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. moody
next prev parent 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * 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' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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).