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

[Luke Kenneth Casson Leighton]

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

i choose to implement, in sambtdb, the "objects" in terms of unix files,
because those are the only kinds of "objects" in unix that i hav e that
will obey "unix" security.

from various discussions with people here, this i know, this i trust,
therefore this i follow.

i don't know what you're talking about with seteuid(), but i do know that
if smbd does a become_user(), and i transfer sufficient info across to
samrd to _Also_ do the same become_user(), and i then set up samtdb
withthe SAM database as files, i will be able to set up unix file
permissions on the SAM database files, and not have to piss about creating
a comprehensive NT security-access system that i'm just not ready to deal
with, right now.

we have _enough_ code sitting around doing bugger-all without adding
ANOTHER major set of functionality that will delay the introduction of nt
domain functionality for unix / samba.

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

who said i am doing a seteuid()? i didn't.

i said i'm doing a become_user().  exactly what that does i actually
couldn't care less.  if smbd trust5s become_user to do the right job, then
so do i, in the msrpc daemons.
 
> > 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).

that's one implemtation.  i choose not to implement it that way.
 
> > 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;
> }

yes.  i know that.  i've known that for about a year.  i know exactly how
it _should_ be implemented.

i expect the implemtation to delay the introduction of tng by several
months, whilst we work out exactly what all the this_object's for every
single function call and info level.

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

wrong [to the default = no bit, see other message]

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

yes.  actually, it's just one function call, identical parameters and
functionality to its NT equivalent.
 
> 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.

yep!