ACL / SDs

[Todd Sabin]

"Michael Stockman" <pgmtekn-micke at algonet.se> writes:

> Hello,
> 
> > Luke Kenneth Casson Leighton <lkcl at samba.org> writes:
> >
> > > > > > Well, even NT has banned them from ACLs. Don't let the fact
> that the
> > > > > > code is the same in NT hide the fact that the bitmask in
> ACLs is a
> > > > > > different bitmask from that by which you request a set of
> permissions.
> > > >
> > > > Actually, this isn't true; they're not banned at all, AFAICS.
> At the
> > > > very least, the SDs for lots of registry keys in NT5 definitely
> > > > contain ACEs with some of the GENERIC_* bits set.  They're
> primarily
> > > > in inherit-only ACEs, but they're there, none the less.
> 
> I can't see what they would mean. Surely, not even NT would allow
> security on an object to be set to some generic value that noone can
> more than guess what it evaluates to when access is evaluated.
> 

Yes, NT does, though I haven't seen any except in INHERIT_ONLY ACEs.
For those, presumably it means that when you create a child object of
this object (which may be of different object type), then add an ACE
to the new object which grants/denies that object type's GENERIC_x
permissions.  This isn't all that different than CREATOR/OWNER, which
is completely meaningless except in terms of inheritance.

> > > See GenericPermissions arg of SeAccessCheck.  this is different
> from bits
> > > 16 to 32 in an ACE.
> > >
> >
> > No, the top four bits of an access_mask are GENERIC_READ,
> > GENERIC_WRITE, GENERIC_EXECUTE, and GENERIC_ALL.  The GenericMapping
> > arg tells how those things map into specific access rights.  e.g.,
> > for LsaPolicy, GENERIC_EXECUTE -> (POLICY_VIEW_LOCAL_INFORMATION
> >                                    | POLICY_LOOKUP_NAMES
> >                                    | STANDARD_RIGHTS_EXECUTE)
> > (STANDARD_RIGHTS_EXECUTE == READ_CONTROL)
> >
> > I'm not sure how this plays out in practice.  I had thought that the
> > generic mapping was mainly a UI mechanism, so the ACL editor could
> > hide details.  However, I've seen ACEs in NT5 that have some of the
> > GENERIC_* bits set.  Usually, they're for inherit-only ACEs, though.
> > I've never seen any place that uses the GENERIC_* bits in a
> > DesiredAccess.  I wonder what would happen if you did?
> 
> Probably nothing. AccessCheck does explicitly say (in the Win32 API
> documentation) that the generic bits must not be set in the
> desired_access field.
> 

Actually, I have to retract my previous statement.  As of a few days
ago, I have seen calls which request 0x80000000 for a DesiredAccess,
and they're handled just fine by NT.  Presumably, that means that the
requester wants whatever the GENERIC_READ permissions are on the
object.  The case where I've seen it was for registry keys.

Here's another permutation to think about: what does it mean if I
request MAXIMUM_ALLOWED along with some other bits,
e.g. (MAXIMUM_ALLOWED | FILE_READ)?  Is that invalid, or does it mean
I want the MAXIMUM_ALLOWED (provided that includes FILE_READ),
otherwise give me access_denied.  What about (MAXIMUM_ALLOWED |
GENERIC_READ)?

It definitely looks like someone needs to do some extensive testing...


Todd