Introduction and approach
Sandbox security works by segregating the contents of the box from the rest of the machine, not by controlling what programs can do. So, to understand how secure a sandbox is you need to analyse whether anything, including users, information and malicious program actions, can get in or out of the box. And you need to understand that what sandboxed programs can do within the sandbox is unlikely to be subject to many restrictions, by default at least.
So you need to know:
[ol]- Are all file writes (including updates and deletes) to the correct location?
- Are all privacy sensitive file reads restricted by request source?
- Can sandboxed processes damage non-sandboxed processes (inc the OS/CIS) or vice-versa?
- Can sandboxed processes connect to non-sandboxed processes an vice versa?
- Can sandboxed programs access system interfaces and drivers (eg keyboard) that work independently of the sandbox boundary and so access the non-sandboxed environment (and vice versa)?
- Can sandboxed programs leak information to the internet?
- Can the sandbox or sandboxed programs be accessed by hackers?
- Can users restricted to the sandbox gain access to the real environment and vice versa? [/ol]
Where privacy is the main concern it is also important to understand whether unknown, potentially malicious, sandboxed processes can secretly obtain access to information which it then could leak through any holes in the box.
The following analysis makes reference to the Fully Virtualised Policy, which as expected does not restrict within-sandbox operations very much. This policy, and more restrictive alternatives are discussed here.
Parts of the analysis, including the assessment of the Fully Virtualised Policy have been undertaken by experiment not from dicumentation and so are subject to experimental error. Monitoring drivers is particularly difficult to achieve, so my conclusions do not yet include a full analysis of driver restrictions/permissions
File and registry reads and writes
The CIS virtualisation facilities are not designed to sandbox every read and write the operating system does - that’s what products like Vmware do. The CIS facilities are designed to sandbox every, or almost every, file and registry read and write made by sandboxed programs - rather like Sandboxie does. Within this scope, the devs believe that the virtualisation technology underlying the CIS sandbox is now inherently more leak-proof than most, possibly all sandboxing technologies because it hooks into the OS at a deeper level. (Better for example, they say, than Sandboxie). That is there should be few inadvertent leaks.
Reads and writes by sandboxed processes outside the sandbox
Writes from the sandbox environment to the real environment are, of course diverted and sandboxed. You might imagine that OS utilities, for example explorer.exe, might escape file write diversion. In fact explorer can itself be sandboxed so it writes to the sandbox, and indeed is when run from Kiosk. You might also wonder whether network writes are virtualised - they are not - instead all access (read/write) to network shares are prevented. (Strangely though read access to mapped drives is allowed). Reads of information outside the sandbox from within the sandbox are allowed unless the information has been updated by a program within the sandbox.
Reads and writes by non-sandboxed processes inside the sandbox
Writes from real processes to the sandbox are not prevented - direct access to the sandbox is is allowed. The CIS virtualiser does not prevent reads of information in the sandbox from outside the sandbox, though you have to know where to go to find the information.
Process disruption
Damage by sandboxed processes to non-sandboxed processes
By default this is handled by the relatively unrestrictive fully-virtualised policy (details here), though higher levels of restriction can be chosen.There are restrictions on the ability of sandboxed processes to:
[ol]- damage (kill or write to the memory of) non-sandboxed processes inc CIS. Though they can kill non-virtualised virtkiosk.exe.
- shutdown the system[/ol]
Damage by non-sandboxed proccesses to sandboxed processes
I have discovered only one, sandbox-specific protection from non-sandboxed processes. Non-sandboxed processes cannot keylog sandboxed processes. Of course the Behavior Blocker restrictions on unknown files will have the effect of offering additional non-sandbox-specific protection to sandboxed processes.
Process connections
Restrictions on process connections between the sandbox and real environments seem to be light to non-existent - indeed I can detect none. However comms may fail in either direction if disk files or the registry is used as a means of data transfer, as they often are in asynchronous transfers. Some ways of addressing these issues are covered in this FAQ here, though these currently come with significant disadvantages, so you’ll need to weigh up your options.
Connections by sandboxed proceses to non-sandboxed processes
Unknown program running in the sandbox by default (ie under the 'fully virtualised policy) have little or no delberate comms access restrictions. So for example if you run an unknown program in the sandbox which uses a service without installing the service in the sandbox, it will communicate with a non-sandboxed instance of the process which can write outside the sandbox. System processes which have a communications role are another source of potential vulnerability. In particular the Windows Clipboard is not controlled so anything you cut or copy from a sandboxed app gets written to disk outside the sandbox.
Connections by nonsandboxed procceses to sandboxed processes
Unless they are CIS or system processes, sandboxed processes won’t themselves have any protection against access from outside the sandbox either, though unknown processes running outside the sandbox will have the normal Partially Limited access restrictions.
Process access to general (virtualisation independent) interfaces and drivers
Key interfaces and drivers include those related to the disk (direct access, not via filesystem), keyboard, screen, and webcam
Access by sandboxed processes outside the sandbox
Direct disk writes are prevented as they are very difficult to virtualise.There seem to be no restrictions on sandboxed programs carrying out clipboard logging, web cam capture, or sound capture of the real environment. In addition sandboxed processes can use system processes or drivers to keylog non-sandboxed processes by at least one technique, though most techniques are inhibited. Screen capture of the real desktop by Kiosk programs is prevented unless the user ‘switches to windows’ because the screen displays the Kiosk. Screen capture of the real desktop by non-Kiosk sandboxed programs is possible using some techniques, and some are prevented.
Access by non-sandboxed processes to sandboxed processes
Unknown processes running outside the sandbox will have the normal Partially Limited access restrictions, including prevention of most background screen-grabbing techniques. These restrictions do not include clipboard logging, web cam capture, or sound capture, so they should be able to capture sandbox information and pass it outside the sandbox. It is not clear that screen-grabbing restrictions which are background only help much when you cannot see non-sandboxed foreground Kiosk processes because the Kiosk is being displayed.
Leaks to the internet
Files in the sandbox have the same firewall restrictions and encryption rules as files running outside the sandbox. By default inbound access is not allowed, so you should be safe from hackers trying to access your sandbox. Outbound access is allowed by default for both trusted and unknown files. You may wish to tighten this. Although you cannot yet make the protection level dependent in any way on sandboxed status, you could consider raising the overall level of control as described in this FAQ here.
Secret access to sandbox information by sandbox processes
The risks associated with this and other security holes are increased by the ability of sandboxed processes to background keylog and clipboard log other sandboxed processes. By default - ie for processes running under the the fully virtualised policy - there are partial restrictions in place that restrict the ability of sandboxed processes to background keylog and screen-grab other sandboxed processes. There seem to be no restrictions on clipboard logging, web cam capture, or sound capture.
User access to the sandbox and the real desktop
If you have data or systems you want to protect in a sandbox, user access from the real desktop can be restricted using CIS and/or Kiosk passwords. If you have data or systems you want to protect in the real environment, user access from the Kiosk can be restricted using a Kiosk exit password. Password implementation is rather flaky and easily bypassed at present, so while it may deter, it won’t withstand a determined attack.