Security Descriptors

NTFSD
1

Hi, all,

In a FS filter (currently legacy), we define I/O codes for all
file I/O we are interested in (CREATE, OPEN, REPLACE, READ, WRITE,
DELETE, RENAME, HIDE) - these have no direct mapping to the standard I/O
mapping as used by security descriptors.

A user successfully builds a security descriptor with 0x7FFFFE
access for Everyone and 0x200 Deny access for TestUser. When the driver
does an SeAccessCheck with this security descriptor however, it always
returns TRUE - am I missing something here, or is it only that
SeAccessCheck only supports default access masks?
When I query back the security descriptor from the driver and
decode it, it is the correct SD (with the same access as described
above).
The check is done as follows:
SeAccessCheck(lpEntry->lpSD,
&lpSubjectContext,
TRUE,
FileOperation, // 0x200
0,
NULL,
&GenMap,
kpMode,
&amGrantedAccess,
&amResult)
returns TRUE and amGrantedAccess always returns TRUE.
kpMode is UserMode, so the check is not “skipped” due to kernel mode
code.
The denied part of the SD should take precedence over allowed, but it
doesn’t seem to be the case above.

–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

2

What is the order of the ACE entries in the ACL? This IS important -
the moment enough ACE entries have been processed to grant access, the
rest of the entries are ignored. Similarly, the moment any ACE entry
denies access to a required right access is denied and the rest of the
entries are ignored.

Here’s a decent enough description:
http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAnAccessC
ontrolList.html

And I think there is a comparable explanation in the Platform SDK. The
IFS Kit and DDK have very little in the way of security documentation
(there’s a few *brilliant* articles in the IFS Kit though. :wink: )

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Wednesday, December 28, 2005 1:31 PM
To: ntfsd redirect
Subject: [ntfsd] Security Descriptors

Hi, all,

In a FS filter (currently legacy), we define I/O codes for all
file I/O we are interested in (CREATE, OPEN, REPLACE, READ, WRITE,
DELETE, RENAME, HIDE) - these have no direct mapping to the standard I/O
mapping as used by security descriptors.

A user successfully builds a security descriptor with 0x7FFFFE
access for Everyone and 0x200 Deny access for TestUser. When the driver
does an SeAccessCheck with this security descriptor however, it always
returns TRUE - am I missing something here, or is it only that
SeAccessCheck only supports default access masks?
When I query back the security descriptor from the driver and
decode it, it is the correct SD (with the same access as described
above).
The check is done as follows:
SeAccessCheck(lpEntry->lpSD,
&lpSubjectContext,
TRUE,
FileOperation, // 0x200
0,
NULL,
&GenMap,
kpMode,
&amGrantedAccess,
&amResult)
returns TRUE and amGrantedAccess always returns TRUE.
kpMode is UserMode, so the check is not “skipped” due to kernel
mode
code.
The denied part of the SD should take precedence over allowed,
but it
doesn’t seem to be the case above.

–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

How is the SD built? The AddxxxAce routines state that:

“These functions do not automatically place the new ACE in the proper
canonical order. It is the caller’s responsibility to ensure that the ACL is
in canonical order by adding ACEs in the proper sequence.”

If the Allow for Everyone was before the Deny for TestUser, it’s in the
wrong canonical order.

HTH,
Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Wednesday, December 28, 2005 1:31 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Security Descriptors

Hi, all,

In a FS filter (currently legacy), we define I/O codes for all
file I/O we are interested in (CREATE, OPEN, REPLACE, READ, WRITE,
DELETE, RENAME, HIDE) - these have no direct mapping to the standard I/O
mapping as used by security descriptors.

A user successfully builds a security descriptor with 0x7FFFFE
access for Everyone and 0x200 Deny access for TestUser. When the driver
does an SeAccessCheck with this security descriptor however, it always
returns TRUE - am I missing something here, or is it only that
SeAccessCheck only supports default access masks?
When I query back the security descriptor from the driver and
decode it, it is the correct SD (with the same access as described
above).
The check is done as follows:
SeAccessCheck(lpEntry->lpSD,
&lpSubjectContext,
TRUE,
FileOperation, // 0x200
0,
NULL,
&GenMap,
kpMode,
&amGrantedAccess,
&amResult)
returns TRUE and amGrantedAccess always returns TRUE.
kpMode is UserMode, so the check is not “skipped” due to kernel mode
code.
The denied part of the SD should take precedence over allowed, but
it
doesn’t seem to be the case above.

–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

<blushes…>
Yes, this was it. Thanks.

Ken Cross wrote:

