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 11032 invoked from network); 11 May 2022 06:33:38 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 11 May 2022 06:33:38 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed May 11 02:31:36 -0400 2022 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1652250692; 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=tDHJBw+LnNWcA1S5ZuebnWzT8W5Lvos5Z83TT8gJSl8=; b=ZCQ73S4HgRhW4j+Bwq4WpwQlbsw7K4h2M7rytKqn5GbhAi6IJKIJKK1E3FQGJuA64tPiS7 VA48QvDESq7qn09MSjdxiNCA/wADBVHUcFxZ1Q3IQTtijJa9ECXtD+zD0gznwM3sxHStzZ TjbAbRKdg1o27IxJvC/N6ob3Zlr+FgM= Received: from [192.168.168.200] (161-97-228-135.lpcnextlight.net [161.97.228.135]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id dc296846 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Wed, 11 May 2022 01:31:31 -0500 (CDT) Message-ID: Date: Wed, 11 May 2022 00:31:27 -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> <0718a4ed-dd38-06f5-2071-6d2ded50b7fa@posixcafe.org> <0BBC7720-2562-4C73-9153-0A37CF503820@gmail.com> From: Jacob Moody In-Reply-To: <0BBC7720-2562-4C73-9153-0A37CF503820@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: patented framework base Subject: Re: [9front] [PATCH] kernel: disallow executing from #| or #d Reply-To: 9front@9front.org Precedence: bulk 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 #include 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