From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13869 invoked from network); 10 May 2022 22:48:41 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 10 May 2022 22:48:41 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Tue May 10 18:47:14 -0400 2022 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1652222830; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wWId9+nprVMU5bL4wS8gVB3p4GqaFAj6qTPKNNraQpc=; b=JJcOof7t0K/ELiCSUAflYmCI5Bk7c+orfmtMJNa32E3o7ywho1otd+lBpYwZ4AHuMFcYB7 KWK9Z481TpZwJVsdqsoUKLhkofU9Jv1ykcSifjR93lxygxSbTyFbYt8HccP8X2M4eLH40y /W7uH42ZNUjvD77D/s1g3gr7F860vvM= Received: from [192.168.168.200] (161-97-228-135.lpcnextlight.net [161.97.228.135]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 0454203b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Tue, 10 May 2022 17:47:09 -0500 (CDT) Message-ID: <0718a4ed-dd38-06f5-2071-6d2ded50b7fa@posixcafe.org> Date: Tue, 10 May 2022 16:47:05 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: 9front@9front.org References: <77567FF86B34A592067F8FA1ADD7F3C6@eigenstate.org> <89328B14-29CE-4D30-AFAD-672900E2699D@gmail.com> From: Jacob Moody In-Reply-To: <89328B14-29CE-4D30-AFAD-672900E2699D@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: flexible generic storage SSL strategy singleton Subject: Re: [9front] [PATCH] kernel: disallow executing from #| or #d Reply-To: 9front@9front.org Precedence: bulk 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