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

[James Sutherland]

On Thu, 10 Feb 2000, Nicolas Williams wrote:

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

How would you know WHICH M$ server you are talking about, anyway?! :-)

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

Like the registry, for example, which does have ACLs and kernel controlled
access, and contains the data in question?

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

Worse than useless, IMO - you do NOT want users to have access to the
FILE, only (some of) the contents - and only when accessed via RPC, NOT
when access as files...

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

Agreed - if Unix file permissions are used, then either users have full
access to the entire SAM file, or no access to it at all. Neither is
really desirable, I suspect? :)

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

James.