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

[Luke Kenneth Casson Leighton]

On Tue, 8 Feb 2000, Nicolas Williams wrote:

> 
> BTW, I knew that you'd respond as below. :)

 he he :)
 
> Wait a minute. The goal, ultimately, is to have ONE set of MSRPC daemons
> for ALL smbds on a host, not what you have now (ONE set of MSRPC daemons
> for EACH smbd on a host).

don't forget any client-side msrpc connections that smbd may make, too,
not just the pass-through-on-loop-back stuff!
 
> Once you get to your stated destination you'll not have to worry about
> how to start those MSRPC daemons: /etc/init.d/ scripts will take care of
> that.
> 
> As for the way TNG does this now, with each smbd fork()/exec()ing the
> MSRPC daemons as necessary, smbd should become_root() before starting
> them.

uhh... yes,

> As for rpcclient it should ALWAYS do DCE/RPC calls via SMB, even when
> running on the host that would be servicing those calls. So forget about
> linking in server-side code into rpcclient. So that's a non-issue.

? why?  that's a silly restriction [always doing dce/rpc via smb].

 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!),

unix# bin/rpcclient -S . -U root%dummypassword -l log
[root at .$ ]

and i get an rpcclient prompt, and i can do the equivalent of an su like
this:

unix# bin/rpcclient -S . -U someuser%nopassword -l log
[someuser at . $]

and issue rpc commands in the security context of someuser.

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.

> > > The SAM RPC daemon should always run as root.
> > 
> > andrew keeps telling me that _All_ the msrpc daemons should run as root,
> > because the only reason that smbd doesn't run as root is because of
> > file-create atomicity issues (in posix, you can't create a file as root
> > and then chown it to another user, atomically, which introduces race
> > conditions).
> 
> He's right about why SMBD needs to do become_root()/unbecome_root().

[actually, become_user(), not become_root()]
 
> SMBD exports a filesystem and so can make use of POSIX features
> (uid/euig/gid/egid/getgroups()/setgroups()) to let the Unix kernel do as
> much of the work of authorization as possible.

yep.

> MSRPC daemons export a set of functions and whether or not each daemon
> can take advantage of POSIX semantics to implement any part of the MSRPC
> authorization semantics is an issue that is specific to the
> implementation of each MSRPC daemon. See below.

uhh... no it isn't [up to each msrpc daemon].  it's up to the
security-context-switching code.

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.

 
> > well, the same reasons apply.  any msrpc daemon that creates files
> > (spoolss being the only one at the moment) or spawns programs (spoolss and
> > svcctl being the only ones... IF you damn well choose to RUN svcctl. WHICH
> > you don't have to] should also not be run as root.
> 
> And you're right that it is conceivable that some MSRPC daemons should
> change privileges as well.

yes, i'm not saying that msrpc daemons _shouldn't_ switch to root, if they
need to.

> [BTW, Unix spoolers never run as the user
> that launched each job. Nor does ypserv ever switch to the calling
> user's uid/gid. I could go on.]

> > basically, MSRPC is a remote function call mechanism.  if the caller is
> > root, the remote function call is root.  if the caller is a threaded
> > applcication, the remote function call is a threaded implementation.  if
> > the caller is user-foo, the remote function call is user-foo.
> 
> LSA simply does SAM/NETLOGON calls on behalf of the client -- the
> client's POSIX uid has no impact on this.

... 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.

you are aware of LsaRetrievePrivateData, LsaSetPrivateData,
LsasomethinglikeCreateUserAccount.

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.

so an anonymous user connecting to \PIPE\samr can add user accounts to a
SAM database.

> 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().

 
> 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.

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().

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)