4

I'm running a sandboxed application as a local user. I now want to deny almost all file system permissions for this user to secure the system, except for a few working folders and some system DLLs (I'll call this set of files & directories X below).

The sandbox user is not in any group. So it shouldn't have any permissions, right? Wrong, because all "Authenticated Users" are a member of the local "Users" group, and that group has access to almost everything.

  • I thought about recursively adding deny ACL-entries to all files and directories and remove them manually from X. But this seems excessive.

  • I also thought about removing "Authenticated Users" from the "Users" group. But I'm afraid of unintended side-effects. It's likely that other things rely on this. Is this correct?

Are there better ways to do this? How would you limit the filesystem permissions of a (very) non-trustworthy account?

Simon
  • 151
  • 1
  • 7

5 Answers5

4

A couple things to keep in mind:

Disable bypass traverse checking for that user.

Explicit allows take precedence over inherited denies.

I would not recommend altering the Authenticated Users or Users security groups.

Ryan Ries
  • 55,481
  • 10
  • 142
  • 199
  • Haven't thought about Bypass Traverse Checking. I just read KB823659 which states that "Therefore, removing the Everyone group from the list of security principals who have this user right by default could lead to operating system instability or to program failure. It is better that you leave this setting at its default.". How can I only deny a single account this right? Secpol.msc -> User Rights Assignment only allows me to add other users/groups, not to deny. – Simon Sep 14 '12 at 23:29
4

Give a deny to that user at the root of the drive for exerything except "Traverse Folder" and then grant an explicit allow where you want them to be able to read. Generally speaking, removing Authenticated Users from Users isn't a good idea.

MDMarra
  • 100,734
  • 32
  • 197
  • 329
  • I like your answer better than mine because it's more of a direct answer to his question and less vague design considerations. – Ryan Ries Sep 14 '12 at 23:52
  • I tried it, but it didn't work. The user still has access to almost all files. To make sure that I did the right thing: Right clicked C:, Security, Advanced, Change Permissions, Add..., enter username, check "Full control/Deny", uncheck "Traverse folder/Deny". I set the combobox at the top of the dialog to "This folder, subfolders and files" and (2nd attempt) to "This folder only". Both things didn't work. Probably related to the "Bypass traverse checking" right? – Simon Sep 15 '12 at 00:01
  • Did you put a tick in the box to apply it to all subfolders and child items, and are you doing this with an account that actually has permission to change the permissions on every file on C:? – MDMarra Sep 15 '12 at 00:04
  • I'm doing it as a local admin. Are you sure I should tick the "[ ] Replace all child object permissions with inheritable permissions from this object"? Wouldn't this mess up all special permissions in C:\Windows for example? – Simon Sep 15 '12 at 00:09
  • Actually, yes. That's a good point. It's so rare to try and do something like this that I forgot about that. – MDMarra Sep 15 '12 at 00:12
  • Note that with the permissions proposed by @MDMarra the user would need to know the *exact path* of any file he needs to access, because he can't enumerate the contents of a folder despite being able to traverse it. If you want the user to be able to click through folders, you need two ACLs. One to `deny all except Traverse folder and List folder for this folder and subfolders` and the other to `deny all for files only`. Also note that the owner of an object can always remove ACLs from that object, so you'd need to make sure that he doesn't own any of the files/folders. – Ansgar Wiechers Sep 15 '12 at 11:25
  • @AnsgarWiechers Since this was a service account to run an application, I assumed that any file-access would be to specifically enumerated files. – MDMarra Sep 15 '12 at 13:00
3

I don't think this is the right way to approach this.

What you should really do is set ACLs on confidential data you have (eg. if users have home folders on this computer, you should change its ACL so that only that user and administrators are granted any access at all on it).

Falcon Momot
  • 25,244
  • 15
  • 63
  • 92
1

In the end I went with the "excessive" solution:

icacls c:\* /T /C /deny MyComputer\SandboxUser:(OI)(CI)F

This adds deny entries to all files and directories. Then I used Process Monitor to see what permissions I have to change manually to let the application run.

Simon
  • 151
  • 1
  • 7
  • Thanks for all the great answers and the effort. I upvoted all of them. Fair? What's the right thing to do here? – Simon Sep 16 '12 at 11:56
0

Remember that even a very non-trustworthy user that you want to be able to log in to your system will need read access to certain system files. What's your concern here? If you're worried about a user being able to delete system files and the like, then a standard user account will probably give the security you need. Make them a member of the Guests group if you're really concerned.

If you're really, really concerned then perhaps consider applying a more restrictive security template to the system (or use the Security Configuration Wizard if you're talking Windows 7/2008 or later), but be aware that this can break things for other users.

Chris McKeown
  • 7,168
  • 1
  • 18
  • 26
  • I'm not concerned about general server security. This user account is just used to sandbox one specific type of application, which is secured by other means too (restricted tokens, job objects and integrity levels). NTFS file permissions is just defense in depth. I'm mostly worried about the user reading confidential data - not deleting system files. – Simon Sep 14 '12 at 23:41