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

[Nicolas Williams]

On Wed, Feb 09, 2000 at 08:59:04AM +1100, Luke Kenneth Casson Leighton wrote:
> 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!

So?

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

Ok. So for testing have rpcclient on the localhost talk to the MSRPC
daemons directly via the Unix domain sockets. That would cut SMBD out of
the picture and you still don't have to link in the MSRPC server-side
code in rpcclient.

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

> 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 :)

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.

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

Yup.

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

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?

So the MSRPC daemons will have access to the user context information.
They have to implement authorization functionality internally because
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?

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

Ok. But I'm saying that neither LSA, nor SAM nor NETLOGON need to run as
any user other than root.

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

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

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

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

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

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

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?

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

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

Why argue then? :)

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

:)

Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.