[9fans] sendfd() on native Plan 9?

[9fans] sendfd() on native Plan 9?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 74 bytes --]

Is there any equivalent of sendfd() on native Plan 9?

Thanks.
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] sendfd() on native Plan 9?

[Rodolfo kix Garcia]

Nathaniel,

I am not 100% sure if my answer will solve your problem, but probably 
you can do it using the 9P protocol.

Look http://plan9.bell-labs.com/magic/man2html/5/0intro, 9P is the way 
to comunicate the kernel with the proccess. Probably sendfd is not 
needed in Plan 9.

Saludos.

Nathaniel W Filardo escribió:
> Is there any equivalent of sendfd() on native Plan 9?
>
> Thanks.
> --nwf;
>   

Re: [9fans] sendfd() on native Plan 9?

[Francisco J Ballesteros]

You can post a fd at /srv for others to use

On 12/23/08, Rodolfo kix Garcia <kix@kix.es> wrote:
> Nathaniel,
>
> I am not 100% sure if my answer will solve your problem, but probably
> you can do it using the 9P protocol.
>
> Look http://plan9.bell-labs.com/magic/man2html/5/0intro, 9P is the way
> to comunicate the kernel with the proccess. Probably sendfd is not
> needed in Plan 9.
>
> Saludos.
>
> Nathaniel W Filardo escribió:
>> Is there any equivalent of sendfd() on native Plan 9?
>>
>> Thanks.
>> --nwf;
>>
>
>
>

Re: [9fans] sendfd() on native Plan 9?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On Wed, Dec 24, 2008 at 12:53:06AM +0100, Francisco J Ballesteros wrote:
> You can post a fd at /srv for others to use

/srv is not an ideal answer, though it is the one I feared would be given.
/srv allows any process running as a given user to access the posted fd, and
does not respect namespace or process group boundaries.  I want a mechanism
to pass a file descriptor to one target process so that I can pass an fd
across namespaces without giving _all_ namespaces access to said fd.

A /srv that 1) was not enumerable, 2) allowed only single opens, and 3) used
secure identifiers (capabilities, similar to devcap) would suffice, as
processes could post an fd to recieve an identifier, pass the identifiers to
another process, and then turn the identifier into an fd.

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] sendfd() on native Plan 9?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Tue, Dec 23, 2008 at 11:52:51PM +0100, Rodolfo kix Garcia wrote:
> Nathaniel,
>
> I am not 100% sure if my answer will solve your problem, but probably  
> you can do it using the 9P protocol.
>
> Look http://plan9.bell-labs.com/magic/man2html/5/0intro, 9P is the way  
> to comunicate the kernel with the proccess. Probably sendfd is not  
> needed in Plan 9.

I think I understand 9P, but do not see why it removes the need for
something like sendfd().  Can you explain further?

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] sendfd() on native Plan 9?

[erik quanstrom]

> /srv is not an ideal answer, though it is the one I feared would be given.
> /srv allows any process running as a given user to access the posted fd, and
> does not respect namespace or process group boundaries.  I want a mechanism
> to pass a file descriptor to one target process so that I can pass an fd
> across namespaces without giving _all_ namespaces access to said fd.
>
> A /srv that 1) was not enumerable, 2) allowed only single opens, and 3) used
> secure identifiers (capabilities, similar to devcap) would suffice, as
> processes could post an fd to recieve an identifier, pass the identifiers to
> another process, and then turn the identifier into an fd.

on unix, which is not a distributed system, passing fds around makes
a certain amount of sense.  in plan 9, i would think that the ideal
answer would need to allow for the unrelated processes running
on seperate machine.  i would also think that it would allow the
standard authentication mechanisms to work.  fds really don't fit
either one of those criteria.  but we're talking generalities.  what's the
specific application?

- erik

Re: [9fans] sendfd() on native Plan 9?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]

On Tue, Dec 23, 2008 at 08:39:27PM -0500, erik quanstrom wrote:
> > /srv is not an ideal answer, though it is the one I feared would be given.
> > /srv allows any process running as a given user to access the posted fd, and
> > does not respect namespace or process group boundaries.  I want a mechanism
> > to pass a file descriptor to one target process so that I can pass an fd
> > across namespaces without giving _all_ namespaces access to said fd.
> > 
> > A /srv that 1) was not enumerable, 2) allowed only single opens, and 3) used
> > secure identifiers (capabilities, similar to devcap) would suffice, as
> > processes could post an fd to recieve an identifier, pass the identifiers to
> > another process, and then turn the identifier into an fd.
> 
> on unix, which is not a distributed system, passing fds around makes
> a certain amount of sense.  in plan 9, i would think that the ideal
> answer would need to allow for the unrelated processes running
> on seperate machine.  i would also think that it would allow the
> standard authentication mechanisms to work.  fds really don't fit
> either one of those criteria.

All of the same comments apply to /srv (though srv^2 is trying to solve
this).

> but we're talking generalities.  what's the specific application?

1) Sending files across namespaces so that I can spawn acme at rio startup
and plumb to it without having to recreate mounts in its namespace.

2) Sending parts of namespaces around locally without needing to run an
exportfs in that namespace.  (i.e. open() a directory && sendfd() that to
another process who can mount() it.)  Among other things, this allows the
shell (and others) to easily offer the current working directory fd (rather
than path) to rio for tab completion.

3) Some small thought about being able to implement srv^2 entirely in
userland, and what the primitives would look like.  sendfd() or the above
outlined devcapsrv seems better than the current devsrv to me, but I confess
I might be mistaken.

Thoughts? 
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] sendfd() on native Plan 9?

[erik quanstrom]

> All of the same comments apply to /srv (though srv^2 is trying to solve
> this).

not true.  import $server / /n/$server will give you access to srv on $server
as /n/$server/srv.

what is "srv^2"?

> 1) Sending files across namespaces so that I can spawn acme at rio startup
> and plumb to it without having to recreate mounts in its namespace.

plumb "Local (bind|mount) args" will accomplish this.

> 2) Sending parts of namespaces around locally without needing to run an
> exportfs in that namespace.  (i.e. open() a directory && sendfd() that to
> another process who can mount() it.)  Among other things, this allows the
> shell (and others) to easily offer the current working directory fd (rather
> than path) to rio for tab completion.

you can't mount a random directory.

> 3) Some small thought about being able to implement srv^2 entirely in
> userland, and what the primitives would look like.  sendfd() or the above
> outlined devcapsrv seems better than the current devsrv to me, but I confess
> I might be mistaken.

what's the advantage of implementing srv entirely in userland?

