DCE/RPC service security design [was: Re: usermgr problems]
Luke Kenneth Casson Leighton
lkcl at samba-tng.org
Tue Sep 18 06:36:06 GMT 2001
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
More information about the samba-technical
mailing list