Since the philosophy of a sandbox is not to limit software, but to segregate its effects, you would expect the sandboxed processes by default to run with few restrictions. Since CIS currently assumes that what is to be protected lies outside the sandbox, and dangers stay within, you would also expect there to be few protections on sandboxed processes.
Experimentation in Kiosk (which may not hold completely for FV process run outside Kiosk) was used to gather the information below, as there is currently no information in the help file.
The default policy for sandboxed files, whether trusted or unknown is ‘fully virtualised’. You can if you wish specify more restricted policies if you sandbox using Advanced Settings ~ D+ ~ Sandbox ~ Add, but you cannot do this easily if using the Kiosk, and probably cannot at all if using automatic sandboxing.
The Fully Virtualised policy
Restrictions
In line with expectations the default, Fully Virtualised (FV), policy imposes relatively few restrictions on software, and no restrictions on registry or file writes. In the main therefore the files run with privs similar to those of trusted files in the non-sandboxed, non-virtualised (NV) environment. Elevated privs seem to be silently granted if required.
FV processes:
[ol]- Keylogging. Cannot keylog FV processes using some (3/7 Aklt.exe, 0/1 Zermana, 0/1 Antitest) techniques, and NV processes using most techniques.
- Screenshotting. Cannot screenshot using some techniques. (Blocks snipping tool, WinGrab & most Faststone techniques but no Spyshelter techniques, or PrtScn)
- Killing etc. Cannot kill or access the memory of NV processes
- Shutdown. If unknown, cannot shutdown or logoff the computer
- Driver installation and Debug privs. There are some restrictions in this area, including driver renames, and some required to run a simple debugger, but I have not been able to pin them down.[/ol]
Protections
Also in line with expectations there are few, indeed I have discovered only one, sandbox-specific protection from NV processes. This protection seems to apply even if the NV process is trusted, and so is probably not a consequence of NV processes being Behavior-Blocked.
- Keylogging. NV processes cannot keylog FV processes using most techniques (AKLT 0/7, Antitest 1/1)
Of course the Behavior Blocker restrictions on unknown NV files will have the effect of offering additional non-sandbox-specific protection to FV proceses.
More restricted policies
These have names similar to the Behavior-Blocker levels. I would anticipate that these levels impose similar restrictions to the eponymous Behavior Blocker levels minus the restrictions on access to Protected Files and Registry Keys. The latter would not need to be protected as any writes would be virtualised.
Further details
As this information has been gathered by experiment not documentation it is subject to experimental error and it may therefore be added to or corrected later.
Notes
The following general points were discovered from experiments with the FV policy, but probably apply to other policies as well.
[ol]- Some, especially asynchronous, communications protocols fail between sandboxed and non-sandboxed processes (eg DCOM) probably due to current sandbox design limitations not deliberate restrictions. (No log records are generated).
- The screen-grabbing restrictions seem currently to be provided by the old HIPS rules not the new behavior-blocker rules as foreground as well as background screen-grabbing is prevented. They have therefore been tested as foreground techniques.
- The FV access restrictions seem not to depend on whether the file is unknown or trusted (excluding the shutdown restriction), the BB or HIPS is on or off, or whether programs are run in or are installed in the sandbox.[/ol]
I will attempt to gain further clarification on all the points in this FAQ and update it when any information becomes available.