- erik

Re: [9fans] sendfd() on native Plan 9?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]

On Tue, Dec 23, 2008 at 11:14:16PM -0500, erik quanstrom wrote:
> > All of the same comments apply to /srv (though srv^2 is trying to solve
> > this).
> 
> not true.  import $server / /n/$server will give you access to srv on $server
> as /n/$server/srv.

Fair, but there's no reason to propose that an exportfs couldn't be the
target of a sendfd(), or that the underlying mechanism for sendfd() couldn't
be similarly exported (devcapsrv would work just fine, I think... maybe I
should just write it and post code?).

> what is "srv^2"?

EricVH's /srv replacement.  See
http://graverobbers.blogspot.com/2008/12/srv-next-generation-service-registry.html
 
> > 1) Sending files across namespaces so that I can spawn acme at rio startup
> > and plumb to it without having to recreate mounts in its namespace.
> 
> plumb "Local (bind|mount) args" will accomplish this.

Assuming that the resource can be named in the plumber's namespace?  This
works out less well for things like ramfs's that were told where to mount
(-m) and not to use /srv (-s).  Or is there something really sneaky going on
here that I don't know?

> > 2) Sending parts of namespaces around locally without needing to run an
> > exportfs in that namespace.  (i.e. open() a directory && sendfd() that to
> > another process who can mount() it.)  Among other things, this allows the
> > shell (and others) to easily offer the current working directory fd (rather
> > than path) to rio for tab completion.
> 
> you can't mount a random directory.

OK, fair, it's more of a bind().  The operation does not yet exist, but
should be quite easy to add.  Perhaps it isn't worth it.

> > 3) Some small thought about being able to implement srv^2 entirely in
> > userland, and what the primitives would look like.  sendfd() or the above
> > outlined devcapsrv seems better than the current devsrv to me, but I confess
> > I might be mistaken.
> 
> what's the advantage of implementing srv entirely in userland?

EricVH made some rumblings off-list about srv^2 being a userland thing, as
it's a relatively complex proposal.  Further, being able to write it
entirely in userland also means that it is a virtualizable service, which
/srv is not.

> - erik

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] sendfd() on native Plan 9?

[erik quanstrom]

> EricVH's /srv replacement.  See
> http://graverobbers.blogspot.com/2008/12/srv-next-generation-service-registry.html

perhaps i don't understand the srv² proposal, to which there
are many parts, but part of the problem seems to be finding
a service.  generally this is mediated by /net/cs.  i wonder if
thinking of it that way might help?

> Assuming that the resource can be named in the plumber's namespace?  This
> works out less well for things like ramfs's that were told where to mount
> (-m) and not to use /srv (-s).  Or is there something really sneaky going on
> here that I don't know?

by definition it must be.  the rule is this:

type	is	text
data	matches	'Local (.*)'
plumb	to	none
plumb	start	rc -c $1

it executes the mount in the plumber's namespace, which is
helpfully shared by rio.  (Local in acme is interpteted by
acme, not sent to the plumber.)

- erik

Re: [9fans] sendfd() on native Plan 9?

[Russ Cox]

On Tue, Dec 23, 2008 at 10:01 AM, Nathaniel W Filardo <nwf@cs.jhu.edu> wrote:
> Is there any equivalent of sendfd() on native Plan 9?

No.

Russ

Re: [9fans] sendfd() on native Plan 9?

[Roman Shaposhnik]

Sorry for coming into this discussion rather late, but...

On Dec 23, 2008, at 5:10 PM, Nathaniel W Filardo wrote:
> On Wed, Dec 24, 2008 at 12:53:06AM +0100, Francisco J Ballesteros
> wrote:
>> You can post a fd at /srv for others to use
>
> /srv is not an ideal answer, though it is the one I feared would be
> given.
> /srv allows any process running as a given user to access the posted
> fd,

True. But why that should be a problem in practice? If the process
belongs
to a user X that means user X has control over it. Thus the behavior
of accidental consumption of an fd that was meant to be consumed by
some other process can only be attributed to bugs in the code, not
malicious
intent.

Thanks,
Roman.

Re: [9fans] sendfd() on native Plan 9?

[Roman Shaposhnik]

On Dec 24, 2008, at 5:36 AM, erik quanstrom wrote:
>> EricVH's /srv replacement.  See
>> http://graverobbers.blogspot.com/2008/12/srv-next-generation-service-registry.html
>
> perhaps i don't understand the srv² proposal, to which there
> are many parts, but part of the problem seems to be finding
> a service.  generally this is mediated by /net/cs.  i wonder if
> thinking of it that way might help?

I was very curious about srv^2 as well, but Eric's blog post is really
too terse for me to appreciate even the general directions of his
proposal.

I guess if Eric can be, somehow, motivated to discuss it in greater
details that would seem to benefit at least two (three?) members
of this group.

Thanks,
Roman.

Re: [9fans] sendfd() on native Plan 9?

[Eric Van Hensbergen]

On Sat, Dec 27, 2008 at 2:27 PM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Dec 24, 2008, at 5:36 AM, erik quanstrom wrote:
>
> I was very curious about srv^2 as well, but Eric's blog post is really
> too terse for me to appreciate even the general directions of his
> proposal.
>
> I guess if Eric can be, somehow, motivated to discuss it in greater
> details that would seem to benefit at least two (three?) members
> of this group.
>

What's in the blog post is all I'm prepared to talk about at this
time.  The idea is still very high level, I'm going to need some
implementation time before I work out many of the details.  When I do,
I'll update the blog.

         -eric

Re: [9fans] sendfd() on native Plan 9?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

On Sat, Dec 27, 2008 at 12:21:49PM -0800, Roman Shaposhnik wrote:
> True. But why that should be a problem in practice? If the process
> belongs to a user X that means user X has control over it. Thus the
> behavior of accidental consumption of an fd that was meant to be consumed
> by some other process can only be attributed to bugs in the code, not
> malicious intent.

If one buys this argument, then namespaces are not valid security constructs
either, and Plan 9 security boundaries are defined solely by user id.  That
is, the claim that "a process spawned without access to your home directory
cannot get it" is flawed if that process runs as your user.  (Even if I
can't mount it, I can attach a debugger to a process that can and make it
make system calls for me.  You now have to intermediate my #p (/proc)
service.  You have to ensure that I can't dial it and authenticate with
factotum.  It's a mess!)

I may be tainted by the capability microkernel koolaid, but I don't like the
idea that users are the sole security domain objects, and I really dislike
that I can build stronger security constructs when using multiple kernels
rather than just one.  Especially in a system like Plan 9, where namespaces
are cheap and capabilties exist in the form of file descriptors.

