IO Manager Security Question

NTFSD
1

Hi,

I have a question regarding how IO manager does security checks for operations on a user mode handle.

In my driver at create time I do various security checks (i.e. computing implied access from desired access, etc.), use IoCheckShareAcess, SeAccessCheck, etc.

How does the IO manager decide if a subsequent IO operation should be allowed to proceed? The FO only has write/read/delete access booleans. How does it decide if attributes can be read/written? Or read/write DAC as another example? Is the granted access mask for the operation stored somewhere else internally that we don’t see?

Once all my checks are done I do the following:

SecurityContext->DesiredAccess &= ~GrantedAccess;
SecurityContext->AccessState->PreviouslyGrantedAccess |= GrantedAccess;
SecurityContext->AccessState->RemainingDesiredAccess &= ~GrantedAccess;

In this case GrantedAccess is equal to my computed implied access. I’m wondering if this is wrong and I should be using the original desired access.

Basically, if someone has asked to overwrite the file I am implicitly checking that they have write access, but am I actually giving them write access by doing the above?

Thanks,
Matt

2

I wrote some additional tests and I now do believe that the code above is buggy. I now make sure that the granted access used to update the security context does not contain any of the implied access check bits. I now also gather that the IO manager keeps the access mask in some internal structure for subsequent access checks.

If anyone has any additional tips on things I am probably doing wrong feel free to chime in.

Thanks,
Matt

3

The granted access is stored in the handle table by iomanager.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Thursday, October 22, 2009 6:51 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] IO Manager Security Question

I wrote some additional tests and I now do believe that the code above is
buggy. I now make sure that the granted access used to update the security
context does not contain any of the implied access check bits. I now also
gather that the IO manager keeps the access mask in some internal structure
for subsequent access checks.

If anyone has any additional tips on things I am probably doing wrong feel
free to chime in.

Thanks,
Matt

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars (including our new fs
mini-filter seminar) 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