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: Tue, 10 May 2022 16:47:05 -0600	[thread overview]
Message-ID: <0718a4ed-dd38-06f5-2071-6d2ded50b7fa@posixcafe.org> (raw)
In-Reply-To: <89328B14-29CE-4D30-AFAD-672900E2699D@gmail.com>

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.


  reply	other threads:[~2022-05-10 22:48 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 [this message]
2022-05-11  4:21         ` Amavect
2022-05-11  6:31           ` Jacob Moody
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=0718a4ed-dd38-06f5-2071-6d2ded50b7fa@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).