Re: [9front] [PATCH] kernel: disallow executing from #| or #d

[Jacob Moody <moody@mail.posixcafe.org>]

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>

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

	rfork(RFNAMEG|RFNOMNT);
	pipe(pipes);
	s = smprint("#d/%d", pipes[1]);
	if(!rfork(RFPROC|RFMEM)){
		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.

moody