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

[Luke Kenneth Casson Leighton]

hiya kai,

thanks very much for responding: it's triggered enough
for me to consider writing up another article for
dcerpc.net.

On Mon, Sep 17, 2001 at 04:18:42PM +0200, Kai Krueger wrote:
 
> ----- Original Message -----
> From: "Luke Kenneth Casson Leighton" <lkcl at samba-tng.org> Sent: Monday,
> September 17, 2001 1:53 PM
> Subject: Re: usermgr problems
> 
> 
> > On Sun, Sep 16, 2001 at 12:15:35AM +0100, Tony Hoyle wrote:
> > > When I edit a user account using usermgr.exe it seems to only work if
> > > the user is logged in as Administrator (uid=0), but not logged in as tmh
> > > (uid=1000, and a Domain Admin).  Is this a limitation of the current
> > > version or have I configured something wrong?
> >
> > that sounds about right.
> 
> > > In the logs I get:
> > >
> > > samr_reply_set_userinfo2: rid:0x3ef
> > > ldap_connect: Connect denied: euid=1000 uid=0
> >   ^^^^^^^^^^^^
> >
> > uh... you didn't say you were using ldap.
> >
> > then, you have an ldap permissions issue.
> 
> this is as far as I know not completely correct s.b.
 
:)  hmm :)

> >
> > correct the ldap permissions issue in your ldap db:
> > you won't find anything in TNG to help you with this one.
> 
> I think this is not possible, as TNG always binds to the ldap db as user
> root with the username and password specified in the smbconf file. Therefor
> the ldap db can not distinguish between the users. So if you want to use TNG
> to change attributes of the sam database at all, you will have to give this
> user full write access.
 
okay :) listen to kai.

ignore me :)

> All security checking therefore has to be done in the sam code of TNG
> itself.
 
correct.  this is the case in freedce, DCE 1.22, unix dce/rpc services,
TNG dce/rpc services, NT's MSRPC services - it's _the_ way, the only
way, to do this.


> Until a couple of months ago (?) there was no checking at all in the
> TNG-ldap code, causing all users to be able to manipulate the entire sam
> database from usrmgr. This of cause was a major security risk. After I had
> mentioned this on tng-users, Elrond quickly came up with a basic security
> check. Instead of just putting a becomeroot() around the ldapcode so that
> everybody had write access, he changed it to only allowing uid=0 right
> access. This fixed the security issue very quickly (and easily) as now only
> root (or perhaps an other user mapped to root) has access, but it looses
> some flexibility. Other members of the domain admin group can now _not_
> manipulate the sam db anymore as they should be able to.

ahh..  good idea.

> I was thinking of implementing a better access check based on
> seaccesscheck(), 


yes!  that's the correct [read, more NT-like] way to do it.

> as I think this is an important feature, but it requires
> knowledge of the userinfo4 (is it 4?) 

3.  NET_USERINFO_3.

> structure of the user logged on and I
> never found a way to get this info in the relevant funktions.

the function you will need, if you examine _samr_connect()
in samrd/srv_samr_passdb.c, is get_sec_ctx().

this [in fact] now only returns a vuid int16, which was originally
created in get_user_creds (see msrpcd.c) with the user_struct
that came off-the named-pipe-emulation layer.  the user_struct
contains the NET_USERINFO_3 that you are looking for as one
of its member structures.

[yes, i know a NET_USERINFO_3 is overkill in some respects
until you examine api_RNetUserGetInfo() and api_RNetWkstaUserLogon()
in smbd/lanman.c, and then it's obvious as to why the NET_USERINFO_3
is being hauled about all over the place.  no, the implementations
of these two functions is not complete, they're filled with
dummy info when they should be filled with info contained in
the NET_USERINFO_3 structure, yes, i know.]

so, from the user_rid, group_rid and groups[], you can construct
one of the arguments to the seaccesscheck() function.

from the policy_hnd code... DAMMIT there's an access_mask
variable which is added, but i'm not sure that's a good idea.

anyway, _for now_, you'll need to add a function which takes
a policy handle and returns the access_mask, see util_hnd.c,
associated with it.

this is _another_ of the arguments to the seaccesscheck() function.

then, you will need to decide what type of operation is being
performed.  READ, WRITE, EXECUTE, ENUMERATE, etc. etc.  this
you will have to decide on a *per-function* basis.  it should
be pretty obvious, but not always.

e.g. _samr_delete_user, well *duur* that's a DELETE operation.

_samr_create_user, is a CREATE operation (check the se_access
bits, i haven't looked for a SE_CREATE #define)

_samr_enum_aliases, well, *duur* that's an ENUMERATE operation.
but is it also simultaneously a READ operation?

this is _another_ of the arguments to the seaccesscheck() function.

the permissions being requested by the various client programs
will give you a clue as to what's going on.

e.g. USRMGR.EXE as run by Admins tends to request READ|WRITE
in the _samr_open_domain().

then, each pipe will need an implementation of
[Pipename]GetSecObject() function - in the samr
case, that's _samr_get_sec_obj() which returns
a Security Descriptor.

in the case of smbpasswd, this is faked up and not used
_anyway_.

in the case of samrtdbd, this was going to be loaded out
of the tdb db on a per-user, per-group, per-alias, per-domain
and per-sam basis [which is the way it really has to be done,
substituting tdb for ldapdb, SQLdb etc etc].

so in the end, you could probably get away with creating
a MACRO, naming the GetSecObject function, the handle
to pass to it, etc.

relatively simply, but just a lot of them, and all hand-coded
[which explains all the security mistakes in NT]


> The other reason I didn't continue trying or asked the list was, that at
> that time there was a discussion about a major rewrite of the sam code. What
> happened to those efforts?
 
see http://dcerpc.net/proj/.

development of the next version of TNG services will begin there.

the reason for this is that we wish to get on with the
proper job, having learned enough to do a proper job.

kai if you, or anyone else, would like to help out on dcerpc.net,
please register a username there, fill in the public key field
with an ssh identity.pub, and i'll give you cvs access to one
of the projects, or set one up for you.

see http://dcerpc.net/cvs.xvl for cvs instructions (including
anon cvs).

i _have_ started a samrd project, there, which is stub for
most functions but with enough to demo for people to get
started.

luke howard, when he's finished his thesis end-of-october,
will begin samrnt5ldapd, which will be a parallel independent
project, run by him.

i haven't heard from jelmer recently but i created samrsqld
_anyway_.

we're going to _need_ that seaccesscheck() function, plus
support infrastructure [equivalent to vuid = get_sec_ctx()
followed by get_valid_user_struct(vuid)]

luke