se-samba

[tridge at samba.org]

Volker,

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

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

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?

Maybe by not thinking of Samba as a special case, and instead
realising that protocol servers for lots of protocols often need to
deal with multiple security contexts the se-linux developers can come
up with a more appealing general solution.

Cheers, Tridge