That is, I want to be able to build processes that cannot access resources
that they were not explicitly granted when their namespace was constructed.
Currently, #p and #s are rather large, open-ended, potent capabilities to
grant, and refusing grant of #p and #s requires some rather careful coding
and prevents a number of conveniences, as you might imagine.

That is, I want, essentially, to run multiple Plan 9 systems on one Plan 9
kernel without needing to get my whole domain to know about multiple
instances of my user (e.g. nwf/browser, nwf/grid, nwf, ...).  Or rather, the
ability to do that is a sufficient, but not necessary, condition.  I can
build exactly these resource-restricted namespaces if I devote an entire
kernel -- and thereby an entire machine or emulation -- to it.  I simply
avoid granting that machine my P9 secret and (tada!) even though the uid may
be "nwf", that doesn't mean anything.

If #s can be virtualized -- ala srv^2 or devcapsrv or something else -- then
the system is one step closer to supporting the above.  There is some
machinery for sealing off #p that I do not recall in full detail but may
well be sufficient, at least for my desires.

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] sendfd() on native Plan 9?

[Eric Van Hensbergen]

On Tue, Dec 30, 2008 at 2:22 AM, Nathaniel W Filardo <nwf@cs.jhu.edu> wrote:
>
> If #s can be virtualized -- ala srv^2 or devcapsrv or something else -- then
> the system is one step closer to supporting the above.  There is some
> machinery for sealing off #p that I do not recall in full detail but may
> well be sufficient, at least for my desires.
>

I think this is an interesting direction to explore.  Extending
private name spaces to private device instances seems to make sense as
a logical extension of the system (as long as its useful to someone).
We already can have private network stacks, are their other devices
which might make sense for similar principles?

       -eric

Re: [9fans] sendfd() on native Plan 9?

[erik quanstrom]

> If one buys this argument, then namespaces are not valid security constructs

they are not security constructs at all.  though ftpd and a few friends
use rfork(2) to create a pgrp that doesn't allow attaches.  very simple
and effictive, but probablly not strong security.

> either, and Plan 9 security boundaries are defined solely by user id.

on the cpu server and authentication server , this is true.  on the file
server, group also matters.

> That is, the claim that "a process spawned without access to your home directory
> cannot get it" is flawed if that process runs as your user.

use RFNOMNT.

> (Even if I can't mount it, I can attach a debugger to a process that can and make it
> make system calls for me.  You now have to intermediate my #p (/proc)
> service.

factotum protects against this by making itself undebuggable and
unpagable.  /sys/src/cmd/auth/factotum/fs.c:/^private

also, binding '#p' into the namespace isn't required for everything.
combined with rfork(RFNOMNT), nor is providing network services.

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

i think the real question here is why don't you trust your
processes?  is it because someone else is running them

> I may be tainted by the capability microkernel koolaid, but I don't like the
> idea that users are the sole security domain objects, and I really dislike
> that I can build stronger security constructs when using multiple kernels
> rather than just one.

i don't understand this.

this doesn't seem like a compelling reason to turn namespaces into
containers.  for the reasons you cite, containers are also unattactive
solutions to security problems.

- erik

Re: [9fans] sendfd() on native Plan 9?

[Roman V. Shaposhnik]

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

Thanks,
Roman.

Re: [9fans] sendfd() on native Plan 9?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]

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;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] sendfd() on native Plan 9?

[Roman V. Shaposhnik]

[ I took a liberty to merge two of your emails together for the ease of commenting ]

