RFNOMNT

RFNOMNT

[Russ Cox]

RFNOMNT, like everything in Plan 9, was put in because
someone needed to use it, not as a purely academic
exercise in adding features.  It's behavior is what it is
because that was necessary to get the job done.
All the pie-in-the-sky "gee it would be nice if it worked
like this, not that I'm actually using it" talk is unproductive.
The "let's submit a patch and fix it" talk is scary.

Russ

Re: [9fans] RFNOMNT

[lucio]

> It's behavior is what it is
> because that was necessary to get the job done.

This approach can lead to unexpected side effects.  Roman (or was it
Nathaniel?) shows how RFNOMNT may be misunderstood to perform two
functions when in fact there is only one purpose to it.  In addition,
only the original requestor and implementor are likely to know of the
exceptions whereas anyone who might want to use it may overlook this
and find herself on thin ice.

With all due respect to those who conceived and coded the function, I
think it is unfair to expect no criticism.  Without a rationale, one
is inevitably tempted to ask whether or not a better solution could be
applied.  And a rationale is no guarantee against criticism either.

++L

Re: [9fans] RFNOMNT

[Russ Cox]

I agree that it would be nice if the exceptions were
documented in the man page.  They are quite nicely
documented in the code, though:

		/*
		 *  noattach is sandboxing.
		 *
		 *  the OK exceptions are:
		 *	|  it only gives access to pipes you create
		 *	d  this process's file descriptors
		 *	e  this process's environment
		 *  the iffy exceptions are:
		 *	c  time and pid, but also cons and consctl
		 *	p  control of your own processes (and unfortunately
		 *	   any others left unprotected)
		 */
		n = chartorune(&r, up->genbuf+1)+1;
		/* actually / is caught by parsing earlier */
		if(utfrune("M", r))
			error(Enoattach);
		if(up->pgrp->noattach && utfrune("|decp", r)==nil)
			error(Enoattach);

Russ

Re: [9fans] RFNOMNT

[lucio]

> I agree that it would be nice if the exceptions were
> documented in the man page.  They are quite nicely
> documented in the code, though:

That's easy enough to do, I'm sure.  I'll look into that and see if I
can build the confidence for a patch to, I presume, rfork(2)?

The rationale is also at least to a large extent in the quoted
comments, congratulations to the implementor.  Is there a nice
practical example one can use in the man page too?  That would be very
helpful in understanding the value and possibly the limitations of
RFNOMNT.

++L

Re: [9fans] RFNOMNT

[erik quanstrom]

> The "let's submit a patch and fix it" talk is scary.

i haven't seen any such talk; and in any event,
how can patches be scary?

> All the pie-in-the-sky "gee it would be nice if it worked
> like this, not that I'm actually using it" talk is unproductive.

if it helps understand what's there, why it's there and
what the real problems might be, i think there is value in
it.

perhaps i'm just not as smart as the rest of you, but
full programs do not leap out of my head.  they are
preceeded by false starts, bad ideas and other people's
ideas.

it has take nearly forty years to get to this point.
i'm sure that even at the labs, some pie-in-the-sky
ideas have contributed to what plan 9 is now.

- erik

Re: [9fans] RFNOMNT

[Roman V. Shaposhnik]

On Sat, 2009-01-03 at 23:08 -0800, Russ Cox wrote:
> The "let's submit a patch and fix it" talk is scary.

Russ, with all due respect, life gets unnecessarily complicated
when on one hand whenever I suggest something for discussion
there's always a member of this list (you included) who asks
me to show the code. But on the other hand, the comments like
the above tend to suggest that such code would be written in vain
anyway(*)

It especially confusing when one doesn't even know who is in
charge of reviewing officially submitted patches. If you are
among reviewers the statements along the lines of "patches
are scary" are quite scary.

Thanks,
Roman.

(*) with a sole exception of people who maintain their own
Plan9 codebase

Re: [9fans] RFNOMNT

[Skip Tavakkolian]

i understood what Russ said to mean: patches -- for enhancements that
"might" someday have a use or fixes that remove some perceived
shortcoming lacking an actual need -- are scary.

> On Sat, 2009-01-03 at 23:08 -0800, Russ Cox wrote:
>> The "let's submit a patch and fix it" talk is scary.
>
> Russ, with all due respect, life gets unnecessarily complicated
> when on one hand whenever I suggest something for discussion
> there's always a member of this list (you included) who asks
> me to show the code. But on the other hand, the comments like
> the above tend to suggest that such code would be written in vain
> anyway(*)
>
> It especially confusing when one doesn't even know who is in
> charge of reviewing officially submitted patches. If you are
> among reviewers the statements along the lines of "patches
> are scary" are quite scary.
>
> Thanks,
> Roman.
>
> (*) with a sole exception of people who maintain their own
> Plan9 codebase

Re: [9fans] RFNOMNT

[lucio]

> i understood what Russ said to mean: patches -- for enhancements that
> "might" someday have a use or fixes that remove some perceived
> shortcoming lacking an actual need -- are scary.

