dynamic context transitions

[Luke Kenneth Casson Leighton]

[selinux taken off cc because content is not relevant to that list]

On Sun, Nov 14, 2004 at 10:22:31PM +1100, Andrew Bartlett wrote:

> > i've said it before (and won't mention it again, i promise!) but
> > personally i believe it far more sensible [and this is a
> > practical solution that i believe could be done _now_ without
> > any samba or selinux code modifications, just some time writing
> > up the config files and policies] to run a samba-4 server with
> > an smb client vfs redirector going to a samba-3 back-end smbd
> > server on the same machine.
> 
> I'm actually not sure this helps - the samba-3 backend still needs to
> move to and from root.  

 printing being one, yes?

> In any case, that setup currently doesn't proxy
> the authentication (fixing that is on the todo list).  When it does, I
> don't think the problem changes.
> 
> What you want is a way to demultiplex the protocol stream based on VUID,

 yes - that was the aim [of using an smb proxy to another smbd server].


 and doing that [demultiplexing... VUID] would solve a lot
 more than just this problem: there's still the long-standing
 issue which is best shown up by having a multi-threaded
 win32 benchmark program, where you set up many threads all
 of which do reads and writes to massively large files, which
 get multiplexed down to a single smbd.

 under these circumstances you end up with one thread hogging
 all the bandwidth until the large file write from one thread
 is completed, and then one other random client thread ends up being
 activated.

 ... not exactly expected behaviour!


> but even if we get that (and perhaps the 'terminal server' case will
> cause such a proxy to be written), we still have the problem of needing
> to become root for some operations.  

 well (as you and others are in a position to appreciate)
 i really don't want to get into this in detail but i think
 you will find that if you follow the tng architecture -
 namely to split services out into separate daemons - then
 that problem goes away.

 from an selinux security perspective, the tng architecture
 is much more amenable to being "locked down".  each service
 (e.g. spoolssd) can be given access to ONLY the required
 commands (e.g. lpr) it needs to execute to do its job, ONLY
 the files it needs (e.g. /var/spool/).

 the point of selinux is to give programs the absolute minimum required
 policy to operate.
 
 smbd is a monolithic application: it's fairly straightforward
 to work out what the difficulties of the monolithic approach
 are in security terms.

 l.