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 31152 invoked from network); 10 May 2022 16:44:31 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 10 May 2022 16:44:31 -0000
Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Tue May 10 12:34:36 -0400 2022
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org;
	s=20200506; t=1652200471;
	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=XUOMM+SFYmkUYl2xniLxEUVAHufoydL8L/CPNaGn1uc=;
	b=FvaeY+C60+oAHjDMabv/abaTLj2OmKaJe5Nz1fr4bExxBYys36u+HlldM/tCWEG0GgsMrp
	0O9P3C8YuJIeFnFLNecjl9ngBbwg5nKEIr09qO/1B7Z27a1+GX2EEsvT1h8to/DL2zIF4M
	1bUTn5UV73rjwl6pwoh7Hz2pwWDncnQ=
Received: from [192.168.168.200] (161-97-228-135.lpcnextlight.net [161.97.228.135])
	by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 8f63b6f8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO)
	for <9front@9front.org>;
	Tue, 10 May 2022 11:34:31 -0500 (CDT)
Message-ID: <b0efb91e-7ffc-1e24-0529-f6f6b47bad0e@posixcafe.org>
Date: Tue, 10 May 2022 10:34:28 -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>
From: Jacob Moody <moody@mail.posixcafe.org>
In-Reply-To: <77567FF86B34A592067F8FA1ADD7F3C6@eigenstate.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: transactional generic SSL plugin-aware blockchain control 
Subject: Re: [9front] [PATCH] kernel: disallow executing from #| or #d
Reply-To: 9front@9front.org
Precedence: bulk

On 5/10/22 08:40, ori@eigenstate.org wrote:
> I think all files should be the same, as much as
> they can be -- we shouldn't necessarily need to
> care if we have a pipe or not.
> 

In general I think I agree, but I would argue that its not the
exec code that is special casing itself from using these files.
The devices are electing themselves to say that execution is
not a supported operation on the files they serve, but perhaps
that is just semantics.

I want to explain more of why I think this is not ideal. I am
approaching this from the question "what capabilities does a sharp
device give you?". And I think it is a bit surprising to say access
to #| or #d also gives a process the ability to execute arbitrary code
stashed in to one end of a pipe. I can imagine such a case of building
a namespace where the binaries exposed are hand picked, and I think its
reasonable to want to restrict what binaries can be executed while also
allowing programs to use dup() and pipe().

But perhaps my approach here is wrong, it could be that it is inherently misleading
to think about a programs capabilities in terms of what kernel devices
the program has access to.


moody