Not if they are first discussed in the type of forum that is savvy to
both the immediate effects and the hidden long term consequences.  I
think that was a misguided generalisation.  If I had it at my
fingertip, I would quote R.A. Heinlein's comment about democracy and
dictatorship.

I'd be curious to hear the Plan 9 developers' take on how significant
they deem contributions from us peanut gallery, sometimes it seems
they very much prefer us all to just go away, as Uriel seems to
suggest.  Other times they seem positively thrilled to have us around.
A more consistent policy would be a lot easier to work with, whichever
side it took.

++L

PS: Of course, Russ does not represent all Plan 9 developers (I have a
feeling and a deep respect for the fact that he may well often be the
sole heir to the title of Plan 9 developer :-) and I am a very
reluctant critic of someone whose contributions appear to have
single-handedly shaped Plan 9.  I'm sure that his outburst was nothing
more than reaction under stressing circumstances.

Re: [9fans] RFNOMNT

[Russ Cox]

I apologize for the tone of my first message.
Skip put the words better in his rephrasing.
I was speaking only for myself -- I have no part
in applying patches to Plan 9 anymore.  I submit
changes the same as everyone else.

I would hope that any patch changing the behavior
of RFNOMNT would be based on someone's experience
using the change for a while and exploring the
consequences, rather than design on a mailing list.
The various RFNOMNT threads seemed to have mostly
the former, and then there was talk of a patch.
That--talk of submitting patches to change subtle, low-level
functionality without having any practical experience
with the change--is what I found scary.

Russ

[9fans] RFNOMNT and/or "least privilege"

[Dave Eckhardt]

> RFNOMNT, like everything in Plan 9, was put in because
> someone needed to use it, not as a purely academic
> exercise in adding features.

Here is something which either I've misunderstood or is
harder than I'd like.

I have a machine which runs two private (password-protected)
web servers on different ports.  It is not the case that
everybody who can log in to the machine should be able to
read the content offered by those two servers.

The web server infrastructure seems pretty focused on running
as user "none", which makes sense as far as it goes, but I
don't want none to be able to read the files served by the
web servers because anybody who can log in to the machine can
become none.

What I've worked out so far is this.  At boot time, the host
owner (who is a member of a group which can access the bits)
builds an approprate namespace for each of the web servers.
In each case the hostowner starts up a wikifs which can read
and modify the privileged information but which posts a
world-mountable service descriptor in /srv.  Once each web
server is launched in a namespace which has mounted the
descriptor, the descriptor is deleted from /srv.  If all this
happens before listen is run, I think the result is two
environments which are both running as none but have access
to the bits they need, without leaking that access to everybody
else who runs as none.

What does this have to do with RFNOMNT?  For one thing, while
I thought about using RFNOMNT to limit the ability of the a
hijacked web server or its children to get at the rest of the
system, lots of people demand the ability to rearrange their
namespaces, e.g., wikipost bails out if it can't mount onto
/mnt/wiki.

But overall I wish I had more ability to set up "least privilege"
execution domains, meaning process trees with exactly the
privileges they need but no more.

Or am I doing it all wrong?

Dave Eckhardt

Re: [9fans] RFNOMNT and/or "least privilege"

[sqweek]

On Wed, Jan 7, 2009 at 3:24 PM, Dave Eckhardt <davide+p9@cs.cmu.edu> wrote:
> The web server infrastructure seems pretty focused on running
> as user "none", which makes sense as far as it goes, but I
> don't want none to be able to read the files served by the
> web servers because anybody who can log in to the machine can
> become none.

 Pegasus[1] is different here, it has namespace seperation between
virtual servers which run as arbitrary users. I can't really comment
on other differences, as I'm not very familiar with httpd. Or pegasus,
for that matter ;) I just read the intro the other day and it sounds
like something you might be interested in.

[1] http://plan9.aichi-u.ac.jp/pegasus/

-sqweek

Re: [9fans] RFNOMNT and/or "least privilege"

[Roman V. Shaposhnik]

On Wed, 2009-01-07 at 01:24 -0500, Dave Eckhardt wrote:
> > RFNOMNT, like everything in Plan 9, was put in because
> > someone needed to use it, not as a purely academic
> > exercise in adding features.
>
> Here is something which either I've misunderstood or is
> harder than I'd like.

[...]

> What does this have to do with RFNOMNT?  For one thing, while
> I thought about using RFNOMNT to limit the ability of the a
> hijacked web server or its children to get at the rest of the
> system, lots of people demand the ability to rearrange their
> namespaces, e.g., wikipost bails out if it can't mount onto
> /mnt/wiki.

The more I think about #X issue (especially in light of
comments made by Russ) and RFNOMNT the more it dawns on me that
I would really like to have a chat with whoever put it there ;-)
(in moments like this, I also wish for good SCM history being
available).

