Luke Kenneth Casson Leighton
lkcl at lkcl.net
Wed Jun 2 12:00:16 GMT 2004
On Wed, Jun 02, 2004 at 08:33:06AM +1000, tridge at samba.org wrote:
> > It's a), everything is done via a single tcp connection. One reason is that we
> > want to mirror the behaviour that the server we proxy towards gives us as
> > closely as possible. Separate smb connections give a difference that might have
> > influence on the server's behaviour.
> Nope, the we open a new connection for each tree connect in that
BRILLIANT. that's even better.
> It really doesn't matter though, as unless I have completely
> misunderstood se-linux, the TConX behaviour is completely irrelevant
> for the seteuid() problem that se-linux faces. All TConX does is
> establish a connection to a new directory (ignoring ancient share
> level security setups).
the problem is that SE/Linux doesn't support seteuid.
> The relevant question is how SessionSetup is handled, because that is
> what determines the security context of requests. A client can combine
> SessionSetup with TConX in any way it wants to, with multiple TConX
> per SessionSetup or multiple SessionSetup per TConX.
> The CIFS proxy backend in Samba4 currently does a fixed SessionSetup
> using domain, username and password from parametric options in
> smb.conf. Andrew Bartlett has talked about adding authentication
> proxying as well, but it isn't done yet. When that is done the whole
> se-linux idea of using a CIFS proxy could be re-visited.
> But really I think the whole idea of using a CIFS proxy for se-linux
> Samba is a non-starter. It would work, but it would be a "party
> trick", not a serious solution. Far better for the se-linux people to
> come up with a more general solution for handling servers that need to
> handle multiple security contexts on one network connection. In
> particular the solution should not be so intimately tied to CIFS.
the solution is to have one process per security context.
it is not possible to drop from the equivalent of root into
the equivalent of a user-security-context (seteuid) and then
back to the equivalent of root again.
and SE/Linux is never going to have the equivalent of seteuid added.
an SMB proxy which de-multiplexes all SMBsessionsetupXs and
SMBtconXs is the "quickest" way to code up something that
"works" that fits the requirements.
it doesn't have to be fast.
it doesn't have to be nice.
it just has to work, and provide the required security semantics.
"next" version can be an improvement on that.
and, if i gather this correctly, the required semantics are already
satisfied by using samba(4)'s SMB proxy and a samba(3) back-end.
which is _great_.
now, as i described a couple of times before, the alternatives
are to write a special samba(4) NT-VFS plugin that communicates
via a custom-written Inter-Process-Communication system to a
de-multiplexing filesystem back-end.
or, to design a back-end that forks() on SMBsessionsetupX
and then forks() again on SMBtconX, and has some internal logic
that manages to deal with locking, consistency, and successfully
manages to communicate SMB requests through the double-layer of
that's a _lot_ more complex a solution than using SMB proxying.
> I would suggest that the se-linux people think about a potential
> user-space NFSv4 server, which faces exactly the same problem. Do the
> constraints imposed by se-linux mean that we will forever have to run
> NFSv4 servers in the kernel? Is that a good idea, given the security
> isolation aims of the project?
i believe you may be misunderstanding the issues, which are relatively
1) root has no special "automatic" privileges, or more specifically,
the uid "0" has no special "automatic" privileges, in SE/Linux.
all uids are treated the same, and they only have the privileges
which they are given, by the sysadmin.
2) processes, which run under user-contexts (uids) have to be given
permissions to do certain operations, such as execv(), open(),
read once opened, stat, in fact pretty much everything is
3) processes can, on creation of a child process make that
child process "transition" to what they refer to as a new
"domain". e.g. auto_trans(samba_parent_t, samba_backend_t)
and the new domain will of course have its _own_ set of
[this is where it gets relevant to se-samba:]
4) IT IS NOT POSSIBLE FOR A CHILD PROCESS TO RETURN TO THE
therefore, with the present design of samba(3) which uses
seteuid() to jump to pretending to be a user context,
such that file writes are done as that user, and then back to
root to deal with a different TconX context, that completely
and yes, famd uses seteuid as well, and needs a total redesign
along the same lines (multiple forked processes).
andrew, i'm not entirely sure where you got the impression
that it is necessary to run a kernel-space service (e.g. a
kernel-space NFS server) in an SE/Linux environment.
a user-space file server is perfectly sufficient, and much more
if it wasn't for the fact that multiple SMB sessions can be made
over the same TCP connection...
could someone please remind me: a Citrix Server does multiple
SMB sessions over the same TCP connection, doesn't it?
if that's the case, then... could someone confirm this statement
"the samba(4) NT-VFS SMB proxy will do multiple TCP client
connections per SMB session"
is that statement correct?
because if so, then if the NT-VFS SMB proxy does multiple TCP
connections per TConX, then yes, that _is_ a little excessive, but
it's possible to live with that excess, and it can be solved
by the libsmbclient supporting multiple TconX connections over the
same TCP connection.
the _most_ important thing is to have separate TCP connections
for every SMBsessionsetupX.
in case anyone's interested, i believe i may have modified
samba-tng's libsmbclient code (or maybe the cliffs libsmbclient
code) to be able to do multiple TconX's per TCP connection.
it's quite straightforward.
More information about the samba-technical