March 19, 2007

Poor design decision for ACL control with UAC?

So one of the most interesting things that goes on at an MVP Summit is the parties at night. Never a good sign when Security MVPs whip out laptops, start cackling in the back corner and dive deep into subjects of interest. Of course a LOT of it I can't talk about, but there was one issue Gabriel and I discussed that is worth talking about publically, since its already known to the public.

That would have to be a design decision, that externally, looks kind of bad when it comes to elevation of file/folder access on Vista. When a Standard User tries to enter a directory it doesn't have access to an elevation prompt occurs. All good so far. If the credential check succeeds, Vista grants that user read access for that folder (and its children) by extending read access to the ACL for that folder. You would kind of expect that.

But then nothing more occurs. You would ASSUME that the ACL would be returned to its previous state when the session ends. But you would be wrong. And it doesn't change when you log off either. Once the permission has been granted, you now have read access forever... or at least until you manually remove the ACE for that DACL.

Is this a security vulnerabiity? Depends on who you ask. I don't think it is. You have given that user access. Nothing prevents them from taking a complete snapshot of all data at that point in time. However I do believe its a bad security decision. Because it never reverts access control back to the previous state, it is EASY to forget about the access change, and later place sensitive data in that directory that someone else may have access to that you don't expect.

I would love to understand the thinking behind this. I understand the concept of changing the ACL, but I would have expected that the ACL would be reset when the session ended. If anyone from Microsoft would like to comment, I would be sure to link to the post. I would love to learn the reasoning behind this design decision.

Personally, I think it was a poor decision. However, I don't have the luxury of looking at the threat model that was performed on this part of the system. I have no idea what I may not be considering here. Elevating access permanently just doesn't seem reasonable to me unless you inform the user of that fact. And that never occurs.

What do you think?

Posted by SilverStr at March 19, 2007 09:27 PM | TrackBack
Comments

I can only imagine it was done this way to reduce UAC dialogs, i.e. so that if a user often needs to view that directory, they only have to elevate once, and then Windows will remember that.

I agree it's not a good design decision, but hey this is Microsoft - the default account is still an Administrator.

Posted by: Mike Weller at March 20, 2007 01:13 PM

If I need to view a directory or be able to manipulate a piece of the registry, I can always fix the ACL myself.

I don't understand about the elevation prompt changing anything. The model is that the elevation prompt from an LUA opens a process under an administrative account, one that had to be logged into. From an admin account, the UAC prompt is really just a matter of confirmation.

So it sounds like they found an uncovered case and slapped in a workaround that leaves collateral damage and doesn't fit the conceptual model that users are taught by the other cases.

If there is a directory access that can't be handled by elevation alone, I wouldn't allow it as a UAC-override. There should be some respect for the prospect of that being intentional.

Posted by: orcmid at March 20, 2007 01:30 PM

Whatever happened to DuplicateHandle()? Once the user agrees to elevate to access the file in question, a privileged service can open the file and then duplicate a handle to it into explorer's (or whatever's) process that has the required access. The handle would be closed when explorer was finished with it, or when the explorer process exits (e.g. during logoff) at the very latest. Future security would not be compromised.

I would be disgusted (but not too surprised) if this wasn't an option because the shell's design doesn't support using a file from just a handle.

ACLs are persistent security metadata. It should be perfectly obvious when and how they are modified. Any kind of change-restore strategy would be prone to race conditions and premature restores (e.g. what if during the user's session the user really wanted the change to become permanent? There'd be no way to distinguish between the temporary change and a permanent one-- at least without a hack to the security system).

Posted by: Foolhardy at March 26, 2007 06:15 PM
Post a comment









Remember personal info?