Why is it that the default permissions for sandboxes and sandboxed objects are set to a very generous full access for everybody? Now this is not a real problem for me, since by default the sandboxes live in the user profile, where other restricted users can't look in, but why is this necessary?
I understand that objects copied to the sandbox cannot have the same permissions as the source objects, because that could lead to all kinds of problems when the sandbox is cleared, but why can't they at least inherit the permissions of the BoxRootFolder or its parent?
Default permissions for sandboxes and sandboxed objects
My assumption is that people aren't going to need to hide the contents of the sandbox from other users on the same computer, because if they did feel the contents were sensitive in some way, it just makes more sense to delete the contents rather than protect it.
Keeping everything accessible to Everyone means that,
o If the same on-disk location is used from multiple user accounts (for example, the sandbox is always C:\SANDBOX, without any per-user characteristics), then they all have access
o If there are sandboxes from multiple users in one top-level folder, then auto-delete by one user can get rid of stale sandboxes by another
There are probably other small benefits to this.
Keeping everything accessible to Everyone means that,
o If the same on-disk location is used from multiple user accounts (for example, the sandbox is always C:\SANDBOX, without any per-user characteristics), then they all have access
o If there are sandboxes from multiple users in one top-level folder, then auto-delete by one user can get rid of stale sandboxes by another
There are probably other small benefits to this.
tzuk
First of all, thanks for taking the time to answer.
Well, I don't entirely agree with your argumentation, because the entire purpose of a multi-user concept is the protection of potentially sensitive or system-critical contents by denying some users access while allowing it to others.
If they aren't logged in as an admin however, then they either don't have admin permissions at all on that box for a reason, or they deliberately chose to do so to leverage the separation that the multi-user concept offers, and they know how to deal with potential problems that arise from it. Writing files with full access for everybody kind of defeats or at least weakens both security concepts.
I personally can live with that, because as long as I can separate the sandboxes of different users by putting them in their user profiles it's not a major problem for me.
On further inspection however, I've found something that I absolutely don't like and that I definitely consider a bug: when I define an OpenFilePath or an OpenKeyPath, the files and keys that get written to that path also end up with full access for everybody outside of the sandbox, instead of the permissions they'd have if I'd write them from an application not under the control of Sandboxie.
This means that anybody who's using the OpenFilePath and OpenKeyPath ini directives ends up with a crude mix of permissions that makes the entire concept of opening paths questionable.
Well, I don't entirely agree with your argumentation, because the entire purpose of a multi-user concept is the protection of potentially sensitive or system-critical contents by denying some users access while allowing it to others.
Since the majority of Sandboxie users are probably logged in as administrators, they'd have full access anyway, so this shouldn't be a problem for most of them.tzuk wrote:o If the same on-disk location is used from multiple user accounts (for example, the sandbox is always C:\SANDBOX, without any per-user characteristics), then they all have access
o If there are sandboxes from multiple users in one top-level folder, then auto-delete by one user can get rid of stale sandboxes by another
If they aren't logged in as an admin however, then they either don't have admin permissions at all on that box for a reason, or they deliberately chose to do so to leverage the separation that the multi-user concept offers, and they know how to deal with potential problems that arise from it. Writing files with full access for everybody kind of defeats or at least weakens both security concepts.
I personally can live with that, because as long as I can separate the sandboxes of different users by putting them in their user profiles it's not a major problem for me.
On further inspection however, I've found something that I absolutely don't like and that I definitely consider a bug: when I define an OpenFilePath or an OpenKeyPath, the files and keys that get written to that path also end up with full access for everybody outside of the sandbox, instead of the permissions they'd have if I'd write them from an application not under the control of Sandboxie.
This means that anybody who's using the OpenFilePath and OpenKeyPath ini directives ends up with a crude mix of permissions that makes the entire concept of opening paths questionable.
Who is online
Users browsing this forum: No registered users and 1 guest
