ACL / SDs

[Michael Stockman]

Hello,

First I'd like to apologize if anyone got bitten my me managing to
seriously destroy our mail system this weekend. I lost some mail and
some might have got confusing bounces, sorry.

> > 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.

This is probably possible. Would solve some problems, but what a
complicated system they've managed to create. Is anyone sure it works
on NT? Would really not be necessary as long as an ACL is associated
with an object of a known type.

Obviously we'll need to keep them in the access_mask anyway.

> > > > 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.

Well, why would NT follow their own API?

> 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)?

Intuitively it would meant MAXIMUM_ALLOWED but other explicit
permissions must be granted or all fails.

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

I agree, although I don't have access to NT, so I can't do it. I'm
trying to code up REG_KEY_GET_SEC in samba, but I'll have to do some
other things this week too (except for work which I also have to do, I
don't have the luxury to work with samba or even programming right
now).

Best regards
  Michael Stockman
  pgmtekn-micke at algonet.se