One of the things that annoys me about Dokany is that it doesn’t support ACL inheritance properly. The reason, of course, is that the parent directory’s security descriptor [such as it is] is kept in user space, and is never passed to the driver to do a SeAssignSecurity on.
To cut my teeth in kernel mode, I decided that I’d like to try to fix this oversight. As is often the case, I realized that the problem is a bit larger than I had anticipated at the outset. So, I have questions, if anyone might share their insight with me?
My basic plan of attack is as follows:
- Create new IOCTL to pass into the driver the parent’s owner, group, DACL and SACL, as well as the requested/proposed DACL to be created with, and as much information from the token handle as I have available.
- Inside the driver, verify the read and write buffers passed in, then create new SECURITY_DESCRIPTOR structures for the parent and the requested/proposed DACL. (?)
- Get the token of the user to (somehow) get the SECURITY_SUBJECT_CONTEXT necessary for SeAssignSecurity (?)
- IoGetFileGenericMapping() to get the file generic right mappings.
- Call SeAssignSecurity()
- Determine the size of the block SeAssignSecurity returns, get the total size of the appropriate parts of the returned block to return to the user, copy that value to the output size argument. If the output block is non-NULL and big enough, copy those appropriate parts to it. Set the return value based on whether SeAssignSecurity worked, or if the buffer provided by the user was large enoough.
- Call SeDeassignSecurity() on the block that SeAssignedSecurity returned.
- Return to user mode.
As you can see from the (?) tags on a couple of these steps, I’ve got some questions.
- What pieces of the security descriptor are actually needed for SeAssignSecurity? I know that at least owner/group/dacl are needed; is the sacl?
- What bits should I set in the parent’s created SECURITY_DESCRIPTOR’s Control field? I don’t get to keep this around.
- What bits should I set in the proposed ACL’s Control field?
- Should I fill in the Owner and Group in the proposed ACL’s SECURITY_DESCRIPTOR from the user mode client?
- I have the token of the client in user mode. I know I need to use this, somehow. Should I impersonate it in user mode and simply request the caller’s security token in kernel mode? (I’ve been avoiding this because impersonation requires a separate privilege, and I don’t have that privilege on my primary development user account where I’ve been test-running things to this point.)
- How do I get the SECURITY_SUBJECT_CONTEXT from the token (or the caller)?
And finally,
- Should I use SeAssignSecurity, or SeAssignSecurityEx? If the Ex version, what is the appropriate GUID for me to pass in?
- Am I missing anything that I should be worrying about?
Thanks for your help, everyone. I’m new to this, so I’m not sure what to do.