9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Jacob Moody <moody@mail.posixcafe.org>
To: 9front@9front.org
Subject: Re: [9front] [PATCH] kernel: disallow executing from #| or #d
Date: Wed, 11 May 2022 00:31:27 -0600	[thread overview]
Message-ID: <c868d55b-2493-db66-740b-17e606a3b99a@posixcafe.org> (raw)
In-Reply-To: <0BBC7720-2562-4C73-9153-0A37CF503820@gmail.com>

On 5/10/22 22:21, Amavect wrote:
> I think the correct thing to do is to get the devices to respect the permission bits,
> potentially allowing execution if chmod made it that way. Also check rw bits.
> This would make it more consistent to my judgement.
> Then, we can decide whether to reject a wstat for trying to set the x bit.

I disagree, I put forward that having #|/^(data data1) executable has no valid
use case. Requiring +x set, then preventing +x from being set
is just a roundabout way of disabling opening with OEXEC, why
not just do that?

> Additionally, if you're restricting namespaces,
> you pretty much have to set RFNOMNT.

As is yes, I was poking around this code because I wish
to change those semantics. There is a patch
for this a bit earlier up in the mailing list.
Some of my thoughts are within the context
of that code.

> This removes access to # directories.

RFNOMNT does not remove access to #|, #d, #e, #c, or #p

> Devpipe is rendered useless due to using attach messages (can still use pipe(2)),

You can still attach to '#|' just fine after an RFNOMNT

cpu% rofk nm
cpu% bind '#|' /n/test

you can use pipe(2) after RFNOMNT specifically because RFNOMNT does not block #|.

The attach semantics of #| are a bit tricky with relation to the pipe
system call. An attach is sent to the device only when a walk is
started from '#', any walk to '#|' always gets you a new pair of pipes.
So in order to get an fd to each side, you need to only walk '#|'
once. That means without having the specific instance of #| 'pined'
somewhere, you can not refer to one end of the pipe by name which is
required to call exec. The pipe() system call does the walk for you,
and gives you back the fds without ever exposing the instance of
#|. So it is impossible to exec an end of a pipe walked to by
the pipe system call.

Or it would be, but you can execute that end of the pipe
by referring to it through #d:

#include <u.h>
#include <libc.h>

main(int argc, char **argv)
	int pipes[2];
	char *s;

	s = smprint("#d/%d", pipes[1]);
		execl(s, s, nil);
		sysfatal("failed to exec: %r");
	fprint(pipes[0], "#!/bin/rc\n");
	fprint(pipes[0], "echo hello\n\n");

Now lets say you can block #d and #| for your process.
If my goal is to build a namespace that is not capable of executing
arbitrary memory, why should I have to block #d and #| to achieve this?
It doesn't seem like there is any practical use for them to leak this capability.


  reply	other threads:[~2022-05-11  6:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10  6:40 Jacob Moody
2022-05-10 14:40 ` ori
2022-05-10 16:34   ` Jacob Moody
2022-05-10 19:59     ` Amavect
2022-05-10 22:47       ` Jacob Moody
2022-05-11  4:21         ` Amavect
2022-05-11  6:31           ` Jacob Moody [this message]
2022-05-11 16:32             ` Amavect
2022-05-11 16:50               ` Jacob Moody
2022-05-15  2:43                 ` Amavect
2022-05-15 15:26                   ` Amavect
2022-05-15 16:28                     ` Jacob Moody
2022-05-10 20:52 ` [9front] " Anthony Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c868d55b-2493-db66-740b-17e606a3b99a@posixcafe.org \
    --to=moody@mail.posixcafe.org \
    --cc=9front@9front.org \
    --subject='Re: [9front] [PATCH] kernel: disallow executing from #| or #d' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).