Comms leaks from the sandbox - how to control? [v6]

Using default settings sandboxed files could potentially pass information to non-sandboxed files or vice-versa, this breaching the ‘walls’ of the sandbox. Here are some ways you can reduce this risk, though there are significant disadvantages in each case.

[ol]- Raise the sandbox restriction level. For sandboxing via the CIS interface (ie not KiosK) you can raise the restriction level placed on sandboxed files if you sandbox them via Advanced Settings ~ Defense+ ~ Sandbox ~ Add. Try using Partially Limited or Limited instead of Fully Virtualised. The disadvantage is that some programs will not run with more restricted permissions.

  • Raise the non-sandboxed restriction. That is level of restriction for unknown processes running outside the sandbox. Consider using ‘Limited’ or higher instead of Partially Limited. You can do this using Advanced Settings ~ Defense+ ~ Behavior-blocker ~ ‘Treat autosandboxed (behavior-blocked) applications as’. This will reduce the risk of non-sandboxed files gaining access to sandboxed data or processes. Unfortunately this rule will apply whether or not the processes trying to gain access are sandboxed. The main disadvantage is that some programs will not run properly under more restricted permissions.
  • Turn HIPS on and and set protection on non-sandboxed processes using an ‘all applications’ rule. This will reduce the risk of sandboxed files gaining access to non-sandboxed data or processes. Unfortunately this rule will apply whether or not the processes trying to gain access are sandboxed.
  • Address the Clipboard leak. Use an external clipboard enhancer, for example Clipmate. If you run Clipmate installed outside the sandbox, from a link within the Kiosk, it will ask to create a new database. This database will be virtualised, and not easily accessible from Clipmate outside the sandbox. The disadvantage in this case is inherent - you lose the convenience of sandbox transfer from sandboxed to non-sandboxed files.[/ol]