Shouldn't it just "emulate" the admin privileges like everything else? Why dose it actually require it? And is there any security problems with that?

1 Answer 1


This is a generic answer, since I haven't looked at sandboxie in most of a decade.

There are many software functions that can't be meaningfully sandboxed. Either they are things which inherently require high privileges (like installing drivers or otherwise interacting with the kernel) or they lose their value if sandboxed (a virus scanner that can't read most of the file system is a pretty worthless thing). There are also things which could, in theory, be done by a lower-privilege account or sandbox, but only of the OS is configured with non-default values to allow this (such as installing a Windows Service).

Some such things can be "emulated", but often doing so amounts to creating a miniaturized OS installation that can't interact with the host system. This can be useful for some sandboxing - it's essentially what a VM is, and can also be used with container systems such as Docker - but again that only works for software that doesn't need to interact with the host system at all.

Sandboxed processes frequently, at installation, need to perform some privileged operations. These might be simple things, like changing a file association to open with the new program (that can be done on a per-user basis if the installer is not sandboxed, but if you want it machine-wide the installer must run as Admin, and in any case it can't be emulated). They also can be relatively complex, like creating a new Windows account and installing a Windows service that automatically runs under it when certain conditions are met; depending on what the service does / what permissions it has and what conditions it starts under, this might technically be possible to emulate but it would be very complicated to detect an installer trying to do this and fake support for it.

As for security problems, there certainly can be, if the installer is malicious (e.g. a Trojan) or simply sloppy (perhaps it changes the ACLs on some directory to make it easier for the app to operate, but now other non-admin users can overwrite important files). Most commonly, though, sandboxie and software like it is intended to contain the damage from an exploit, rather than to contain known-malicious software, and the behavior with installers reflects this. Installers typically run only once for a short time, do not typically consume untrusted input (a browser consumes web content from Internet servers; a browser installer does not), and are often fairly simple programs. In other words, they have minimal attack surface.

Consequently, it is very unlikely that an attacker would be able to compromise an installer while it runs, so - so long as you trust its author to not be malicious - there is no need to limit what it can do. Limiting it anyway would break a lot of installers for very little gain. While sandboxie and similar are absolutely intended to be capable of containing malicious code, it is a very reasonable assumption to trust a vulnerable program's installer to not be malicious (if the user chose to run it), while still not trusting (and thus sandboxing) the installed program.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .