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

[tridge at linuxcare.com]

> [Forall(Arguments where security-context exists) apply same
> logic-reasoning/justifications that are in smbd, to msrpc daemons].
> 
> ehh?  so... what does become_user() do, then?  and why am i doing a
> become_user() in the msrpc code?  because it's done in smbd, that's why.

it is done in smbd because smbd serves files. files are protected by
the unix security context. msrpc objects aren't.

> well, i take it that in smbd we don't allow code patches that do
> seteuid(time(NULL)), right???

thats right. We also shouldn't allow patches that do
seteuid(ntcontextid). Both would be wrong. Both are "harmless" in that
they don't actually break anything, but both give the impression that
something is being protected. In both cases that impression would be
wrong.

> because in srv_samr_dom_tdb.c:_samr_open_domain(), the unix user to which
> the anonymous user has been mapped does not have write permission to open
> the S-1-5-21-xxx-xxx-xxx.usr.tdb file, because its permissions are
> rw-r--r-- and it's owned by root.

this trick gives you two security contexts - those that have write
permission on system files are those that don't. 

if thats all you want then you should do a seteuid() to the uid of the
guest user. You would not even look at what uid the user is
authenticated as, you would just look at anonymous or non-anonymous.

even if this is all you want, then it is still the wrong way to go about
it. It is using a side effect in a way that is not at all obvious,
which is always a very bad thing to do with security. Instead it would
be miles better to do:

if (this_is_an_anonymous_connection) {
   return ACCESS_DENIED;
}

that makes it explicit in the code, and doesn't require the rather
complex maneuvering in the uid handling code in smbd.

> not now.  it will take weeks to implement and integrate into all of the
> tng functions.  there's well over a hundred of them, andrew.

if it takes weeks, then you are approaching it in the wrong way. For
example, what if you have a table in one place, giving the names of
the functions and a set of flags that says whether the function can be
run on an anonymous connection. Default all of them to no.

see the smb_messages[] table in smbd/process.c for an example of how
to do this. It makes it clear what can and can't be done, and is
really quick to implement.

Cheers, Tridge