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

[Nicolas Williams]

I'll make this quick. My hands are hurting.

I didn't say ALL MSRPC daemons need not bother switching euig/egid to
the caller's, but that LSA/NETLOGON/SAM certainly don't. I can imagine
that some MSRPC services would need to switch the Unix security context
to the caller's, say, like a remote application launcher (something like
Terminal Server, say, of which I know nothing).

But look, if Luke wants to put become_user()/unbecome_user() calls in
his code, they'll amount to nothing in most cases and so there will be
no isse; someday someone will notice the utter uselessness of those
calls and drop them. The only harm of using those calls will be:

 - possibly a false sense of security
 - possibly complicate any attempt to multi-thread those daemons

Now, my hands hurt, so I'll drop out of all of this for a while.

Oh, and, as for SYSKEY, I just realized yesterday that SYSKEY and
similar systems are going to be specific to each SAM database backend
implementation, not generic to Samba. E.g., Luke Howard's SAM with LDAP
with Windows 2000 schema will likely need to implement Microsoft's
system, not Luke's. So if Samba is to have its own SYSKEY system it
should really just be a library for some, not all, SAM implementations
to use.

Also, as for which TNG ideas to keep in a merge to a stable branch,
IMNSHO (I stress the 'NS' bit :):

 - Modular MSRPC external to SMBD using localhost IPC for communication
   between SMBD and MSRPC daemons, including the latest PID/VUID and
   standard_sub_vuser() stuff we've been talking about.

 - Marshalling/Unmarshalling code separated from the implementation
   functions. Preferably the MSRPC daemons should consist only of the
   marshalling/unmarshalling functions and should dlopen() the shared
   object that contains the implementation functions; this would allow
   SAM/LSA/NETLOGON implementation options be configurable via smb.conf
   instead of just compile-time options.

 - Multiple SAM backends (only one can run at a given time, of course).
   This capability is a result of the above two items. Same thing with
   LSA and NETLOGON implementations.

 - TNG's MSRPC implementations.

Again, IMNSHO. Bye for now,

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


On Thu, Feb 10, 2000 at 12:32:12AM +1100, tridge at linuxcare.com wrote:
> > 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.
> 
> I am so glad to see that somebody else understands this. It is a very
> important concept.
> 
> We have to decouple the unix security context from the RPC security
> context. We have the SMB and Unix security contexts coupled in smbd,
> but we get away with that because we are dealing with objects that the
> unix kernel knows about so the unix security handling does all the
> work for us. In msrpcd the situation is quite different as we are
> manipulating objects that have no parallel in the unix world - so we
> must not couple the security contexts or we end up relying on
> protection that the kernel just can't provide.
> 
> In NT things are different. There they have the objects in the kernel
> and the kernel knows how to protect them. The NT kernel security
> context provides protection of the objects manipulated by msrpc
> calls so there is no issues as to whether these two contexts should be
> coupled - they are the same thing. On non-NT systems we must design
> things quite differently.
> 
> Think about the above couple of points carefully Luke. They are central
> to what you are working on.
> 
> Cheers, Tridge
> 
> PS: I'm away for the next month - expect only occasional email
> responses.

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.