On Thu, Jan 01, 2009 at 02:53:33PM -0800, Roman V. Shaposhnik wrote:
> On Tue, 2008-12-30 at 10:31 -0500, erik quanstrom wrote:
> > > You have to ensure that I can't dial it and authenticate with
> > > factotum.  It's a mess!)
> > 
> > how would that attack work?
> >
> > supposing that you have a fully jailed process.  if it has a connection
> > to the fileserver, which does do security by user id, the jailed process
> > can still mess with you.  say by deleting all your files.

Yes, exactly.  I don't understand the question?
 
> > i think the real question here is why don't you trust your
> > processes?  is it because someone else is running them
> 
> That was, essentially, my original question. Nathaniel, could you,
> please answer it?

I'm looking at a system like 9gridchan where an essentialy autonomous agent
publishes services.  A bug in this server which revealed all of /srv, rather
than the parts of /srv it's supposed to, would be tragic.  I'd be much, much
happier if the bar were raised from server compromise to local kernel
compromise.  Further, 9gridchan pollutes the namespace of /srv for everybody
else on the system, and its current naming scheme makes it impossible to run
two 9gridchan agents (w/o modification) even as different users.

I also want, I think, an extension to 9gridchan where I can publish a
service which relays for other 9gridchan nodes, which essentially means that
remote machines are directing the contents of my /srv.  (I want this so that
I can bounce around NATs or loss of direct connectivity in the 9gridchan
mesh... other proposals for solving this problem welcome.)

While fixing 9gridchan could solve some of this, the problem is more
general. The global unified name space of /srv is reminiscent of the UNIX
/tmp nightmare, where processes and users have to guess as to names that
won't collide or iterate around create() or, in the worst case, just fail
outright (e.g. somebody has posted a file name 'sources' into /srv that
isn't a connection to sources).

However, /srv is currently the only mechanism (AFAIK) for a fd in a pgrp A
to be given to a process in pgrp B.  Therefore, if /srv is to be virtualized
(made a property of namespaces) ala /tmp, then something like sendfd() seems
to be necessary to replace this functionality when required.

Does that help answer the question?  Am I totally lost in the woods? (It's
always possible...).

Thanks.
--nwf;