Architecture of Sandboxie #3882
Replies: 1 comment 1 reply
-
Sandboxie is an OS-level application sandbox. It heavily relies on Windows security model for restricting access to resources by running programs with a very restricted access token (untrusted integrity, removed privileges, all groups marked as deny-only). Since programs would not be able to run under such conditions, Sandboxie then hooks hundreds of functions in the sandboxed processes and redirects/lies about the operation results in an attempt to fix compatibility without compromising security. There are three components that participate here:
Usually, relying on user-mode hooks is a bad idea for security, but here it works well because sandboxed processes effectively have two choices:
You can find many similarities between the architecture of Sandboxie and Chrome Renderer Sandbox since they both run untrusted code under very restricted security contexts and rely on conceptually similar brokering mechanisms. The primary difference is that Sandboxie is a general-purpose sandbox that can run any program, while Chrome Sandbox is not. On the downside, Sandboxie needs a driver and a service to work, so it potentially introduces a bigger attack surface. However, compared to other 3rd party application sandboxes (Avast, Comodo, 360 Security, Shade) that do not restrict process tokens and, thus, do not introduce a security boundary between sandboxed and unsandboxed processes, Sandboxie offers very formidable isolation. |
Beta Was this translation helpful? Give feedback.
-
Please help me with the architecture of Sandboxie, with the details like drivers used at the kernel level and user level etc.
Beta Was this translation helpful? Give feedback.
All reactions