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). Sandboxed processes frequently, at installation, need to perform some privileged operations. 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. 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.
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). 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 many software functions that can't be meaningfully sandboxed.
This is a generic answer, since I haven't looked at sandboxie in most of a decade.
0 kommentar(er)