On Thu, 2009-01-01 at 18:57 -0500, Nathaniel W Filardo wrote:
> That is, the claim that "a process spawned without access to your home
> directory cannot get it" is flawed if that process runs as your user.
> (Even if I can't mount it, I can attach a debugger to a process that
> can and make it make system calls for me.  You now have to
> intermediate my #p (/proc) service.  You have to ensure that I can't
> dial it and authenticate with factotum.  It's a mess!)

It would seem to me that none of the issues that you've mentioned here
are insurmountable. As far as #p and #s are concerned the good news
under Plan9 is that they are supposed to be 'just servers' (the reality
of the situation is a bit more grim -- but I'd would like to discuss
this in the separate thread). As such, if the default implementation
seems too open, you can always harden its security semantics by
providing proxying user-level servers (well, that plus fixing all the
smart-ass apps -- more on that in a separate thread).

All in all, I don't see the above example as a fundamental obstacle to
what you're trying to accomplish.

> I may be tainted by the capability microkernel koolaid,
> but I don't like the idea that users are the sole security
> domain objects

How does your ideal world look like? What else, besides users and groups
of users would you like to have as security domain objects?

> I really dislike that I can build stronger security constructs when
> using multiple kernels rather than just one.  Especially in a system
> like Plan 9, where namespaces are cheap and capabilties exist in the
> form of file descriptors.
[....]
> That is, I want, essentially, to run multiple Plan 9 systems on one
> Plan 9 kernel without needing to get my whole domain to know about
> multiple instances of my user

The above two seem to be the most crucial statements in all of this
thread. If I were to interpret them, I would say that what you're really
after is being able to provide an OS-level virtualization solution
under Plan9.

The very same reasons were part of the motivation for implementing
Solaris containers/zones for Solaris 10.

Now, if one is to look past all the marketing hype and the amount
of thrust that was needed to make that particular pig fly, Solaris
Zones are all about convincing a group of processes that they run
under separate kernels on separate hosts, even though in reality they
all could very well share the common "big iron" server. Long story
short, it all boiled down to:
   1. Virtualizing root account, so that every Zone can have its own
   2. Virtualizing the global UNIX namespace
   3. Virtualizing TCP/IP stack
   4. Virtualizing drivers providing access to the service provided
      by the kernel itself (things like /proc, etc.)
   5. Implementing per-Zone quotas on CPU, Memory and I/O consumption

Now, under Plan9, #1-3 come for free. I'm not sure how #5 is possible
(anybody?). And thus #4 is the only are that needs work. That work,
is really all about teaching things like #s and #p to only disclose
information about processes running within the same "zone". Whether
"same zone" means "same process group" or an extra level of process
grouping is needed remains to be seen.

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

The question, as I understood it, was about the practicality of such
attack. For every fully jailed process that belongs to the user Foo,
the following holds true: either it has no existing channels to the
external file servers and no means to create them, or it can obtain
a channel (either existing or a new one). From the point it connects
*and* passes the auth process, you are constrained by the security
model of 9P. Users and user groups are the only thing that is there.

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

What is 9gridchan?

> where an essentialy autonomous agent publishes services.

How does that publishing happen? If the system is distributed,
I'd presume that the publishing happens in a network-friendly
manner, thus making the whole discussion around #s pretty much
moot.

> 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 have to know more about 9gridchan agents in order to reason about
this intelligently. So far it seems to me that your general issue
with a global nature of /srv can be somewhat mitigated by following
a particular naming convention for files under /srv. More on that
later.

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

Again, I have to know more about 9gridchan and how the publishing works.

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

Now, just to be clear: this requirement is quite different from
your earlier OS-level virtualization, since you're trying to
introduce an IPC between processes which were specifically told
to behave as though the only IPC available to them is networking.

That said, the requirement itself makes sense. Although, even with
sendfd() you have to have a socket connection established before you can
pass fd's around. Except for the case where such socket connection
was created using socketpair() the sockets are *named* objects.
And that should present all the same problems that naming files
under /srv presents, shouldn't it?

IOW, I'd be very curious to see a proposal from you on how the
channel for this imaginary sendfd() is supposed to be managed so that
it gets rid of all the issues you've identified with /srv.

> Does that help answer the question?

Well, it definitely helped me understand what is it that you're after.

Thanks,
Roman.

Re: [9fans] sendfd() on native Plan 9?

[erik quanstrom]

>    1. Virtualizing root account, so that every Zone can have its own
>    2. Virtualizing the global UNIX namespace
>    3. Virtualizing TCP/IP stack
>    4. Virtualizing drivers providing access to the service provided
>       by the kernel itself (things like /proc, etc.)
>    5. Implementing per-Zone quotas on CPU, Memory and I/O consumption
>
> Now, under Plan9, #1-3 come for free. I'm not sure how #5 is possible
> (anybody?). And thus #4 is the only are that needs work. That work,

there isn't a root account, but there is still only one eve.
also, there can only be one ip stack per physical interface.
(this could be fixed by changing two or three lines of code.)
there's also nothing preventing one from implementing a
filtering fs that restricts the directories available in /proc.

i'm not quite sure what the point is.  if the problem really
is security, then i would the security problems should be fixed.

> a channel (either existing or a new one). From the point it connects
> *and* passes the auth process, you are constrained by the security
> model of 9P. Users and user groups are the only thing that is there.

note that in plan 9, groups only exist on the file server.
the auth server doesn't know anything about them

- erik

Re: [9fans] sendfd() on native Plan 9?

[Roman V. Shaposhnik]

On Sat, 2009-01-03 at 16:41 -0500, erik quanstrom wrote:
> there's also nothing preventing one from implementing a
> filtering fs that restricts the directories available in /proc.

True. But there are two problems with a filtering fs:
  1. Accessing #p would bypass the fs 100%
  2. For things like #s the need to proxy the actual data
     back and forth seems to be really unfortunate.

Thanks,
Roman.

Re: [9fans] sendfd() on native Plan 9?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 11495 bytes --]

On Sat, Jan 03, 2009 at 01:23:02PM -0800, Roman V. Shaposhnik wrote:
> [ I took a liberty to merge two of your emails together for the ease of commenting ]

Thanks. :)
 
