Re: [9front] RFNOMNT vs unmount

Re: [9front] RFNOMNT vs unmount

[ori]

Quoth hiro <23hiro@gmail.com>:
> > When trying to restrict a program, it seems common to
> > bind /path/to/resource over /, and then calling
> > 'rfork m'.
> 
> really? i have never seen this on plan9. instead it seems like
> something you would do on linux (with chroot).

It's something done by tcp80 and ftpd, for example.

But, you're right: it's not used nearly enough, considering
that the system is designed around namespacing. Probably
because glaring gaps like this make it less useful.

Re: [9front] RFNOMNT vs unmount

[cinap_lenrek]

for tcp80 and ftpd, it works fine because they dont run a full
shell that lets you do mounts or run arbitrary commands.

--
cinap

Re: [9front] RFNOMNT vs unmount

[ori]

Quoth cinap_lenrek@felloff.net:
> for tcp80 and ftpd, it works fine because they dont run a full
> shell that lets you do mounts or run arbitrary commands.

Right, and I don't *intend* to allow mounts and arbitrary
commands in other scripts, but bugs happen and lead to RCE
or shell escapes.

I see namespaces as something that could be a tool to help
make those harder to exploit.

Re: [9front] RFNOMNT vs unmount

[magma698hfsp273p9f]

ori@eigenstate.org writes:

> Luckily, we have rfork m to prevent new mounts.
> Unluckily, rfork m still allows unmounting,
> which means that if you mount a constructed
> naemspace over /, that can be undone.

What?!  Has that flaw been in the kernel since day one?

> Quoth cinap_lenrek@felloff.net:
> Right, and I don't *intend* to allow mounts and arbitrary
> commands in other scripts, but bugs happen and lead to RCE
> or shell escapes.
>
> I see namespaces as something that could be a tool to help
> make those harder to exploit.

I agree w/ori.  You can't rely on server application program logic to
enforce security.  Sometimes, it helps to have assistance from the
operating system.

Re: [9front] Re: RFNOMNT vs unmount

[ori]

Quoth Anthony Martin <ality@pbrane.org>:
> > This can be done by treating cmount() almost like a union,
> > but putting a flag within the union so that names() stops
> > traversing the union early -- 'm->shadow'; unmount can
> > then prune just the mounts with an newer 'freeze depth'
> > than the current rfork depth.
> 
> You should make the change in your own kernel if you
> have a need for it. Then, after a few weeks or more,
> let us know what the consequences were. At that point
> we can have a better discussion.

The patch I posted in the initial email covers my needs,
and I'll be running it. But there's not much to be learned
from how it interacts with the system, though, because very
little within the system uses RFNOMNT.

For good reason. As hiro pointed out, it's not particularly
well designed. I'd be happy to implement a more general and
more useful solution, but I don't have ideas I'm happy with
right now.

My goal is to restrict the impact of a compromised process;
for example, if I were inappropriately escaping paths in
shithub, and someone were able to inject a shell command,
I would like the viewer to be unable to access the user
home directories.

Re: [9front] RFNOMNT vs unmount

[Xiao-Yong Jin]

> On Dec 21, 2020, at 12:25 AM, ori@eigenstate.org wrote:
> 
> My goal is to restrict the impact of a compromised process;
> for example, if I were inappropriately escaping paths in
> shithub, and someone were able to inject a shell command,
> I would like the viewer to be unable to access the user
> home directories.

It looks like the responsibility of tcp80 and ftpd to prepare a
proper clean name space, RFCNAMEG?

[9front] RFNOMNT vs unmount

[ori]

When trying to restrict a program, it seems common to
bind /path/to/resource over /, and then calling
'rfork m'. This would be reasonably effective in
removing access to resources on the same file server
if it could be made permanent.

Luckily, we have rfork m to prevent new mounts.
Unluckily, rfork m still allows unmounting,
which means that if you mount a constructed
naemspace over /, that can be undone.

This patch disallows unmounting if we've got
RFNOMNT.

diff -r 1ae20c21a286 sys/src/9/port/chan.c
--- a/sys/src/9/port/chan.c	Sat Dec 19 19:15:02 2020 +0100
+++ b/sys/src/9/port/chan.c	Sun Dec 20 11:14:49 2020 -0800
@@ -790,6 +790,10 @@
 		wunlock(&pg->ns);
 		error(Eunmount);
 	}
+	if(pg->noattach){
+		wunlock(&pg->ns);
+		error(Enoattach);
+	}
 
 	wlock(&m->lock);
 	f = m->mount;

I think it would be nicer if we could make it recursive,
freezing the namespace at 'rfork m', and not allowing
binds or mounts to modify the frozen namespace, but
new namespace operations could be done. The problem
is that MREPL doesn't play well with this.

MREPL replaces a mount point, freeing what's below.
To make MREPL work the way I'd imagine we want, we
need to keep around the old mount, so we can unroll
to the frozen namespace on unmount.

This can be done by treating cmount() almost like a union,
but putting a flag within the union so that names() stops
traversing the union early -- 'm->shadow'; unmount can
then prune just the mounts with an newer 'freeze depth'
than the current rfork depth.

Is this a path we want to go down? It feels a bit more
complex than I like for simply restricting compromised
scripts.

Re: [9front] RFNOMNT vs unmount

[hiro]

On 12/20/20, ori@eigenstate.org <ori@eigenstate.org> wrote:
> When trying to restrict a program, it seems common to
> bind /path/to/resource over /, and then calling
> 'rfork m'.

really? i have never seen this on plan9. instead it seems like
something you would do on linux (with chroot).

Re: [9front] RFNOMNT vs unmount

[Steve Simon]

the usual way to create a restricted namespace is to clear it out and start again adding only the minimum you need.

-Steve