[s4] Access Control Rights musings

[Nadezhda Ivanova]

On Fri, Mar 26, 2010 at 1:24 PM, Andrew Bartlett <abartlet at samba.org> wrote:

> On Thu, 2010-03-25 at 17:25 +0200, Nadezhda Ivanova wrote:
> > Hi all,
> > My apologies for the 10-tomed "Mission Earth" I am dumping on you, but I
> > would appreciate at least a cursory glance, to make sure I haven't missed
> > something important.
> > This is a list of references and short explanations about Access Control
> > Rights and when the system needs to check them, and my opinion if they
> are
> > relevant to our implementation. I suppose it could be useful to all of
> us,
> > since I may not always be able to add access checks fast enough in the
> > appropriate place in the code so other people may need to help. Also
> perhaps
> > you can help me decide which ones are actually relevant. I am not sure if
> we
> > need them all for interoperability...
> > I dont know if I should should add all of these that are relevant to the
> > TODO list, to keep track of what we have.
> >
> > *The following are rights that we definitely need to check for:*
> >
> > *Add-GUID* - Extended right needed at the NC root to add an object with a
> > specific GUID. If the requester specifies an object guid when adding an
> > object, they must have this access right on the NC. A few other
> conditions
> > must be met as well, see MS-ADTS 3.1.15.2.1 for reference. I am not sure
> if
> > we currently always disallow specifying objectGuids, and if we do, where
> > it's done...
>
> repl_meta_data disallows it, unless 'relax' is specified.  I think there
> is also a 'DS behaviour' bit that should also be checked'
>

So, does it make sense to do a few tests without this explicit disallow, but
with checking for
an access right + the additional conditions and see if we get the same
behavior. Not sure if it would
break the openLDAP backend though...

>
> > Kerberos:
> > Allowed-To-Authenticate - The control access right controls who can
> > authenticate to a particular machine or service. It basically lives on
> > computer, user and InetOrgPerson objects. It is also applicable on the
> > domain object if access is allowed for the entire domain we. It can be
> > applied to OU's to permit users to be able to set inheritable ACE's on
> OU's
> > containing a set of user/computer objects.  This one is referenced in
> > MS-KILE 3.3.5.4 TGS Exchange and MS-SFU 4.3, both documents are about
> > Kerberos protocol extensions, so maybe abartlet can take a look and say
> if
> > they are relevant.
>
> Perhaps this is about using the KDC to control access to a service that
> does not do good internal access control?  If the KDC won't give you a
> ticket, you don't have to trust that the in-house written app can decode
> the PAC and check that you are really an administrator.  (For example).
> It's a complete abuse of Kerberos, but it probably works :-)
>
> It would need to be checked in the KDC before we issue a ticket to a
> particular service.
>

Well, if you decide to go into this and need my help, lust let me know. I am
completely
ignorant here, would not even know how to test it.



>
> Andrew Bartlett
>
> --
> Andrew Bartlett                                http://samba.org/~abartlet/<http://samba.org/%7Eabartlet/>
> Authentication Developer, Samba Team           http://samba.org
> Samba Developer, Cisco Inc.
>
>