> On Thu, 2009-01-01 at 18:57 -0500, Nathaniel W Filardo wrote:
> > That is, the claim that "a process spawned without access to your home
> > directory cannot get it" is flawed if that process runs as your user.
> > (Even if I can't mount it, I can attach a debugger to a process that
> > can and make it make system calls for me.  You now have to
> > intermediate my #p (/proc) service.  You have to ensure that I can't 
> > dial it and authenticate with factotum.  It's a mess!)
> 
> It would seem to me that none of the issues that you've mentioned here
> are insurmountable. As far as #p and #s are concerned the good news
> under Plan9 is that they are supposed to be 'just servers' (the reality
> of the situation is a bit more grim -- but I'd would like to discuss
> this in the separate thread). As such, if the default implementation
> seems too open, you can always harden its security semantics by
> providing proxying user-level servers (well, that plus fixing all the
> smart-ass apps -- more on that in a separate thread).
> 
> All in all, I don't see the above example as a fundamental obstacle to
> what you're trying to accomplish.

Agreed.  I think the kernel modifications necessary are small and tastefully
doable.

> > I may be tainted by the capability microkernel koolaid, 
> > but I don't like the idea that users are the sole security 
> > domain objects
> 
> How does your ideal world look like? What else, besides users and groups
> of users would you like to have as security domain objects?

Namespaces are containers, if the objects bound in to the namespace are well
behaved.  That is, if I cannot refer to an object in my namespace and no
server I can refer to will grant access, then I have achieved isolation of
that object and any process running in my namespace.

Users make sense for remote services -- it's an excellent mechanism for
reconnecting a principle with its capabilties (nabable objects and
permissions) on a remote server.  Perhaps in local cases they make sense as
well, but in Plan 9 the only "local" services are kernel provided.  Most of
these, AFAIK, only differentiate between hostowner and not.  The few that
leap to mind that have more advanced permissions schemes, '#p', '#s', and
the servers backing /net, have, IMHO, dubious models backing them.  '#p'
allows any of my namespaces to debug processess in any other, '#s' is too
global, and /net seems to allow any of my processes to manipulate any of my
other processes' network connections (though I've not tested in detail to
see what's possible.)

Groups are woefully problematic in almost every system I can think of (NIS,
LDAP, AFS's PTS) and Plan 9 is no exception.  Groups are left to
interpretation by the server, and in most cases are ignored.  Perhaps SPKI
will solve some of this.

> > I really dislike that I can build stronger security constructs when 
> > using multiple kernels rather than just one.  Especially in a system 
> > like Plan 9, where namespaces are cheap and capabilties exist in the
> > form of file descriptors.
> [....]
> > That is, I want, essentially, to run multiple Plan 9 systems on one 
> > Plan 9 kernel without needing to get my whole domain to know about
> > multiple instances of my user 
> 
> The above two seem to be the most crucial statements in all of this
> thread. If I were to interpret them, I would say that what you're really
> after is being able to provide an OS-level virtualization solution
> under Plan9.

"OS-level virtualization" is only a meaningful concept because,
traditionally, our kernels were not.  I want there to be no distinction
between the security guarantees that can be made when one or many kernels
are in flight.

>[snip]
> Now, under Plan9, #1-3 come for free. I'm not sure how #5 is possible
> (anybody?). And thus #4 is the only are that needs work. That work,
> is really all about teaching things like #s and #p to only disclose
> information about processes running within the same "zone". Whether
> "same zone" means "same process group" or an extra level of process
> grouping is needed remains to be seen.

Run with me for a moment to see how this might work without the extra level
of grouping.  Let's introduce an fdbind() call which takes a fd and a path,
and binds the fd's chan on the path in the current namespace.  This is
essentially an optimization around spawning a billion exportfs processes and
mount()ing the resulting descriptors.  Now, suppose '#s' and '#p' -- the
kernel services -- expose only the current process group (==namespace).  If
I want different behavior, when I construct the new namespace, I ensure that
I have open fds to my /proc and /srv and fdbind() these in the new namespace
along with '#s' and '#p'.  If desired, the new namespaces' '#s' and '#p' can
be posted (or sendfd()'d; see below) to the parent process, doing the
inverse kind of exposure.
 
> > > > 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?
> 
> The question, as I understood it, was about the practicality of such
> attack. For every fully jailed process that belongs to the user Foo,
> the following holds true: either it has no existing channels to the
> external file servers and no means to create them, or it can obtain
> a channel (either existing or a new one). From the point it connects
> *and* passes the auth process, you are constrained by the security 
> model of 9P. Users and user groups are the only thing that is there. 

I think perhaps this attack was a figment of my imagination.  The
descriptors posted in /srv posted by default are the connections not the
result of Tattach messages.  As long as this is observed, it suffices to
remove access to the user's factotum and not otherwise give the namespace so
constructed access to the user's secret.

> > > > 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
> 
> What is 9gridchan?

http://www.9gridchan.org/.  Perhaps a better example of where I might not
trust my processes would be Firefox. :)
 
> > where an essentialy autonomous agent publishes services.  
> 
> How does that publishing happen? If the system is distributed,
> I'd presume that the publishing happens in a network-friendly
> manner, thus making the whole discussion around #s pretty much
> moot.

The agents post and access resources via the local /srv.

> > 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 have to know more about 9gridchan agents in order to reason about
> this intelligently. So far it seems to me that your general issue
> with a global nature of /srv can be somewhat mitigated by following
> a particular naming convention for files under /srv. More on that
> later.

The same holds for /tmp.

> > 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.)
> 
> Again, I have to know more about 9gridchan and how the publishing works.
> 
> > 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.
> 
> Now, just to be clear: this requirement is quite different from
> your earlier OS-level virtualization, since you're trying to
> introduce an IPC between processes which were specifically told
> to behave as though the only IPC available to them is networking.

It's a little more related... the observation is that global '#s' makes
sense in some cases, but it is not a "virtualizable" interface.  Therefore,
the question becomes how one would build something like it on top of a
virtualiable interface.
 
> That said, the requirement itself makes sense. Although, even with
> sendfd() you have to have a socket connection established before you can
> pass fd's around. Except for the case where such socket connection
> was created using socketpair() the sockets are *named* objects.
> And that should present all the same problems that naming files
> under /srv presents, shouldn't it? 

sendfd() is a little special since it uses "out of band structured ancillary
data" (or something like that?) to do its magic.  See below.

> IOW, I'd be very curious to see a proposal from you on how the
> channel for this imaginary sendfd() is supposed to be managed so that
> it gets rid of all the issues you've identified with /srv. 

It's a bad answer, but notes are at least one way of sending messages to
processes you can name (e.g. exist in your /proc bindings) but with which
you have no common namespace elements.

More realistically, the plumber is an excellent example of a (virtualizable)
message passing and routing service which suffices to allow processes in
properly constructed namespaces to send textual information.  '#|' is
another.

I've been imaginging sendfd() to be based on a non-enumerable /srv
replacement, where possession of the file name and able to walk to it
suffices to prove access rights to the posted descriptor.  Let's say the
protocol is that this magical device serves a ctl file, into which one
writes a fd number and reads back a long, guaranteed unique, string.  This
string names a file beside the aforementioned ctl file.  Despite being a
global service, this can be safely mounted in every namespace with no
information exposure (non-enumerable).  Like /srv, it's even possible and
sane to exportfs this (assuming that the clients are willing to trust the
exportfs process).  It's possible to emulate /srv atop this by publishing a
list of file names somewhere.

Here's another example of where something like sendfd() might be useful, if
it helps: suppose the plumber has an active acme client which is in a
different namespace from the shell I'm about to plumb a path in.  If I could
open() that path, post it to the imaginary non-enumerable /srv, and send the
name to the plumber, then acme could open() and fdbind() that file, allowing
me to work with it, even without giving acme the rest of the namespace.  If
you trust acme, consider instead Firefox. ;)
 
> > Does that help answer the question? 
> 
> Well, it definitely helped me understand what is it that you're after.

Glad.  Thanks for discussion. :)
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] sendfd() on native Plan 9?

[lucio]

> '#p'
> allows any of my namespaces to debug processess in any other, '#s' is too
> global, and /net seems to allow any of my processes to manipulate any of my
> other processes' network connections (though I've not tested in detail to
> see what's possible.)

So you're saying that (a) a jailed process should not have access to
the #-devices at all and (b) their equivalent /proc, /srv and /net
ought to be configured as part of the jail and should not be
modifiable.

Plan 9 source often short-circuits the possibility that #-something is
not bound to the conventional place (#v comes to mind as a frequent
culprit) but that is a form of laziness that could be corrected by a
careful source audit.  In which case it would be possible to treat #X
as another of those security issues that needed special treatment for
Factotum and have a kernel request that puts the #-space out of
bounds.

Would that satisfy your requirements?  Oh, sure, I haven't ever used
#| directly and I'm a bit ignorant of consequences, but the rest seems
feasible.

Another aspect I noticed is that what you seem to need is a
finer-grained construction of #p and #s, but being able to construct
them one layer further down the hierarchy might suffice.

Just an uneducated opinion, I've had little occasion to study those
specific devices or the others in any detail.  But I am curious of
where this discussion could lead.

++L

Re: [9fans] sendfd() on native Plan 9?

[erik quanstrom]

> > '#p'
> > allows any of my namespaces to debug processess in any other, '#s' is too
> > global, and /net seems to allow any of my processes to manipulate any of my
> > other processes' network connections (though I've not tested in detail to
> > see what's possible.)
>
> So you're saying that (a) a jailed process should not have access to
> the #-devices at all and (b) their equivalent /proc, /srv and /net
> ought to be configured as part of the jail and should not be
> modifiable.

there is no special exception for #s, #I or #l.  these cases are handled
already.

