SeAccessCheck with UAC

Paolo_Gatti · March 21, 2013, 1:40pm

My filesystem filter driver protects access to various files etc by using SeAccessCheck.

The DACL that protects my files allows administrators access but denies everyone else.

I get the token via a call to SeCaptureSubjectContext and then a call to SeQueryInformationToken.

However, if the user mode process is running under an account in the administrators group and UAC is enabled the the access check fails.

I can see why it fails – the token i’m using is “un-elevated” and so, as far as SeAccessCheck is concerned, the calling process is not in the administrators group. I had thought that calling SeQueryInformationToken and asking for the LinkedToken might fix it but if i do this it just returns BAD_PARAM …

any ideas anyone ???

Many thanks,

Paolo

OSR_Community_User · March 21, 2013, 3:09pm

> However, if the user mode process is running under an account in the administrators group and UAC

is enabled the the access check fails.

This is by design, the process must be elevated.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

Paolo_Gatti · March 22, 2013, 6:19am

Maxim, thanks for your help.

I understand that this is by design but my requirement is to be able to determine whether or not the access check is failing due to the process not being elevated or for some other reason.

It could be failing, for example, if the DACL explicitly denies access to the username associated with the process … or, it could simply be an elevation issue.

If i could do the access check against a token that is already elevated then i could determine if my ‘real’ access check is failing due to elevatoin issues.

I know the phrase “token that is already elevated” probably doesn’t make sense but i’ve been told (though have not tried it) that this is possinle from user mode using linked tokens …

thanks,
Paolo

Paolo_Gatti · March 22, 2013, 2:07pm

… as i understand it, in a UAC environment, the logon process creates the traditional ?full? token and also creates a limited ?filtered? token. The filtered token has the user as a member of Administrators for deny-only.

So, in usermode i’ve been told you can use the ‘full token’ (ie unfiltered) for an access check as follows.

GetTokenInformation(hToken, TokenLinkedToken, … )
AccessCheck( pSecurityDescriptor, TokenLinkedToken, DesiredAccess, …)

If i do this in kernel mode with SeQueryInformationToken (ie specifying TokenLinkedToken) i get a ‘bad parameter’ error

Paolo_Gatti · March 25, 2013, 11:37am

My driver code currently does the following to perform an access check …

SeCaptureSubjectContext(&Context);

SeAccessCheck(myDACL, Context, );

In a UAC environment, access checks can fail due to ‘Context’ pointing to the filtered token (ie the one which has restricted access). This can happen when the ACL allows access to Administrators but denies all others.

I would like to be able to be able to modify “Context” to get it to refer to my unfiltered token before i call SeAccessCheck so it assumes i’m a member of the administrators group for the sake of the access check.

Does anyone know if this is possible or might i have to write my own SeAccessCheck ?

Ken_Johnson · March 25, 2013, 11:56am

You cannot modify the subject context structure (note the clear and unambiguous statement in the documentation, “Drivers are not to modify the SECURITY_SUBJECT_CONTEXT structure directly.”), and you should not attempt to write your own access check function.

The whole point of a split token is that one half does not have the more dangerous privileges, e.g. admin rights. Subverting this compromises the whole point of a split token. This is not something shipping code can do.

What are you actually trying to accomplish here? If a user has a split token and needs to perform an administrative task, the design is that they must elevate.

S (Msft)

From: xxxxx@gmail.com mailto:xxxxx
Sent: ?3/?25/?2013 8:37
To: Windows File Systems Devs Interest Listmailto:xxxxx
Subject: RE:[ntfsd] SeAccessCheck with UAC

My driver code currently does the following to perform an access check …

SeCaptureSubjectContext(&Context);

SeAccessCheck(myDACL, Context, );

In a UAC environment, access checks can fail due to ‘Context’ pointing to the filtered token (ie the one which has restricted access). This can happen when the ACL allows access to Administrators but denies all others.

I would like to be able to be able to modify “Context” to get it to refer to my unfiltered token before i call SeAccessCheck so it assumes i’m a member of the administrators group for the sake of the access check.

Does anyone know if this is possible or might i have to write my own SeAccessCheck ?

—
NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

Paolo_Gatti · March 25, 2013, 12:30pm

… our driver is used to restrict access to removable media such as USB sticks.

If the user is an administrator and our policy says “allow administrators to access USB sticks” then what we are finding is that in a UAC environment, when the user clicks on the USB drive in the explorer navigation pane, our driver denies access to the USB as it performs the access check with explorer.exe’s token which is unelevated
(SeAccessCheck does not consider us to be in the Administrators group).