It now seems, that if your process has a read/write access to
a channel capable of speaking 9P not letting it mount that
channel really doesn't accomplish much: whatever messages kernel
would send on your behalf, you can send directly. There's no
additional damage to be done. Thus, the first place, where RFNOMNT
starts to make a difference, is when your jailed process spawns
children. They are too, prevented from mounting stuff. Does it
change security ramifications? I'd say for *channels* that
speak 9P -- it doesn't.

Thus, the only place where RFNOMNT start to *really* matter
is restricting access to the devices in the #-namespace. Which,
given its name, is a bit ironic. After all, accessing them
is about *implicit* attach done by namec(), not an explicit
mount.

Now, as far as restricting access to the devices goes: RFNOMNT
seems like too clumsy of a hammer: it either all or nothing
(plus, all those weird exception noted in namec()). For example,
if I wanted to create a jailed environment with access to
a particular set of devices: I'm out of luck.

So all in all, so far it seems that:
   1. RFNOMNT is a bit of a misnomer
   2. For what it is supposed to be useful (restricting
      access to kernel devices) it doesn't do
      a very convincing job.

> But overall I wish I had more ability to set up "least privilege"
> execution domains, meaning process trees with exactly the
> privileges they need but no more.

Ok, here are my thoughs:
  1. so far, the #1 issue for proper jailing is really how
  to efficiently manage access rights to the kernel devices.

  2. since at this point -- I'm almost convinced that: pretending
  that devices are channels capable of speaking 9P (and thus
  forcing the access to *always* be via the namespace) is not
  much better than what we currently have.

So what are the options left to manage the access rights?
Since devices are not channels (even pretend ones) you can't do
the management via r/w permission on the channel itself.
That leaves only RFNOMNT (which starts to look a bit ugly)
and devattach().

>From a flexibility standpoint, though, I really wish I could
do something like this:
   term% echo 'devallow |decpsPr' >> /proc/$pid/ctl
   # the above still doesn't matter
   # but after the next line it will
   term% rfork m
   term% ls '#p' '#P' '#s' # this works
   ....
   term% ls '#I'           # this doesn't
   ls: #I: mount/attach disallowed

The amount of code needed for such a change is trivial and
it also has a benefit of managing those pesky exceptions
in namec() in a much more explicit manner.

Thanks,
Roman.

Re: [9fans] RFNOMNT and/or "least privilege"

[Charles Forsyth]

>It now seems, that if your process has a read/write access to
>a channel capable of speaking 9P not letting it mount that
>channel really doesn't accomplish much: whatever messages kernel
>would send on your behalf, you can send directly.

note that if a Chan has once been mounted it can no longer
be read or written except through devmnt.

Re: [9fans] RFNOMNT and/or "least privilege"

[Nathaniel W Filardo]

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

On Thu, Jan 08, 2009 at 07:57:42PM +0000, Charles Forsyth wrote:
> >It now seems, that if your process has a read/write access to 
> >a channel capable of speaking 9P not letting it mount that
> >channel really doesn't accomplish much: whatever messages kernel 
> >would send on your behalf, you can send directly.
> 
> note that if a Chan has once been mounted it can no longer
> be read or written except through devmnt.

That's not much of a security guarantee since there's a race window when a
channel is first posted to '#s' (e.g.), but yes, it's better than nothing.

--nwf; 

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

Re: [9fans] RFNOMNT and/or "least privilege"

[Charles Forsyth]

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

i was just pointing it out: i wasn't suggesting that it
necessarily added security. (it was a response to the remark
that a process could send arbitrary messages; not necessarily.)
having said that, i'm not sure it's really a race, more of an ordering restriction:
if you mount it before posting, i don't think you can get avoid the checks,
so it can be much better than nothing.

[-- Attachment #2: Type: message/rfc822, Size: 3489 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 596 bytes --]

On Thu, Jan 08, 2009 at 07:57:42PM +0000, Charles Forsyth wrote:
> >It now seems, that if your process has a read/write access to 
> >a channel capable of speaking 9P not letting it mount that
> >channel really doesn't accomplish much: whatever messages kernel 
> >would send on your behalf, you can send directly.
> 
> note that if a Chan has once been mounted it can no longer
> be read or written except through devmnt.

That's not much of a security guarantee since there's a race window when a
channel is first posted to '#s' (e.g.), but yes, it's better than nothing.

--nwf; 

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

Re: [9fans] RFNOMNT and/or "least privilege"

[Roman V. Shaposhnik]

On Thu, 2009-01-08 at 19:57 +0000, Charles Forsyth wrote:
> >It now seems, that if your process has a read/write access to
> >a channel capable of speaking 9P not letting it mount that
> >channel really doesn't accomplish much: whatever messages kernel
> >would send on your behalf, you can send directly.
>
> note that if a Chan has once been mounted it can no longer
> be read or written except through devmnt.

That's a good point. Mounted channels do introduce a third clause
into this taxonomy -- channels which are only good for mounting.
>From that standpoint they really start to look more like user-visible
incarnations of #M, which would lump them into devices category.

IOW, the appearance of extra security ramifications here is a bit
deceiving.

Thanks,
Roman.