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.
