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

[Nicolas Williams]

On Thu, Feb 10, 2000 at 09:00:55AM +1100, tridge at linuxcare.com wrote:
> > [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.

Though it is conceivable that some MSRPC objects might. See my previous
example of an MSRPC service to remotely start/stop applications on a
"terminal server" (I hate that term).

That said, while a SAM's files are protected by the kernel, yet the SAM
service must export access to the objects in the SAM files more
liberally than the Unix kernel protection of the files themselves. Thus
the SAM daemon must implement its own access controls on the actual
objects in those files because the Unix kernel knows nothing about those
objects (and, BTW, I doubt that the NT kernel can permission objects in
generic binary files; perhaps it can in _some_ structured binary
files).

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

Even if you mapped the NT SID+RID to a Unix UID that seteuid() will be
useless.

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

This trick is bad. The SAM daemon should only open its DB at startup and
after any event where it must close it for maintenance (say,
rewriting). Access to the records in SAM db must be controlled not by
the DB's file permissions but by code in the SAM daemon (and ACLs,
implicit or explicit, in the SAM DB).

> 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 only that, the code should look more like:

if (this_caller != owner_of_this_object && this_caller != administrator/root)
{
    return ACCESS_DENIED;
}

Or better yet:

if ( ! ACLeval(this_object, this_caller) )
{
    return ACCESS_DENIED;
}

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

Right. Or implement some rules and/or ACLs as above.

Besides, if you design the access control system correctly then you can
re-use it elsewhere (hint, hint; Luke appears to like this sort of
thought; make it a library).

Remember the mk_tdb concept I was sharing before? Now add a layer that
allows storing of ACLs and ACEs too and you've got a SAM_TDB concept
that's pretty complete.

> Cheers, Tridge


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.