dynamic context transitions
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Sun Nov 14 16:24:53 GMT 2004
[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
... 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.
More information about the samba-technical