> Plan 9 source often short-circuits the possibility that #-something is
> not bound to the conventional place

s/often/always/
there is no exception.  one could not bind something onto #X.

- erik

Re: [9fans] sendfd() on native Plan 9?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

On Sun, Jan 04, 2009 at 07:19:35AM +0200, lucio@proxima.alt.za wrote:
> > '#p'
> > allows any of my namespaces to debug processess in any other, '#s' is too
> > global, and /net seems to allow any of my processes to manipulate any of my
> > other processes' network connections (though I've not tested in detail to
> > see what's possible.)
> 
> So you're saying that (a) a jailed process should not have access to
> the #-devices at all and (b) their equivalent /proc, /srv and /net
> ought to be configured as part of the jail and should not be
> modifiable.

Sounds about right.  I'd say that they can be modifiable if new capabilities
are sendfd()'d into the namespace, but yes.
 
> Plan 9 source often short-circuits the possibility that #-something is
> not bound to the conventional place (#v comes to mind as a frequent
> culprit) but that is a form of laziness that could be corrected by a
> careful source audit.  In which case it would be possible to treat #X
> as another of those security issues that needed special treatment for
> Factotum and have a kernel request that puts the #-space out of
> bounds.

Elsewhere in a different thread, eric grepped for explicit uses of #X paths
and found very few.  See <3598a04c733942f7f010ad61d83a8bc2@quanstro.net>.
 
> Would that satisfy your requirements?  Oh, sure, I haven't ever used
> #| directly and I'm a bit ignorant of consequences, but the rest seems
> feasible.

I suspect #| being an exception wouldn't hurt, though it might be viewed as
a historical wart, being the only one... could #| be made to operate more
like devdup and given a canonical mountpoint?

> Another aspect I noticed is that what you seem to need is a
> finer-grained construction of #p and #s, but being able to construct
> them one layer further down the hierarchy might suffice.

"one layer further down the hierarchy" ?

> Just an uneducated opinion, I've had little occasion to study those
> specific devices or the others in any detail.  But I am curious of
> where this discussion could lead.

I too.

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] sendfd() on native Plan 9?

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On Sun, Jan 04, 2009 at 12:48:08AM -0500, erik quanstrom wrote:
> > > '#p'
> > > allows any of my namespaces to debug processess in any other, '#s' is too
> > > global, and /net seems to allow any of my processes to manipulate any of my
> > > other processes' network connections (though I've not tested in detail to
> > > see what's possible.)
> > 
> > So you're saying that (a) a jailed process should not have access to
> > the #-devices at all and (b) their equivalent /proc, /srv and /net
> > ought to be configured as part of the jail and should not be
> > modifiable.
> 
> there is no special exception for #s, #I or #l.  these cases are handled
> already.

RFNOMNT has been brought up repeatedly and, while it's certainly better than
nothing, it is too harsh!  It simultaneously:
  -> restricts access to kernel devices via # paths
  -> prevents any and all additional mount requests.

Constructing a namespace without RFNOMNT that does not have #s (say) bound
is not really securing #s (and its other consumers) against that namespace's
actions.  Constructing a namespace with RFNOMNT and without #s bound does
at least two bad things:
  -> it makes it impossible to pass fds around between processes in this
     namespace, as there is now no /srv backing.
  -> it prohibits import of additional resources.

The claim is that it might be useful to have namespaces where the mount
table remained open to additional mounts (etc.) but for which the magic
shortcut and proxy circumvention mechanism of #X was not available.

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

Re: [9fans] sendfd() on native Plan 9?

[lucio]

>> Would that satisfy your requirements?  Oh, sure, I haven't ever used
>> #| directly and I'm a bit ignorant of consequences, but the rest seems
>> feasible.
>
> I suspect #| being an exception wouldn't hurt, though it might be viewed as
> a historical wart, being the only one... could #| be made to operate more
> like devdup and given a canonical mountpoint?
>
I'd love to see that, although I respect the Plan 9 developers enough
to believe they have given the issue plenty of thought.  Still, there
have been some instance of expedience (don't ask me, I may have to
take this back :-) and perhaps there is another way if one looks
beyond the present boundaries.

>> Another aspect I noticed is that what you seem to need is a
>> finer-grained construction of #p and #s, but being able to construct
>> them one layer further down the hierarchy might suffice.
>
> "one layer further down the hierarchy" ?
>
Well, if you could bind a subset of #s by some selection criterion -
specifically process group, but who's to know what else might be
useful?  - say, back onto a local /srv, you may have a sensible
mechanism for jailing processes.  But I'm once again speculating
outside my knowledge and experience.

>> Just an uneducated opinion, I've had little occasion to study those
>> specific devices or the others in any detail.  But I am curious of
>> where this discussion could lead.
>
> I too.

I have a feeling this is heading precisely where I would have liked to
go a year or so ago, namely putting Plan 9 at the bottom of a
paravirtualising executive.  If that is the case, count me in on any
further developments.

++L

Re: [9fans] sendfd() on native Plan 9?

[lucio]

> RFNOMNT has been brought up repeatedly and, while it's certainly better than
> nothing, it is too harsh!  It simultaneously:
>   -> restricts access to kernel devices via # paths
>   -> prevents any and all additional mount requests.
>
Well, it does only the latter, the first is just a special case.  If
you see these as different, I think you may have a slightly distorted
picture and although it is accurate at this point, it may prove
erroneous later.

> Constructing a namespace without RFNOMNT that does not have #s (say) bound
> is not really securing #s (and its other consumers) against that namespace's
> actions.  Constructing a namespace with RFNOMNT and without #s bound does
> at least two bad things:
>   -> it makes it impossible to pass fds around between processes in this
>      namespace, as there is now no /srv backing.
>   -> it prohibits import of additional resources.
>
You could have a superserver process that constructs additional
namespace entries as mkdir()s within its own directory hierarchy,
could you not?  That, if I understand all this rather heady stuff
correctly, is largely your sendfd(): I want access to some external
namespace by posting its handle (a text string) to the superserver
(echo mount 'hisnamespace' > /dev/superserver/ctl) and suddenly find
/dev/superserver/999/hisnamespace for me to mess to my heart's
content.  Like you, I'd then find it annoying that RFNOMNT stops me
from abbreviating this as /n/hisnamespace for practical purposes.

Again, I'd love to be corrected if the above scenario is based on a
misunderstanding.

> The claim is that it might be useful to have namespaces where the mount
> table remained open to additional mounts (etc.) but for which the magic
> shortcut and proxy circumvention mechanism of #X was not available.

