File specification inc. using wildcards in CIS (Technical FAQ)

Please note that this FAQ is a technical FAQ for advanced users. If you make mistakes when using some of the techniques below you could compromise security.

A. FILE SPECIFICATION FACILITIES

File specification dialogs
There are essentially two dialog types:

  • Comodo multiple selection file dialog used in D+ Groups, Protected and Blocked files; also AV exclusions. Where this is used you can select multiple files and directories.
  • Windows dialog used in D+ rules, and throughout the FW module) Where this is used only single files can be directly selected - multiple files and directories cannot be directly selected. You can however edit a path created by the Windows dialog to create a directory spec.

Wildcards. You can use the * wildcard in place of multiple characters and the ? wildcard in place of one one character in file selection operations. CIS interprets embedded wildcards correctly eg C:\fred*\mary.exe will be interpreted as all instances of mary.exe in paths starting with fred with any intermediate directory or directories.

Environment variables. You can use environment variables like %windir% and %comspec%, including ones you define yourself. But remember to restart the CIS GUI, cfp.exe, after defining them using exit from the CIS tray icon and the CIS start menu link.

Groups. Groups allow you to define sets of file specifications that can be re-used in file selection dialogs at many different points in CIS, including different modules. You define file and directory groups using the ‘groups’ button in protected files in D+, and then refer to this group from other parts of CIS, but not from Defence plus trusted files or AV exclusions. Environment variables may be of some help there.

Editing paths. If the CIS dialog does not allow you to create the precise string you want, select any file, then edit the resulting path. Sometimes - eg trusted files - a right click is needed. This appears to work in all CIS file selection dialogs.

Ordering. Some rules - the rules in Computer security ~ D+ rules and everywhere in the Network Security Policy - can be priority ordered. This means that you can create rules for broader filespecs that over-ride rules for narrower filespecs in some circumstances (see below for details).

The character ‘|’ adds file deposit restrictions to a directory in the D+ Computer Security Policy ~ Protected files. It is not really part of a filespec, more part of a rule.

B. USING THE FACILITIES - SOME SUBTLETIES

[ol]- Paths like C:\fred\google* match C:\fred\googleapplications\typit.exe and C:\fred\google.bat as well as C:\fred\google\yung.bat. Such paths are often automatically created when you select directories so watch out! If you just want all the files in a particular directory use C:\fred\google* instead. Use the ‘editing paths’ technique above if needed.

  • Wildcards cover subdirectories of matched directories though in the case of D+ Trusted Files you need to tick ‘include sub-directories’.
  • You cannot use the classic DOS . path to mean all files in the current directory, but none in subdirectories. CIS is consistent - it sees the terminal asterisk and includes subdirectories
  • You CAN make rules for narrower sets of files that over-ride ones for broader sets where the sets are the subject of the rule. Where rules can be ordered, simply ensure the rule for the narrower set is above the broader set. So for example you can say that Fred directory files (subject) are isolated but \fred\holiday directory files are not.
  • But where the file sets are the object of the rule you CANNOT make rules for narrower sets of files that over-ride ones for broader sets by any technique I can find - in general it appears that ‘allow’ object filespecs override ‘block’ object filespecs. So for example you cannot say that Phil (subject) directory files are protected from access by Program directory files (object) but not from Program\utility files (object). [See note 1]
  • You can use pathless wildcarded file specs eg make *.pdf wherever it occurs on any path a installer/updater say. This is powerful but when allowing actions, or using permissive policies, is also a potential security risk, so use with care. It is best to restrict it if you can, for exmple like this: ??days?.pdf
  • Wilcards used when adding files to trusted files are applied only at the point of addition, so if you add files afterwards to a directory which matches these patterns they will not be regarded as trusted files. Even then, when defining trusted files, wildcards embedded in file names are ignored - only wildcards defining directories are expanded. If you want to get over these problems consider making the files concerned installer/updaters in D+ rules instead. Note that files made instalers/updaters can run any other files they want and they and the files they run can do anything they want on the system. So use this cautiously
  • If you are constantly needing to re-use the same selection of wildcarded filespecs then you can define a group and refer to it from elsewhere in D+
  • If you are trying to create a wildcarded rule to determine which files can run or which should be blocked, note that this must be applied to the process/file that is running the file, not the file itself. So to prevent a file being started from the OS GUI, add the rule as an access settings, ‘run an executable’ rule of explorer.exe for example. If you want to allow the execution of executables which are automatically variably named, add the rule as an access settings, ‘run an executable’ rule of the file that runs the executable.[/ol]

FOOTNOTES
[1] I have tried creating rules with duplicate subject file specs but different object file specs and using rule ordering, but CIS just acts as if it has merged the rules instead of acting on the order of the rules. (Creating rules with duplicate subject file specs but different object file specs is possible using groups or environment variables).

[2]This FAQ deals with very generalised rules and it has not therefore been practical to test all aspects of it. It is therefore presented very much on a best endevours basis. Please do help us improve by posting suggestions/corrections to the ‘Help materials - Feedback topic’ here.