SYSKEY, TNG freeze, 2.0.x->TNG merge and other thoughts

[Luke Kenneth Casson Leighton]

> >  1) for test purposes and if i want, as root, to bypass SMB authentication
> > stages (which may not be up or working, say, if i have broken netlogond or
> > don't _have_ one!),
> 
> Ok. So for testing have rpcclient on the localhost talk to the MSRPC
> daemons directly via the Unix domain sockets.

correct.

> That would cut SMBD out of
> the picture and you still don't have to link in the MSRPC server-side
> code in rpcclient.

yep.  i was just giving you an example (simple one) of how to implement
ncalrpc in a [bad] way, the dlopen / dlsym oway is a better example.
 
> This is for testing, so you don't have to be strict about authenticating
> rpcclient's user (which would otherwise have been done by SMBD).

.... i'm taking "advantage" of the unix-socket-loopback code.

> > 2) i may end up replacing the unix-socket-loopback code (as a compile-time
> > option) with this:
> > 
> > 
> > uint32 samr_open_domain(...)
> > {
> > 	return dlsym(dlopen("libsmbsampass.so"), "_samr_open_domain")(...)
> > }
> > 
> > this is a perfectly feasible and rational thing to do.  it also means i
> > can't assume that libsmbsampass.so will always be run in a root security
> > context.
> 
> So you finally read the man pages for dlopen()/dlsym() and thought them
> to be cool :)

um, i didn't read them, but people keep telling me about them :)
 
> Ok, but then, while this goes along with the modularity of TNG, it does
> not help reduce resource consumption as much as having a separate set of
> MSRPC daemon processes, one set per server host, that SMBD talks to via
> DCE/RPC over local IPC.

true :)
 
> > if you have multiple smbd connections to one msrpc daemon, users are going
> > to get _very_ unhappy if they don't have their own user security context.
> 
> We've already settled that point by having SMBD pass in PID/VUID
> information with the DCE/RPC calls and storing the user context info in
> a TDB keyed by PID/VUID.
> 
> Why rehash this?

we're not.

when you receive an MSRPC PDU, it comes in with a context_id in it.  i
overload that with the VUID, and do a become_vuser(context_id), thereby
ensuring that the  remote function call has EXACTLY the same setuid /
setgit / simulated-NT-security-context as the local function caller
environment.

 
> So the MSRPC daemons will have access to the user context information.

yes.

> They have to implement authorization functionality internally because

no.  they don't.  see rpc_server/srv_pipe_ntlmssp.c api_pipe_verify().
this is (should be) exactly the same code as in smbd/reply.c
reply_sesssetup_x().  call domain_client_validate(), obtain a
NET_USER_INFO3, obtain uid/gid/getgroups, create a user_struct, do a
become_vuser().

otherwise, if the msrpc daemon was fired up from smbd, the msrpc daemon
INHERITS the sec_ctx of the smbd process, it doesn't _do_ authorisation
itself, it trusts that the msrpc loop-back interface hasn't been
compromised because it's root-only-access.

> the objects which most of those MSRPC daemons deal with are NOT Unix
> kernel objects (files, pipes, Unix sockets, processes, whatever); if
> those objects are not Unix kernel objects then switching Unix security
> contexts (euid/egid) HAS NO EFFECT.


> Why rehash this?

because i am not thinking in terms of _just_ NT, here, any more.  i'm
thinking in terms of a proper dce/rpc full implementation.  except,
without the thread library, for now.

 
> > yes, i'm not saying that msrpc daemons _shouldn't_ switch to root, if they
> > need to.
> 
> Ok. But I'm saying that neither LSA, nor SAM nor NETLOGON need to run as
> any user other than root.

need?  what has the need of three little services that _use_ dce/rpc got
to do with the design of a dce/rpc implementation [dce/rpc the mechanism
itself is different from dce/rpc-based services themselves].

> > ... not quite.  we have to inherit the security context of the smbd
> > process.  the smbd sec-ctx (POSIX uid) is mapped one-to-one to an NT
> > sec-ctx, and that's the way i want it to stay.  i do NOT want to have to
> > code up one POSIX uid [root] mapping to multiple [any] NT sec-ctx [SID].
> > there's too much work involved.
> 
> See above. The context is passed in by SMBD via the PID/VUID and the TDB
> record indexed by the same. But switching the POSIX context will turn
> out to be a usless thing to do, most of the time.

no it won't.  there are currently 9 msrpc daemons.  only 3 of them, IF the
implemeters choose to, HAVE to, at some point, jump to root, OR, if the
implementers choose to, CAN run as root all the time.

if you're suggesting that just because _some_ msrpc service
implementations _should_, in your opinion (and a few others), be run as
root, that the entire MSRPC service-running-system _must_ run _all_
services as root, then i have to say, that's silly.