> How is the SD built? The AddxxxAce routines state that:
>
> “These functions do not automatically place the new ACE in the proper
> canonical order. It is the caller’s responsibility to ensure that the ACL is
> in canonical order by adding ACEs in the proper sequence.”
>
> If the Allow for Everyone was before the Deny for TestUser, it’s in the
> wrong canonical order.

–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.</blushes…>

5

My understanding (for too long by all standards) was that deny ACEs override
allow ACEs, i.e. the entire SD being processed. This problem did not occur before
since each user had his ACE in the SD, this was the first time we had a case for
Everyone.
Thanks.

Tony Mason wrote:

What is the order of the ACE entries in the ACL? This IS important -
the moment enough ACE entries have been processed to grant access, the
rest of the entries are ignored. Similarly, the moment any ACE entry
denies access to a required right access is denied and the rest of the
entries are ignored.

Here’s a decent enough description:
http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAnAccessC
ontrolList.html

And I think there is a comparable explanation in the Platform SDK. The
IFS Kit and DDK have very little in the way of security documentation
(there’s a few *brilliant* articles in the IFS Kit though. :wink: )

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dejan Maksimovic
Sent: Wednesday, December 28, 2005 1:31 PM
To: ntfsd redirect
Subject: [ntfsd] Security Descriptors

Hi, all,

In a FS filter (currently legacy), we define I/O codes for all
file I/O we are interested in (CREATE, OPEN, REPLACE, READ, WRITE,
DELETE, RENAME, HIDE) - these have no direct mapping to the standard I/O
mapping as used by security descriptors.

A user successfully builds a security descriptor with 0x7FFFFE
access for Everyone and 0x200 Deny access for TestUser. When the driver
does an SeAccessCheck with this security descriptor however, it always
returns TRUE - am I missing something here, or is it only that
SeAccessCheck only supports default access masks?
When I query back the security descriptor from the driver and
decode it, it is the correct SD (with the same access as described
above).
The check is done as follows:
SeAccessCheck(lpEntry->lpSD,
&lpSubjectContext,
TRUE,
FileOperation, // 0x200
0,
NULL,
&GenMap,
kpMode,
&amGrantedAccess,
&amResult)
returns TRUE and amGrantedAccess always returns TRUE.
kpMode is UserMode, so the check is not “skipped” due to kernel
mode
code.
The denied part of the SD should take precedence over allowed,
but it
doesn’t seem to be the case above.

–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.

6

> My understanding (for too long by all standards) was that deny ACEs

override
allow ACEs, i.e. the entire SD being processed.

No, due to performance optimization, the ACE is processed ONLY until
first granted entry is found or first denied entry is found.

L.

7

> My understanding (for too long by all standards) was that deny ACEs

override
allow ACEs, i.e. the entire SD being processed.

No more than artifact of how some GUI type tool builds the ACL? :wink:

“Dejan Maksimovic” wrote in message news:xxxxx@ntfsd…
>
> Hi, all,
>
> In a FS filter (currently legacy), we define I/O codes for all
> file I/O we are interested in (CREATE, OPEN, REPLACE, READ, WRITE,
> DELETE, RENAME, HIDE) - these have no direct mapping to the standard I/O
> mapping as used by security descriptors.
>
> A user successfully builds a security descriptor with 0x7FFFFE
> access for Everyone and 0x200 Deny access for TestUser. When the driver
> does an SeAccessCheck with this security descriptor however, it always
> returns TRUE - am I missing something here, or is it only that
> SeAccessCheck only supports default access masks?
> When I query back the security descriptor from the driver and
> decode it, it is the correct SD (with the same access as described
> above).
> The check is done as follows:
> SeAccessCheck(lpEntry->lpSD,
> &lpSubjectContext,
> TRUE,
> FileOperation, // 0x200
> 0,
> NULL,
> &GenMap,
> kpMode,
> &amGrantedAccess,
> &amResult)
> returns TRUE and amGrantedAccess always returns TRUE.
> kpMode is UserMode, so the check is not “skipped” due to kernel mode
> code.
> The denied part of the SD should take precedence over allowed, but it
> doesn’t seem to be the case above.
>
> –
> Kind regards, Dejan M.
> http://www.alfasp.com E-mail: xxxxx@alfasp.com
> Alfa Transparent File Encryptor - Transparent file encryption services.
> Alfa File Protector - File protection and hiding library for Win32
> developers.
> Alfa File Monitor - File monitoring library for Win32 developers.
>
>

8

Probably :smiley:

Lyndon J Clarke wrote:

> My understanding (for too long by all standards) was that deny ACEs
> override
> allow ACEs, i.e. the entire SD being processed.

No more than artifact of how some GUI type tool builds the ACL? :wink:

–
Kind regards, Dejan M.
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.