Have prepared the summary below for myself, wiith some help, thanks, from Ronny, Endymion and posts in a moderators topic. This is obviously just the opinion of a volunteer moderator on how it works, not an official Comodo description. Thought it might help others, though as you can see some areas are Iâm just guessing.
All updates and corrections gratefully received - they will be reflected in edits to this post.
Declared purpose
To allow software whose security status cannot be immediately identified to be automatically run safely without alerts while it is investigated (eg via CIMA) by Comodo
Aspects of this purpose intentionally not yet implemented
- installers do not work if sandboxed (?may never be implemented - too difficult in 64 bit?)
- automatic investigation by Comodo is not enabled
- automatic sandboxing does not include virtualisation of program data
Components
The sandbox consists of:
- running software as a Windows âjobâ with limited OS user account privileges and OS job limits. Referred to below as restricted privileges. (See appended descriptions of privileges).
- file system virtualisation. In C:\Sandbox
- Registry virtualisation. In Hkey_local_machine\system\sandbox[app name][app created keys]
- A special set of D+ restrictions. Technically, automatically sandboxed software can write to the disk but it cannot cannot a) write to (ie infect) existing protected files or registry keys b) key log or screen grab, set windows hooks, access protected COM interfaces or access non-sandboxed applications in memory
Rules
Known safe software, including know safe installations software, is not sandboxed. Definition of known safe = ??? (signed or identified by hash) AND (not on local/cloud AV list) AND (on Comodo white list or in local my safe files)
Known software believed to be unsafe (on cloud av list) is put in sandbox with restricted privileges, then caught by CIS version 3 facilities when local virus database updated
Unknown software is automatically sandboxed, unless CIS thinks itâs an installation routine and âAutomatically detect installer/updaters and run them outside the sandboxâ is ticked. If CIS thinks its an unknown installation routine, or it asks for Windows admin privileges, you will be asked (once only) whether you want to run it with elevated privileges, and if you say yes, the VENDOR and the file becomes fully trusted you receive no further warnings of any form for files from that vendor. (However the alerts allows you to make a system restore point). If you say no the installer runs in the sandbox, and the installed software is unlikely to work. I suppose CIS probably guesses whether it is an installer from the code signer (or maybe more likely from the file asking for admin privs?).
Any processes directly invoked by sandboxed software are sandboxed.
Any software can be manually sandboxed, including installation routines, but the latter must be run with âunrestrictedâ (ie only slightly restricted) privileges, which can include virtualisation.
Processes
Automatic sandboxing.
This currently consists of, silently:
- running it with restricted privileges. Nothing is virtualised.
- Enforcing a special set of D+ restrictions
- Making a background check on it using CIMA (next version)
- If it looks OK taking it out of the sandbox
Manual sandboxing.
You can:
- Run a program, including an installation progam, once in sandbox by using ârun a program in the sandboxâ (run-once sandboxing). No virtualisation is applied, but various levels of restricted privileges, with associated D+ restrictions, can be applied
- Run software, including an installation program, in the sandbox continuously by adding it in the programs in the Sandbox view (continuous sandboxing). Various levels of restricted privileges and virtualisation can optionally be applied. (D+ file/registry access restrictions are not applied if fully virtualised?).
- not sure what will happen re a CIMA check (in next version). Will it do one???
Unfortunately after running an installation program virtualised, the installed program will not be able to access its files. (This holds , whether the installed program is run within or outside the sandbox and whether it is located inside or outside the sandbox). Also, if a program is run sandboxed and virtualised (after normal installation) it may forget settings made while sandboxed, and may function abnormally in other ways because it cannot access some parts of its data. This appears to arise because virtualisation makes assumptions regarding where (under what directory root) program settings and user data is stored. This happens even with the lowest level of restriction - âunrestrictedâ applied.
Un-sandboxing
You can take an app out of the sandbox:
- and treat it as trusted by putting it in My Safe Files then re-starting it before rebooting. Making it âTrustedâ or âWindows Systemâ in D+ does not seem to work yet, occasionally âMy Safe Filesâ may not work either, as some files seem to be autmatically removed from âMy Safe Filesâ on reboot
- and treat it as a trusted installer, by defining it as an installer in the D+ Computer Security Policy
- and treat it as trusted automatically via the CIMA check (applies to manually sandboxed items?)
- to get rid of it by???
No sure what happens to virtualised program data when a program is unsandboxed - is it copied to the relevant Application Data, or My Docs directory?
GUI & logging (updated to cover release version 10/03)
Automatically sandboxed items are added to My Pending Files, along with other files submitted to Comodo for analysis. However my pending files provides no way of distinguishing between sandboxed pending files and unsandboxed pending files.
Re manual sandboxing, continuously sandboxed items appear in the âPrograms in the sandboxâ. Run-once sandboxed items are not displayed in âPrograms in the sandboxâ or in âMy pending filesâ.
In both manual and automatic sandboxing, a log record is made when software is put in the sandbox, but not when it is taken out. Requests denied by MS job monitoring are not logged even in the Windows event file - on XP anyway - unless they result in an application crash or some such event. Requests denied by D+ due to sandboxing restrictions are logged.
Automatic sandboxing and manual run-once sandboxing can be seen as brown highlighted entries (âjobsâ) with restricted privileges (process properties: security tab and job tags) in process explorer. Not all brown entries are sandboxed - Chrome (hence CD) and IE tab processes already use MS jobs - you need to check the job and security restrictions to be sure - see appended screen shots for what to expect from automatic sandboxing. Not all sandboxed entries are marked brown with normal process explorer settings - you need to untick the other process highlighting rules to ensure that all sandboxed entries will be coloured brown.
All programs which have ever been sandboxed in any way, including those currently sandboxed, have keys under: Hkey_local_machine\system\sandbox\
[attachment deleted by admin]