> See above.
> 
> > you are aware of LsaRetrievePrivateData, LsaSetPrivateData,
> > LsasomethinglikeCreateUserAccount.
> 
> No. I was not. I looked at your book. They're not listed in it, thus I
> did not know about them.

i found out about them when someone requested doing a SvcCreateService
function.  NT threw all sorts of wobbly-looking LSAs at me on the network,
and i freaked out, and told them i couldn't do a SvcCreateService right
now.

that was four months ago.
 
> > you want me to run these as root?  fine, i'll run them as root.  then,
> > when they call Samr functions, those will be run as root, too.
> 
> Yes, if the those items are records in a larger database. No if those
> items are _files_ in a Unix filesystem. By 'items' I mean the
> 'PrivateData' referred to in the function names you list above.

well, createuseraccount, say.

so, what you're saying is, it's an implementation-specific issue, on a
per-msrpc-daemon basis?

because if so, why [as it seems] are you suggesting that i only run
msrpc-service-running as root, and drop the become_vuid() function call?
 
> Of course, if you store those items in a database with other user's
> items, then you'll have to implement your own authorization mechanism.

... *sigh*...

> If the items are kept as individual files then you _can_ let Unix do
> access control, in which case the LSA daemon must switch POSIX security
> contexts.

separate the concepts of msrpc-service-running from
msrpc-service-implementation and then let's go over this, again.
 
> > so an anonymous user connecting to \PIPE\samr can add user accounts to a
> > SAM database.
> 
> No, why? LSA would know the security context of the caller from the
> PID/VUID passed in by the intermediate SMBD and TDB record indexed by
> that PID/VUID tuple and it would know that the caller is anonymous and
> so would deny access as appropriate.

yeah.  that's implementing an entire NT security model, including access
right checks, inside samba.

i _really_, _really_ don't want to have to do that... _right_ now.  do you
have any idea how much work would be involved?  there are well over 100
msrpc-service-functions in samba in all 9 msrpc daemons.

no thank you.  not today.

therefore, i am "thunking" NT to unix, maintaining one-to-one mapping
between NT security contexts and unix security contexts, as the first
implementation.

> > > Similarly with NETLOGON.
> > 
> > no,  NETLOGON should only become_root() to  call _samr_query_userinfo(),
> > _samr_set_userinfo() to obtain or set user passwords. unbecome_root().
> 
> I disagree. NETLOGON should always run as root.

that's just one implementation of a netlogon daemon, nico.  doesn't mean
_all_ nelogonds should be root.
 
> Let me ask you a question: how does NT do it? Do the equivalent NT
> services (the processes that implement them) ever switch security
> contexts? Or do they always run privileged?

MSRPC connections to NETLOGON are anonymous (over SMB IPC$).

however, microsoft run the NETLOGON services at the SYSTEM context in
order to be able to access SYSTEM-ACL-locked functions, such as
SamQueryUserInfo(level 0x12) in SAMSRV.DLL.

answer: don't know.  i can make a guess.
 
> > > SAM accesses a database the same way no matter who is making the SAM
> > > calls (I mean at the system call level). SAM will need to do
> > > authorization internally; no Unix authorization mechanism will change
> > > this (unless you use a filesystem as a database -- as opposed to TDB or
> > > LDAP -- but that has its problems and is a non-starter, I bet).
> > 
> > tdb _is_ a filesystem-based database, and yes: i am relying on the unix
> > security context to provide me with samtdb access authorisation.
> 
> No, you misunderstood. TDB is stored in a file, but each TDB record is
> represented as data in that file, not as a _separate_ file. I.e., TDB is
> not a directory/file hierarchy with each record being stored as a
> _separate_ file!!

well, actually, i _was_ considering doing exactly that...
 
> > an anonymous user is mapped to the guest account.  if the guest account
> > doesn't have write permission on S-1-5-21-xxx-xxx-xxx.usr.tdb, they can't
> > do any damage to user accounts or modify the SAM database in any way.
> > 
> > like i said earlier, the only reason to allow become_root() is to do an
> > _samr_set_userinfo() at level 0x12 or an _samr_query_userinfo() at level
> > 0x12, which return or set the user LM#/NT# direct unbecome_root().
> 
> If you always run as root you don't need to do this.
> 
> > in the entire samtdb code, there _aren't_ any become_root / unbecome_root
> > calls (except from cut/paste from srv_samr_passdb.c, which i haven't got
> > round to removing)
> 
> Good, so it works then? Always running as root?

no, it runs as the smbd-connected security context, which is usually
anonymous!

i've designed the samtdb implementation so that the tdb files are all 644,
and owned by root.

i _may_ change this, based on what i find out with the rpcclient
samquerysec command on individual user accounts.

ok, the _owner_ of the invidual user account infos is S-1-5-32-544, which
is Administrators.

the _user_ themselves have "create" and "Readcontrol" permissions.  i.e
they can create a user password, and they can read their own user profile.

> (BTW, I don't want to get too adversarial here; I don't know you personally.)

no problem, nico :)