DCE/RPC service security design [was: Re: usermgr problems]

[Luke Kenneth Casson Leighton]

On Mon, Sep 17, 2001 at 06:36:57PM +0200, Elrond wrote:
> On Mon, Sep 17, 2001 at 05:21:21PM +0200, Luke Kenneth Casson Leighton wrote:
> [...]
> 
> 
> Hi,
> 
> 
> IF someone is realy going to invest this stuff.
> 
> I can merge over the se_access_check from the "other
> place", they use it heavily now for printing and some other
> stuff, so it is likely to be correct.
 
needs that extra parameter which is the permissions of the handle.


> Their version doesn't any more accept a NET_USER_INFO_3,
> but instead an NT_USER_TOKEN, which is basicaly a list of
> SIDs.
> I can write code to generate that from a NET_USER_INFO_3.
 
that'd be v.good.


> I'm thinking about a caching get_current_nt_user_token(),
> which does caching by vuid. (vuid changes --> go recalc).
> 
> 
> The basic problems with samr are:
> 
> 
> We don't know the bits precisely!
 
use the generic ones only, but explore with samrquerysec
a bit to obtain a security descriptor from an NT PDC

then, don't _bother_ to find out what the bits are, just
pass the SD to se_access_check() with the "stuff" from
the various other sources, and that will - despite
any scepticism that you may have - Do The Job!

[as long as the modified se_access_check supports MAXIMUM_ALLOWED,
it will, anyway]/


> We have (or can get) the usualy Security Descriptors for
> the various objects.
 
yes.

> It _will_ be a lot of work.
 
well providing a fully function implementation of SamrQuerySecDesc()
actually cuts the percieved amount of work, drastically.

all that need be implemented, as both you and kai have
hinted at, is to return hard-coded security descriptors.


but the important thing is to do this in SamrQuerySecDesc()
on a _per handle_ basis.

i.e. for a SamrConnect handle, you return one sec desc
(and use samrquerysec on a connect handle to get one)

i.e. for a SamrDomain handle, you return one sec desc
(and use samrquerysec on a Domain handle to get one)

etc. etc.

it _does_ mean that it will be necessary to identify
handles by type.

elrond, yo added some code to specify a "name" associated
with a handle.  that's not ideal, but better than nothing.

better would be to have a state struct - like sockaddr - which
always has  an enum at the front - identifying the type of
the state info.

> 
> In the first run, we could try and ignore the access_masks
> on the handles. This is just an additional layer of
> access-control.
> The se_access_check in head anyway only has one
> desired_access field.
> 
> So for the first run, it would probably be easier to just
> the rights needed in the special case against the sec-desc.
> 
> This will allow for some nice things:
> 
> Even normal users will be able to double click on users in
> usrmgr.exe. With NT PDC this isn't possible, because
> usrmgr.exe requests RW when opening the user...
> 
> 
> Can people please comment?
> 
> 
> I don't want to merge over se_access_check, if nobody is
> really thinking about using it.
 

> 
>     Elrond