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

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

On 5/10/22 13:59, Amavect wrote:
> I agree with ori. It should be consistent.

I guess I don't quite understand what is inconsistent with a device
telling the rest of the kernel that its files are unfit to be used
in an exec. It seems no more different then the device/file system
saying 'no this file is not fit for reads' and giving an error on reads.
I don't view that as read() being inconsistent.

> Now, what's weird to me is why it can execute the pipe without the x bit set.

That's due to the responsibility for honoring permission bits to be on the device
exposing the files itself. None of the code checks for DMEXEC before allowing
an open with OEXEC.

> Also, trying to cp /bin/ls into data fails to execute properly.

This is because #| does not honor reads with an offset, but #e does:

term% cat /bin/file > '#e/filetest'
term% '#e/filetest' /bin/file
/bin/file: amd64 plan 9 executable

On 5/10/22 14:52, Anthony Martin wrote:
> OREAD and OEXEC are essentially the same thing on
> Plan 9. If you can open and read a file, you can always
> just copy the contents to a new file that you own and
> change the mode. Unix retains the illusion.

This is true only if you have another place to copy the
binary to that you can then also exec from. Depending on your
namespace and current user, that may not be the case.

My interest here is really in making a restricted
namespace, like one with no writable directories,
useful from a capabilities context. You are right,
having an executable #e or a directory you can
copy something in to and execute from accomplishes
the same capability. But that also means you can't remove
that capability itself from the program without removing
access to both methods. We currently have a way of removing
that writable directory method through namespace operations,
but no way of removing the ability to use #e, #d, or #| this way.

Blocking the device entirely from the namespace is one way to do the later,
but thinking of access to #e as access to the capability of stashing and executing
arbitrary code didn't sit well with me on a first pass. On a second pass, #e
is really just a proc local writable directory that is restricted to only stashing
files. As such it probably makes sense that access to #e should be no different, in
terms of capabilities it gives, then any other writable folder.

For #| and #d, I am less convinced. Not only is the interface to execute from them
really not useful, due to not honoring read offsets, but I don't think I could generalize
their function in the same way I could with #e. That is to say, I don't think the capabilities
they give should be conflated with those of a typical writable dir.

This discussion is really interesting to me. Thank you for your thoughts.

moody