[OpenAFS-devel] Re: openafs / opendfs collaboration

[Luke Kenneth Casson Leighton]

matthew, i'm going to be bluntly honest here.

it sounds like a complete nightmare.

i see nothing here that a userspace implementation plus an
appropriate selinux policy couldn't gain you.

if a credential / ACL "cache" is provided in a userspace daemon,
which provides oh, say, a unix domain socket interface, and you
created an selinux policy which protected access to those sockets,
not only are you done, but also if you port your credential cacheing
userspace daemon to other unixen that don't happen to have selinux,
so what?  at least it's portable: you don't _have_ to "layer" selinux on
top.

there are tricks that can be played when providing a unix
domain socket interface, to ensure that only a specific uid has access
to an interface, in a way that the daemon can be absolutely sure that
only that uid has access (except root of course).

you connect to a 0777 accessible socket, you say "this is
my uid", then the daemon creates a temporary directory,
chmods it 0700, chowns it to that uid, creates a unix-d-sock
in that directory, 0600 chmods and chowns it, and then sends
the location of that directory down the 0777 socket.

(the creation of the directory is necessary because some unixen
 cannot handle chmod on a socket!)

the client disconnects from the 0777 socket and then reconnects to the
temporary socket.  the daemon therefore knows that only a process with
that uid is able to access that socket.

you could even, on linux, play tricks with /proc (similar to what lsof
does) to ensure that only a particular _process_ has access to a socket.

... but i believe this [restricting processes] would be much
better / cleanly achieved using an selinux policy, setting up
selinux domains to restrict access.

l.



On Wed, Jan 26, 2005 at 01:41:09PM -0800, Matthew N. Andrews wrote:
 
> > such that a userspace credential cache would be insufficient?
> >
> > in other words, if i log in as user1 and create boat-loads
> > of processes, is there _any_ circumstance under which any
> > arbitrary user2 _needs_ access to the cached credentials
> > of user1?
> >
> I think you're missing a key feature of pags here. you can have a 
> process acquire credentials that:
> 
> 1) other processes with the same uid/gid cannot access.
> 2) are accessible to child processes with a differend uid/gid, unless 
> specific actions are taken to drop access by an intermediat 
> descendant/ancestor.
> 
> and yes, there are circumstances when changing effective uid needs NOT 
> to drop access to my credentials. in particular, setuid programs run by 
> me should retain access to my afs credentials.
> 
> -Matt Andrews
> 
> > l.
> > 
> >--
> ><a href="http://lkcl.net">http://lkcl.net</a>
> >--
> >_______________________________________________
> >OpenAFS-devel mailing list
> >OpenAFS-devel@openafs.org
> >https://lists.openafs.org/mailman/listinfo/openafs-devel
> >
> >
> 

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--