In other words, restrict RFNOMNT (obviously by a totally different
name and possibly mechanism) to the #X exception instead of its
current function.  Non?

Something tells me that there may have to be a different solution,
because as Erkik correctly points out, it is not the #-name that makes
a difference, that is just a convenient notation.  For your proposal
to make sense, it must address the properties of the #-space that make
it special/different from the rest of the namespace, specifically from
the point of view of creating a secure namespace jail.  It is that
property that needs to be leveraged by an RFCJAIL option, feeling
secure that it will not include #| when applied.

++L

Re: [9fans] sendfd() on native Plan 9?

[erik quanstrom]

> >> Another aspect I noticed is that what you seem to need is a
> >> finer-grained construction of #p and #s, but being able to construct
> >> them one layer further down the hierarchy might suffice.
> >
> > "one layer further down the hierarchy" ?
> >
> Well, if you could bind a subset of #s by some selection criterion -
> specifically process group, but who's to know what else might be
> useful?  - say, back onto a local /srv, you may have a sensible
> mechanism for jailing processes.  But I'm once again speculating
> outside my knowledge and experience.

why not just avoid /srv and #s alltogether?

the jailer could do the mounts before starting the
prisoner.  this way, no access to #s would be required.

- erik

Re: [9fans] sendfd() on native Plan 9?

[erik quanstrom]

> Constructing a namespace without RFNOMNT that does not have #s (say) bound
> is not really securing #s (and its other consumers) against that namespace's
> actions.  Constructing a namespace with RFNOMNT and without #s bound does
> at least two bad things:
>   -> it makes it impossible to pass fds around between processes in this
>      namespace, as there is now no /srv backing.
>   -> it prohibits import of additional resources.

i think you've got the cart before the horse.
i haven't even seen what i think is a compelling
argument for sendfd yet you're trying to argue
for second-order problems with a particular
application of sendfd.

i would think that in order to justify sendfd one would
need to
- have a reasonable implementation of sendfd and
- a useful application that needs it and can't be
implented correctly without it.
it would be more convincing with a paper
that considers other options and makes the
argument for sendfd.

with that in hand, it then would make sense
to talk about second-order problems.

- erik

Re: [9fans] sendfd() on native Plan 9?

[lucio]

> i haven't even seen what i think is a compelling
> argument for sendfd yet you're trying to argue
> for second-order problems with a particular
> application of sendfd.
>
Sendfd() seems to me a somewhat more carefully controlled version of
/srv.  As it stands, the additional features of sendfd() involving
security are not present in /srv, so one can make a case for providing
sendfd() (or a moral equivalent, as was originally suggested) in that
vacuum.  Enhancing /srv is certainly an option, but the exact
semantics aren't clear as sendfd() is quite remote from the Plan 9
style of implementing the analogous functionality.  While
investigating these semantics, Nathaniel merely identified how the
combination of #s and RFNOMNT falls short of the desired objectives.

> i would think that in order to justify sendfd one would
> need to
> - have a reasonable implementation of sendfd and
> - a useful application that needs it and can't be
> implented correctly without it.
> it would be more convincing with a paper
> that considers other options and makes the
> argument for sendfd.

I happen to agree with you, but Nathaniel originally specifically
asked how the sendfd() functionality could be achieved within the Plan
9 paradigm.  We have since digressed in a somewhat tortuous quest for
the exact requirements the Plan 9 design would need to satisfy.  We
are nowhere near a goal yet, because amongst all the discussion a lot
of effort has been expended in defending the Plan 9 way instead of
concentrating on how it could be enhanced.  Part of the problem is
that we do not clearly know which problem is being solved, the
objectives are still too vague and too caught up with what sendfd()
presently does.

Personally, I have a feeling that whittling down the objectives for a
sendfd() analogue would reveal that very little within Plan 9 actually
needs adjustment (a minor alternative to RFNOMNT, perhaps, or
factotum-like extensions to lock certain properties of #s).

The point is that this mailing list is a good a place to exchange
these ideas and some useful clarifications have already taken place.
I believe this discussion may be slow, but it is progressive.  If
enough people feel strongly about it, perhaps it ought to be taken
off-list, but I don't believe it should cease just yet (not that I'm
accusing anyone of shooting it down, but my comment may suggest that I
am).

++L

Re: [9fans] sendfd() on native Plan 9?

[Roman V. Shaposhnik]

On Sun, 2009-01-04 at 08:43 +0200, lucio@proxima.alt.za wrote:
> > Constructing a namespace without RFNOMNT that does not have #s (say) bound
> > is not really securing #s (and its other consumers) against that namespace's
> > actions.  Constructing a namespace with RFNOMNT and without #s bound does
> > at least two bad things:
> >   -> it makes it impossible to pass fds around between processes in this
> >      namespace, as there is now no /srv backing.
> >   -> it prohibits import of additional resources.
> >
> You could have a superserver process that constructs additional
> namespace entries as mkdir()s within its own directory hierarchy,
> could you not?

That was the solution I was trying to hint at in my original email.
I still haven't seen Nathaniel's reply to that.

> and suddenly find
> /dev/superserver/999/hisnamespace for me to mess to my heart's
> content.  Like you, I'd then find it annoying that RFNOMNT stops me
> from abbreviating this as /n/hisnamespace for practical purposes.

RFNOMNT does NOT restrict bind(2). Thus you can always do that even
in a fully jailed process.

> > The claim is that it might be useful to have namespaces where the mount
> > table remained open to additional mounts (etc.) but for which the magic
> > shortcut and proxy circumvention mechanism of #X was not available.
>
> In other words, restrict RFNOMNT (obviously by a totally different
> name and possibly mechanism) to the #X exception instead of its
> current function.  Non?

My personal opinion (which seems to be shared by Erik) is that it
is a slippery slope that can be avoided. I haven't seen the
arguments to the contrary so far.

Thanks,
Roman.

Re: [9fans] sendfd() on native Plan 9?

[Roman V. Shaposhnik]

On Sun, 2009-01-04 at 20:23 +0200, lucio@proxima.alt.za wrote:
> > i haven't even seen what i think is a compelling
> > argument for sendfd yet you're trying to argue
> > for second-order problems with a particular
> > application of sendfd.
> >
> Sendfd() seems to me a somewhat more carefully controlled version of
> /srv.  As it stands, the additional features of sendfd() involving
> security are not present in /srv,

Guys, lets stop talking about security issues. I don't think there are
any that need to be worried about. Nathaniel has identified a couple
of real issues with the current implementation of /srv so lets focus
on those.

