dynamic context transitions

[Luke Kenneth Casson Leighton]

On Mon, Nov 01, 2004 at 03:25:21PM -0500, Stephen Smalley wrote:

> On Mon, 2004-11-01 at 15:35, Luke Kenneth Casson Leighton wrote:

> >  no there is no reason why [a helper application should] not [be used].
> >  
> >  i am not sure if the simple solution [that andrew and russell
> >  came up with] was fully enumerated: it involves exec'ing a
> >  per-user helper application which does a setuid.
> >  
> >  the helper application opens files as-and-when they are needed,
> >  [and also does mkdirs? and rmdirs?] and then passes the file
> >  descriptor over a unix-domain-socket to the smbd process,
> >  which NEVER itself does file opens under a user context.
> > 
> >  i believe it then no longer becomes necessary for smbd to
> >  call become_user().
> 
> Except that SELinux mediates access to file descriptors upon transfer
> via local socket IPC as well as attempted use for read/write, so SELinux
> is still going to apply a permission check to the parent smbd process in
> that situation.  

 that i would expect.

> Not to mention that this no doubt has a significant
> cost.

 that i was not expecting.

 ... which leaves my original idea as a viable option, and it is one
 that fits the "exec()" principle.
 
 the "front-end" proxy smbd process [doing NT-style network-based
 authentication] i.e. a "Samba 4" server with the example
 VFS SMB-proxy used in a live production environment, and a
 "back-end" "Samba 3.0.X" server doing the actual file access.

 if speed is of the essence [the overhead of an intermediate TCP
 connection is considered to be non-trivial] then an additional
 communication mechanism, just like MySQL does and just like
 X does, can be added: a unix-domain-socket to provide a
 communication path between the front-end and back-end servers.

 the front-end smbd process running in smbd_t context, the
 back-end running in smbd_user_t context, never the twain
 shall meet.

 several front-end smbd processes would need to be triggered -
 one for each SMB user context - something that i believe the
 "Samba 4" VFS SMB-proxy plugin already does [by default /
 lack-of-other-options].


 if the cost of the [permanently established] link between the
 front-end and back-end is expensive on an selinux system [due
 to exactly the same mediation that stephen mentions above],
 how about using shared memory instead?

 it would require a little bit of design thought [or researching
 for existing libraries] - a packet-based transport in shared
 memory that to all external intents and purposes looked like
 a socket (odd!)

 l.

-- 
--
you don't have to BE MAD   | this space    | my brother wanted to join mensa,
  to work, but   IT HELPS  |   for rent    | for an ego trip - and get kicked 
 you feel better!  I AM    | can pay cash  | out for a even bigger one.
--