I am not interested in using the extra privs of the other part of the split token, i just want SeAccessCheck to consider me a full member of the administrators group when i do the access check.

If i run explorer.exe elevated ( kill explorer.exe and restart from elevated command prompt ) then access is granted.

OSR_Community_User · March 25, 2013, 2:31pm

Try creating a shortcut on the desktop to explorer.exe and select “run
as administrator” from the advanced properties tab. If you know that
path to the USB drive then you can include the path. Or you could write
a small command line program to find the USB drive and lauch explorer
with elevation. The key is to elevate the thread before calling into
the kernel. Then your access check will work.

Ken_Johnson · March 26, 2013, 2:47am

Split tokens where the user is really an admin will have the administrators group present as a deny only SID (i.e. matches deny but not allow ACEs).

Have you structured your access checked DACL to *grant* access to administrators and then you refuse access if the access check passes, or to *deny* access to administrators and then you refuse access if the access check fails? The latter should cover you in this particular scenario.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, March 25, 2013 9:30 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] SeAccessCheck with UAC

… our driver is used to restrict access to removable media such as USB sticks.

If the user is an administrator and our policy says “allow administrators to access USB sticks” then what we are finding is that in a UAC environment, when the user clicks on the USB drive in the explorer navigation pane, our driver denies access to the USB as it performs the access check with explorer.exe’s token which is unelevated (SeAccessCheck does not consider us to be in the Administrators group).

I am not interested in using the extra privs of the other part of the split token, i just want SeAccessCheck to consider me a full member of the administrators group when i do the access check.

If i run explorer.exe elevated ( kill explorer.exe and restart from elevated command prompt ) then access is granted.

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Ken_Johnson · March 26, 2013, 2:56am

Apologies, I misread your message and thought you were attempting to deny access to administrators, not grant it!

You cannot use a deny only SID to grant access, only to deny access. (Anyone can label a deny only SID on their token regardless of whether they are a part of that group, but once labeled, the SID cannot typically be removed from the SID group list.)

The non-admin side of a split token is -not- an administrator and you shouldn’t grant access to it as though it were an administrator. As George M. Garner mentioned, the caller needs to elevate to benefit from their admin permissions rather than that happening automatically (which loses the entire point of a split token).

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, March 25, 2013 11:46 PM
To: Windows File Systems Devs Interest List
Subject: RE: RE:[ntfsd] SeAccessCheck with UAC

Split tokens where the user is really an admin will have the administrators group present as a deny only SID (i.e. matches deny but not allow ACEs).

Have you structured your access checked DACL to *grant* access to administrators and then you refuse access if the access check passes, or to *deny* access to administrators and then you refuse access if the access check fails? The latter should cover you in this particular scenario.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, March 25, 2013 9:30 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] SeAccessCheck with UAC

… our driver is used to restrict access to removable media such as USB sticks.

If the user is an administrator and our policy says “allow administrators to access USB sticks” then what we are finding is that in a UAC environment, when the user clicks on the USB drive in the explorer navigation pane, our driver denies access to the USB as it performs the access check with explorer.exe’s token which is unelevated (SeAccessCheck does not consider us to be in the Administrators group).

I am not interested in using the extra privs of the other part of the split token, i just want SeAccessCheck to consider me a full member of the administrators group when i do the access check.

If i run explorer.exe elevated ( kill explorer.exe and restart from elevated command prompt ) then access is granted.

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Paolo_Gatti · March 26, 2013, 7:24am

… thanks for all the input …

On windows-7 you can’t run an elevated windows explorer alongside the standard un-elevated explorer. Customer will want the standard explorer running so i’m stuck with the standard unelevated explorer trying to access USB sticks. I agree that generally if a program needs to run elevated then the user should just run it elevated and the program shouldn’t fiddle around with split tokens in order to determine if the program would have access if elevated – however, i cannot do this with explorer.exe.
I have a usermode program that, when run from an unelevated admin account, can use the more privileged part of the split token for an access check and the call to AccessCheck returns 'access granted. Pseudo code …
DACL = (Allow Admin Access, Deny Users Access)
bOk = OpenProcessToken(GetCurrentProcess(), TOKEN_ALL_ACCESS, &hToken);
bOk = GetTokenInformation(hToken, TokenLinkedToken, &linkedToken, dwSize, &dwSize);
bOk = AccessCheck( lpSD, linkedToken.LinkedToken, …)

If this can be done in usermode why does it seem impossible from kernel mode ???

Paolo