RtlAddAccessAllowedAce to set as read only

NTDEV
1

I’m not entirely sure why this is not working as I would think it would. I am creating a security descriptor with the intent of making a partition (for a USB storage device) readonly access. Meaning you can traverse the directories, list the directories contents, open files, read the contents of files, etc. HOWEVER, under no circumstance should anything be able to write to the partition for any reason (ie. no new folders, no saving of documents, etc.).

I have been trying variations of the following ACE statements and either it renders the partition as thinking it is needing to be formatted (if SeLocalSystemSid is missing FILE_EXECUTE), or allows completly normal operations on the partitions as if there were no modified ACE at all.

Here ae the two ACE statements I am making:
// Define the ACE of each ACL
status = RtlAddAccessAllowedAce(pAclReadOnly,
ACL_REVISION,
READ_CONTROL | FILE_EXECUTE | FILE_READ_DATA | FILE_READ_EA | FILE_READ_ATTRIBUTES | FILE_LIST_DIRECTORY | FILE_TRAVERSE,
SeExports->SeLocalSystemSid);

status = RtlAddAccessAllowedAce(pAclReadOnly,
ACL_REVISION,
READ_CONTROL | FILE_READ_DATA | FILE_READ_EA | FILE_READ_ATTRIBUTES | FILE_LIST_DIRECTORY | FILE_TRAVERSE,
SeExports->SeAuthenticatedUsersSid );

2

Regarding the bit about formatting, I have no idea, but two general comments, that may or may not apply in your case, depending on where you’re applying this ace:

1.) RtlAddAccessAllowedAce (v. RtlAddAccessAllowedAceEx) doesn’t allow you to specify any sort of inheritance properties.

2.) Neither one will necessarily result in the total set of ACE’s (if more than just this one exist) being ordered in the way that you would like; that is, something else could be, say, granting write access to someone, and it might be getting applied later.

So:

a.) Where are you applying this ACE v. where are you trying to access?
b.) Are they any others already there (or higher up that are getting inherited)?

Good luck,

mm

3

> I’m not entirely sure why this is not working as I would think it would. I am creating a security

descriptor with the intent of making a partition (for a USB storage device) readonly access. Meaning
you can traverse the directories, list the directories contents, open files, read the contents of files, etc.
HOWEVER, under no circumstance should anything be able to write to the partition for any reason (ie.
no new folders, no saving of documents, etc.).

I don’t think you can solve this task with an ACL.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

4

MM,

I am applying the security descriptor as a brand new one to the USB device and all of its partitions. However, after thinking about your comment you could be entirely right that perhaps the permissions are not being inherited down…

So I am attempting to retest this with RtlAddAccessAllowedAceEx instead. I am hoping that the flag ADS_ACEFLAG_INHERIT_ACE = 0x2 found here http://msdn.microsoft.com/en-us/library/aa772242(VS.85).aspx will work. ie.,
status = RtlAddAccessAllowedAceEx(pAclReadOnly,
ACL_REVISION,
0x2,
READ_CONTROL | FILE_EXECUTE | FILE_READ_DATA | FILE_READ_EA | FILE_READ_ATTRIBUTES | FILE_LIST_DIRECTORY | FILE_TRAVERSE,
SeExports->SeLocalSystemSid);
status = RtlAddAccessAllowedAceEx(pAclReadOnly,
ACL_REVISION,
0x2,
READ_CONTROL | FILE_EXECUTE | FILE_READ_DATA | FILE_READ_EA | FILE_READ_ATTRIBUTES | FILE_LIST_DIRECTORY,// | FILE_TRAVERSE,
SeExports->SeAliasAdminsSid );

So after testing this the partition is completely editable still… I keep checking the permissions for the devices under devicetree and for both the raw disk and the partition I see Administrators read access only and system read access only. However I just noticed that \FileSystem\Fastfat has Everyone with Full permissions (which is exactly what I am seeing occur). I thought applying a security descriptor to a device applied to everything in the stack after that device?

If Fastfat’s permissions are what are allowing the access to the disk, how do I adjust my security with only knowing the DEVICE_OBJECT in my disk filter driver so that I can target whatever Filesystem is being used so I can apply the pemissions to that filesystem as well, whether it be NTFS, FastFat, etc.

5

