9front - general discussion about 9front
 help / color / mirror / Atom feed
* Re: [9front] RFNOMNT vs unmount
@ 2020-12-20 20:33 ori
  2020-12-20 21:39 ` cinap_lenrek
  0 siblings, 1 reply; 8+ messages in thread
From: ori @ 2020-12-20 20:33 UTC (permalink / raw)
  To: 23hiro, 9front

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.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] RFNOMNT vs unmount
  2020-12-20 20:33 [9front] RFNOMNT vs unmount ori
@ 2020-12-20 21:39 ` cinap_lenrek
  2020-12-20 21:52   ` ori
  0 siblings, 1 reply; 8+ messages in thread
From: cinap_lenrek @ 2020-12-20 21:39 UTC (permalink / raw)
  To: 9front

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

--
cinap

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] RFNOMNT vs unmount
  2020-12-20 21:39 ` cinap_lenrek
@ 2020-12-20 21:52   ` ori
  2020-12-21 18:51     ` magma698hfsp273p9f
  0 siblings, 1 reply; 8+ messages in thread
From: ori @ 2020-12-20 21:52 UTC (permalink / raw)
  To: cinap_lenrek, 9front

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] RFNOMNT vs unmount
  2020-12-20 21:52   ` ori
@ 2020-12-21 18:51     ` magma698hfsp273p9f
  0 siblings, 0 replies; 8+ messages in thread
From: magma698hfsp273p9f @ 2020-12-21 18:51 UTC (permalink / raw)
  To: 9front

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] RFNOMNT vs unmount
  2020-12-21  6:25 [9front] " ori
@ 2020-12-21 15:34 ` Xiao-Yong Jin
  0 siblings, 0 replies; 8+ messages in thread
From: Xiao-Yong Jin @ 2020-12-21 15:34 UTC (permalink / raw)
  To: 9front


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] RFNOMNT vs unmount
  2020-12-20 19:49 ` hiro
@ 2020-12-20 20:32   ` Steve Simon
  0 siblings, 0 replies; 8+ messages in thread
From: Steve Simon @ 2020-12-20 20:32 UTC (permalink / raw)
  To: 9front


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

-Steve


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [9front] RFNOMNT vs unmount
  2020-12-20 19:22 ori
@ 2020-12-20 19:49 ` hiro
  2020-12-20 20:32   ` Steve Simon
  0 siblings, 1 reply; 8+ messages in thread
From: hiro @ 2020-12-20 19:49 UTC (permalink / raw)
  To: 9front

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [9front] RFNOMNT vs unmount
@ 2020-12-20 19:22 ori
  2020-12-20 19:49 ` hiro
  0 siblings, 1 reply; 8+ messages in thread
From: ori @ 2020-12-20 19:22 UTC (permalink / raw)
  To: 9front

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2020-12-21 20:50 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-20 20:33 [9front] RFNOMNT vs unmount ori
2020-12-20 21:39 ` cinap_lenrek
2020-12-20 21:52   ` ori
2020-12-21 18:51     ` magma698hfsp273p9f
  -- strict thread matches above, loose matches on Subject: below --
2020-12-21  6:25 [9front] " ori
2020-12-21 15:34 ` [9front] " Xiao-Yong Jin
2020-12-20 19:22 ori
2020-12-20 19:49 ` hiro
2020-12-20 20:32   ` Steve Simon

9front - general discussion about 9front

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/9front

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9front 9front/ http://inbox.vuxu.org/9front \
		9front@9front.org
	public-inbox-index 9front

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9front


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git