> so one can make a case for providing sendfd()
> or a moral equivalent
  ^^^^^^^^^^^^^^^^^^^^^ incoming... ;-) (Sorry, couldn't resit)

Thanks,
Roman.

Re: [9fans] sendfd() on native Plan 9?

[erik quanstrom]

two emails, one response

> My personal opinion (which seems to be shared by Erik) is that it
> is a slippery slope that can be avoided. I haven't seen the
> arguments to the contrary so far.
and
>
> The above seems like a net gain, doesn't it?
>

pretty much, and then not so much.

the current set of exceptions is already somewhat of a
consternation.  i think it would be good to reduce, not
increase exceptions.  bandaids won't do that.  and will
likely break too many things to be popular.  to break
things and get away with it, you need to provide a real
reason to put up with the annoyance.

i suppose you could accuse me of not wanting to change
anything, but it's hard to be in favor of operating system
feng shui.

- erik

Re: [9fans] sendfd() on native Plan 9?

[lucio]

> i suppose you could accuse me of not wanting to change
> anything, but it's hard to be in favor of operating system
> feng shui.

I'll go along with Erik that the #-space should not be restricted.
Not because I disagree that it would lead to a cleaner implementation,
but because there is too much reliance on it being the way it is.
Perhaps the next iteration of Plan 9 can have the cleaner approach and
"cd #|" can be deprecated.

That said, roll on any good suggestions on where fundamentals need to
be revised.  There is no harm in regular spring cleaning.  Specially
if nothing is lost in the process.

++L

Re: [9fans] sendfd() on native Plan 9?

[Roman V. Shaposhnik]

On Sat, 2009-01-03 at 18:57 -0500, Nathaniel W Filardo wrote:
> That is, if I cannot refer to an object in my namespace and no
> server I can refer to will grant access, then I have achieved isolation of
> that object and any process running in my namespace.

That sounds like a reasonable expectation.

> Users make sense for remote services -- it's an excellent mechanism for
> reconnecting a principle with its capabilties (nabable objects and
> permissions) on a remote server.

Ok. So we are in agreement that the model doesn't need to be changed for
anything that gets to you through the #M. That leaves all the other
drivers in need for a discussion.

In fact, if there's more interest in this area -- this looks like
a subject worthy of its own thread: fine tuning of the access
permissions to the services provided by kernel drivers.

> "OS-level virtualization" is only a meaningful concept because,
> traditionally, our kernels were not.  I want there to be no distinction
> between the security guarantees that can be made when one or many kernels
> are in flight.

Agreed. Unfortunately, in UNIX "one kernel vs. many kernels"
requirements can NOT be easily unified. Thus the need for things like
Solaris zones. In Plan9, however, I suspect such unification can be made
with a very trivial amount of changes to the core system. That's why
I'm interested in this discussion to begin with.

In fact, why don't we re-frame this discussion (yet another new
thread? ;-)) as "what changes (if any) need to be implemented in
Plan9 so that there is no distinction between the security guarantees
that can be made when one or many kernels are in flight"

If nothing else, that would at least increase the practicality level.

> Run with me for a moment to see how this might work without the extra level
> of grouping.  Let's introduce an fdbind() call which takes a fd and a path,
> and binds the fd's chan on the path in the current namespace.  This is
> essentially an optimization around spawning a billion exportfs processes and
> mount()ing the resulting descriptors.

And as with any optimizations, can we, please, leave it out of the
discussion for a while? Since it is *just* and optimization, we can
always discuss it later.

> Now, suppose '#s' and '#p' -- the
> kernel services -- expose only the current process group (==namespace).  If
> I want different behavior, when I construct the new namespace, I ensure that
> I have open fds to my /proc and /srv and fdbind() these in the new namespace
> along with '#s' and '#p'.  If desired, the new namespaces' '#s' and '#p' can
> be posted (or sendfd()'d; see below) to the parent process, doing the
> inverse kind of exposure.

Ok. So the idea here boils down to partitioning the namespaces that
#s and #p serve based on the process groups (as defined by a shared
namespace), right? Then, the key problem really seems to be -- what's
the best way of unionizing these disjoint sets. If you're willing to
keep the old semantics for #s around (may be under a different name)
then exportfs doesn't seem to be too prohibitive, does it?

> > That said, the requirement itself makes sense. Although, even with
> > sendfd() you have to have a socket connection established before you can
> > pass fd's around. Except for the case where such socket connection
> > was created using socketpair() the sockets are *named* objects.
> > And that should present all the same problems that naming files
> > under /srv presents, shouldn't it?
>
> sendfd() is a little special since it uses "out of band structured ancillary
> data" (or something like that?) to do its magic.  See below.

I wasn't talking about ancillary data, I was talking about the point of
rendezvous for two processes. In case of UNIX, for unrelated processes,
that point of  rendezvous has to be a *named* entity. The fact that you
can exchange an unlimited amount of descriptors using it, doesn't solve
the /tmp-like issues. You're still dealing with namespace collisions,
etc.

> I've been imaginging sendfd() to be based on a non-enumerable /srv
> replacement, where possession of the file name and able to walk to it
> suffices to prove access rights to the posted descriptor.

These two form a very nice set of requirements. If I were to paraphrase,
what you really need is an srv-like device driven via a clone-like
interface.

> Let's say the protocol is that this magical device serves a ctl file,
> into which one writes a fd number and reads back a long, guaranteed unique,

Why does it have to be long and not just a sequential id?

> string.  This string names a file beside the aforementioned ctl file.
> Despite being a global service, this can be safely mounted in every namespace
> with no information exposure (non-enumerable).  Like /srv, it's even possible
> and sane to exportfs this (assuming that the clients are willing to trust the
> exportfs process).  It's possible to emulate /srv atop this by publishing a
> list of file names somewhere.

I need to think about it. But I understand what you have in mind now and
I agree that existing machinery doesn't seem to solve it. Now, before I
go away, here's a crazy idea that is guaranteed to get me in trouble ;-)

Would it be completely out of the question to slightly modify devdup.c
so that it accepts attaches of the following form: '#dPID' ?
Actually, since it already has ctl associated with every file id, you
can reuse that ctl to enforce a particular security policy. Then, your
sendfd() becomes a trivial matter of:
   open("#d[TARGET-PID]/[fid]");
on the receiving end and (may be) a control message (or even a chmod)
on the sending end. You will have to know the fid, but that information
needs to be exchanges anyway.

If the above sounds stupid -- I'd like to blame the late time of the
day ;-)

Thanks,
Roman.