For example, in order to find the raw disk and its partitions to apply the security settings I am creating, I walk from \Driver\Disk all of its child devices looking for the ones that contain in their name string “%d\DR” and “%d\DP(” where %d is the disk number I am looking for. Then ObOpenObjectByPointer and ZwSetSecurityObject and we are done with that device. It keeps on enumerating all of the devices until it finds all that match the criteria listed above. I’m sure I could do something similar for the filesystems, but I’m not sure how I would identify which of the many many filesystems I need to look at. I suppose I could exhaustively go through them all from \FileSystem but then I need something unique to key off of like I do for the disks.

Ideas? Better solutions?

6

I had a thought on this as I perused through the device stacks looking for how to make the jump from the partition device to the filesystem device object.

Is it legal to access DeviceObject->Vpb.DeviceObject? From what I can tell I am starting at my partition in question that I have changed the pemissions on… inside of its DeviceObject is a structure called Vpb which contains another DeviceObject which is the FileSystem device that I need to set the permissions on. With that I could still do ObOpenObjectByPointer and ZwSetSecurityObject. But I see with further inspection that my disk0 partition has a DeviceObject->Vpb.DeviceObject but its value is NULL. Does that mean an NTFS system should take the permissions and anything else other than NULL I apply the security on? It seems logical, but someone more experienced might spot a falicy with this.

7

ok… applying ZwSetSecurityObject on pDeviceObjectTemp->Vpb->DeviceObject yeilds a STATUS_NO_SECURITY_ON_OBJECT “Indicates an attempt was made to operate on the security of an object that does not have security associated with it.” So… that didn’t work. If the filesystem device object cannot have a security_descriptor how does DeviceTree show it having a DACL of everyone full access? I’m missing something. But out of ideas for now…

Anyone have any suggestions?

8

You’re up the wrong tree I think. Security only applies to named objects,
the non-control FS device objects (like the one you got out of the VPB) are
unnamed.

I don’t have the code in front of me, but I suspect that Device Tree is just
showing the default DACL since there’s no security on the object.

All that you’re doing with locking down the disk/partition/volume devices is
locking down raw access to the volume. So, if the user opens “c:” then your
security descriptor will be applied. However, if the user opens "c:" then
the access check is not performed. At that point it becomes the job of the
file system to enforce the security and you’re in the realm of a file system
filter driver.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> ok… applying ZwSetSecurityObject on
> pDeviceObjectTemp->Vpb->DeviceObject yeilds a STATUS_NO_SECURITY_ON_OBJECT
> “Indicates an attempt was made to operate on the security of an object
> that does not have security associated with it.” So… that didn’t work.
> If the filesystem device object cannot have a security_descriptor how does
> DeviceTree show it having a DACL of everyone full access? I’m missing
> something. But out of ideas for now…
>
> Anyone have any suggestions?
>

9

Thanks Scott.

Is there a way to bridge that gap? Ie set a sddl string on "c:" and
all of it’s child objects/containers from the kernel, specifically my
disk filter? For example my driver already determined the drive
letter that matches the partition I physically filter over. I
appreciate your comments.

Sent from my iPhone

Brian

On Apr 13, 2010, at 4:36 AM, “Scott Noone” wrote:

> You’re up the wrong tree I think. Security only applies to named
> objects, the non-control FS device objects (like the one you got out
> of the VPB) are unnamed.
>
> I don’t have the code in front of me, but I suspect that Device Tree
> is just showing the default DACL since there’s no security on the
> object.
>
> All that you’re doing with locking down the disk/partition/volume
> devices is locking down raw access to the volume. So, if the user
> opens “c:” then your security descriptor will be applied. However,
> if the user opens "c:" then the access check is not performed. At
> that point it becomes the job of the file system to enforce the
> security and you’re in the realm of a file system filter driver.
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> wrote in message news:xxxxx@ntdev…
>> ok… applying ZwSetSecurityObject on pDeviceObjectTemp->Vpb-
>> >DeviceObject yeilds a STATUS_NO_SECURITY_ON_OBJECT “Indicates an
>> attempt was made to operate on the security of an object that does
>> not have security associated with it.” So… that didn’t work. If
>> the filesystem device object cannot have a security_descriptor how
>> does DeviceTree show it having a DACL of everyone full access? I’m
>> missing something. But out of ideas for now…
>>
>> Anyone have any suggestions?
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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

10

> Is there a way to bridge that gap? Ie set a sddl string on "c:" and all

of it’s child objects/containers from the kernel, specifically my disk
filter?

That’s exactly what the FILE_DEVICE_SECURE_OPEN device object flag does, so
if you could somehow convince the FS to set this bit then it would work.
But, I don’t think that there’s any way to do that, so you’d need a filter
that would perform the access check for every open.

I’ll warn though that this won’t likely lead to the results that you expect.
Lots of applications ask for write access even though then never plan on
writing to the file. In fact, for application compatibility reasons neither
FAT nor NTFS fail opens with write access on read only volumes.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Brian” wrote in message news:xxxxx@ntdev…
> Thanks Scott.
>
> Is there a way to bridge that gap? Ie set a sddl string on "c:" and all
> of it’s child objects/containers from the kernel, specifically my disk
> filter? For example my driver already determined the drive letter that
> matches the partition I physically filter over. I appreciate your
> comments.
>
> Sent from my iPhone
>
> Brian
>
> On Apr 13, 2010, at 4:36 AM, “Scott Noone” wrote:
>
>> You’re up the wrong tree I think. Security only applies to named
>> objects, the non-control FS device objects (like the one you got out of
>> the VPB) are unnamed.
>>
>> I don’t have the code in front of me, but I suspect that Device Tree is
>> just showing the default DACL since there’s no security on the object.
>>
>> All that you’re doing with locking down the disk/partition/volume
>> devices is locking down raw access to the volume. So, if the user opens
>> “c:” then your security descriptor will be applied. However, if the user
>> opens "c:" then the access check is not performed. At that point it
>> becomes the job of the file system to enforce the security and you’re in
>> the realm of a file system filter driver.
>>
>> -scott
>>
>> –
>> Scott Noone
>> Consulting Associate
>> OSR Open Systems Resources, Inc.
>> http://www.osronline.com
>>
>>
>> wrote in message news:xxxxx@ntdev…
>>> ok… applying ZwSetSecurityObject on pDeviceObjectTemp->Vpb-
>>> >DeviceObject yeilds a STATUS_NO_SECURITY_ON_OBJECT “Indicates an
>>> attempt was made to operate on the security of an object that does not
>>> have security associated with it.” So… that didn’t work. If the
>>> filesystem device object cannot have a security_descriptor how does
>>> DeviceTree show it having a DACL of everyone full access? I’m missing
>>> something. But out of ideas for now…
>>>
>>> Anyone have any suggestions?
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other 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
>

11

So it sounds like a simple file filter driver would be needed as well
to communicate between my device and this other device. Hmmm at least
it’s something to experiment with.

What exactly would the FILE_DEVICE_SECURE_OPEN have to be set on,
the filesystem device? Or something else. Any good recommended
readings on the subject?

Thanks.

Sent from my iPhone

Brian

On Apr 13, 2010, at 5:58 AM, “Scott Noone” wrote:

>> Is there a way to bridge that gap? Ie set a sddl string on "c:"
>> and all of it’s child objects/containers from the kernel,
>> specifically my disk filter?
>
> That’s exactly what the FILE_DEVICE_SECURE_OPEN device object flag
> does, so if you could somehow convince the FS to set this bit then
> it would work. But, I don’t think that there’s any way to do that,
> so you’d need a filter that would perform the access check for every
> open.
>
> I’ll warn though that this won’t likely lead to the results that you
> expect. Lots of applications ask for write access even though then
> never plan on writing to the file. In fact, for application
> compatibility reasons neither FAT nor NTFS fail opens with write
> access on read only volumes.
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “Brian” wrote in message news:xxxxx@ntdev…
>> Thanks Scott.
>>
>> Is there a way to bridge that gap? Ie set a sddl string on "c:"
>> and all of it’s child objects/containers from the kernel,
>> specifically my disk filter? For example my driver already
>> determined the drive letter that matches the partition I
>> physically filter over. I appreciate your comments.
>>
>> Sent from my iPhone
>>
>> Brian
>>
>> On Apr 13, 2010, at 4:36 AM, “Scott Noone” wrote:
>>
>>> You’re up the wrong tree I think. Security only applies to named
>>> objects, the non-control FS device objects (like the one you got
>>> out of the VPB) are unnamed.
>>>
>>> I don’t have the code in front of me, but I suspect that Device
>>> Tree is just showing the default DACL since there’s no security
>>> on the object.
>>>
>>> All that you’re doing with locking down the disk/partition/volume
>>> devices is locking down raw access to the volume. So, if the user
>>> opens “c:” then your security descriptor will be applied.
>>> However, if the user opens "c:" then the access check is not
>>> performed. At that point it becomes the job of the file system to
>>> enforce the security and you’re in the realm of a file system
>>> filter driver.
>>>
>>> -scott
>>>
>>> –
>>> Scott Noone
>>> Consulting Associate
>>> OSR Open Systems Resources, Inc.
>>> http://www.osronline.com
>>>
>>>
>>> wrote in message news:xxxxx@ntdev…
>>>> ok… applying ZwSetSecurityObject on pDeviceObjectTemp-
>>>> >Vpb-
>>>> >DeviceObject yeilds a STATUS_NO_SECURITY_ON_OBJECT “Indicates an
>>>> attempt was made to operate on the security of an object that
>>>> does not have security associated with it.” So… that didn’t
>>>> work. If the filesystem device object cannot have a
>>>> security_descriptor how does DeviceTree show it having a DACL of
>>>> everyone full access? I’m missing something. But out of ideas
>>>> for now…
>>>>
>>>> Anyone have any suggestions?
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other 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
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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

12

Yes, on the file system device. You don’t own that device object though so
setting flags on it might not be the best idea. A cleaner solution would be
to do the security checks yourself from a filter. This will also give you
finer control to selectively exclude things that won’t be happy about the
restriction.

The particular behavior that I’m talking about is described here:

http://msdn.microsoft.com/en-us/library/ff542068(VS.85).aspx

Aside from that, the usual reading suggestions apply (Windows Internals, the
WDM book, etc) paying close attention to the object manager and security
reference monitor sections.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Brian” wrote in message news:xxxxx@ntdev…
> So it sounds like a simple file filter driver would be needed as well to
> communicate between my device and this other device. Hmmm at least it’s
> something to experiment with.
>
> What exactly would the FILE_DEVICE_SECURE_OPEN have to be set on, the
> filesystem device? Or something else. Any good recommended readings on
> the subject?
>
> Thanks.
>
> Sent from my iPhone
>
> Brian
>
>
> On Apr 13, 2010, at 5:58 AM, “Scott Noone” wrote:
>
>>> Is there a way to bridge that gap? Ie set a sddl string on "c:" and
>>> all of it’s child objects/containers from the kernel, specifically my
>>> disk filter?
>>
>> That’s exactly what the FILE_DEVICE_SECURE_OPEN device object flag does,
>> so if you could somehow convince the FS to set this bit then it would
>> work. But, I don’t think that there’s any way to do that, so you’d need
>> a filter that would perform the access check for every open.
>>
>> I’ll warn though that this won’t likely lead to the results that you
>> expect. Lots of applications ask for write access even though then never
>> plan on writing to the file. In fact, for application compatibility
>> reasons neither FAT nor NTFS fail opens with write access on read only
>> volumes.
>>
>> -scott
>>
>> –
>> Scott Noone
>> Consulting Associate
>> OSR Open Systems Resources, Inc.
>> http://www.osronline.com
>>
>>
>> “Brian” wrote in message news:xxxxx@ntdev…
>>> Thanks Scott.
>>>
>>> Is there a way to bridge that gap? Ie set a sddl string on "c:" and
>>> all of it’s child objects/containers from the kernel, specifically my
>>> disk filter? For example my driver already determined the drive
>>> letter that matches the partition I physically filter over. I
>>> appreciate your comments.
>>>
>>> Sent from my iPhone
>>>
>>> Brian
>>>
>>> On Apr 13, 2010, at 4:36 AM, “Scott Noone” wrote:
>>>
>>>> You’re up the wrong tree I think. Security only applies to named
>>>> objects, the non-control FS device objects (like the one you got out
>>>> of the VPB) are unnamed.
>>>>
>>>> I don’t have the code in front of me, but I suspect that Device Tree
>>>> is just showing the default DACL since there’s no security on the
>>>> object.
>>>>
>>>> All that you’re doing with locking down the disk/partition/volume
>>>> devices is locking down raw access to the volume. So, if the user
>>>> opens “c:” then your security descriptor will be applied. However, if
>>>> the user opens "c:" then the access check is not performed. At that
>>>> point it becomes the job of the file system to enforce the security
>>>> and you’re in the realm of a file system filter driver.
>>>>
>>>> -scott
>>>>
>>>> –
>>>> Scott Noone
>>>> Consulting Associate
>>>> OSR Open Systems Resources, Inc.
>>>> http://www.osronline.com
>>>>
>>>>
>>>> wrote in message news:xxxxx@ntdev…
>>>>> ok… applying ZwSetSecurityObject on pDeviceObjectTemp-
>>>>> >Vpb-
>>>>> >DeviceObject yeilds a STATUS_NO_SECURITY_ON_OBJECT “Indicates an
>>>>> attempt was made to operate on the security of an object that does
>>>>> not have security associated with it.” So… that didn’t work. If
>>>>> the filesystem device object cannot have a security_descriptor how
>>>>> does DeviceTree show it having a DACL of everyone full access? I’m
>>>>> missing something. But out of ideas for now…
>>>>>
>>>>> Anyone have any suggestions?
>>>>
>>>> —
>>>> NTDEV is sponsored by OSR
>>>>
>>>> For our schedule of WDF, WDM, debugging and other 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
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other 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
>

13

> Is there a way to bridge that gap? Ie set a sddl string

Forget ACLs if you want to have read-only disk. The interface between the disk and the FSD will ignore any ACLs.

Just filter the partition and fail IOCTL_DISK_IS_WRITABLE.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

14

Thanks for the idea Maxim.

Sent from my iPhone

Brian

On Apr 14, 2010, at 12:00 AM, “Maxim S. Shatskih” > wrote:

>> Is there a way to bridge that gap? Ie set a sddl string
>
> Forget ACLs if you want to have read-only disk. The interface
> between the disk and the FSD will ignore any ACLs.
>
> Just filter the partition and fail IOCTL_DISK_IS_WRITABLE.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other 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