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=-1.0 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 8473 invoked from network); 28 May 2022 22:56:31 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 28 May 2022 22:56:31 -0000
Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Sat May 28 18:54:29 -0400 2022
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org;
	s=20200506; t=1653778464;
	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=6TFoYfJAkhAyS9xkkh/iuCpAroMQl7y4yp5lTY+UpGE=;
	b=NKWL25eZHBoBvAxjeGPgDOq2E4jYvbthUeuao6LCyiap9o9O0LkQ4hWdxiA8d2HHvKKr5H
	8nf+NDrPs9FdxbW9T2DSpPIjXQgULky0+RC/HiFobPZRQJD7J4sJOyy5TQwJbErg8QKvzi
	huS+QYBGqliB4TxKozY6QS4HgK8kNdc=
Received: from [192.168.168.200] (161-97-228-135.lpcnextlight.net [161.97.228.135])
	by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 065696c1 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO)
	for <9front@9front.org>;
	Sat, 28 May 2022 17:54:24 -0500 (CDT)
Message-ID: <3e08a1f8-205c-dfbd-0d37-39503d9c363f@posixcafe.org>
Date: Sat, 28 May 2022 16:54: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: <FA4FA4789598BE723F7D8E68D7D8AA37@eigenstate.org>
From: Jacob Moody <moody@mail.posixcafe.org>
In-Reply-To: <FA4FA4789598BE723F7D8E68D7D8AA37@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: asynchronous structured persistence hypervisor-based ORM over ActivityPub just-in-time component 
Subject: Re: [9front] git: use new /dev/drivers for privdrop
Reply-To: 9front@9front.org
Precedence: bulk

On 5/28/22 13:41, ori@eigenstate.org wrote:
> Quoth unobe@cpan.org:
>> For example, say I want a sandboxing area for people to "try 9front".
>> With moody's recent work, it removes a big attack vector by
>> restricting certain drivers.  But isn't it still possible to fork-bomb
>> a server, or to just cause unnecessary churn (i.e., computation), or
>> just open too many files, or fill a disk?
> 
> Yes.
> 
> I'm not aware of anyone trying to protect against denial of
> service with shared resources. This work mostly is about
> preventing data leakage.
> 
> 

I dont have too much interest in doing quotas. The approach
I want for dealing with shared resources is to remove the
resources you dont need. Attempting to block only misuse of resources
seem error prone. With that being said it might be nice to increase
the list of capabilities that can be eroded. Currently there are
some devices that are tied to other capabilities:

devmnt(#M) is tied to the mount system call.
devpipe(#|) is tied to the pipe system call.

The first was done to emulate RFNOMNT, the later
fell out from how syspipe is implemented. I might purpose
expanding this list a bit further:

devup(#d) could be tied to sysdup, if sysdup implemented itself through devdup.
devproc(#p) could be tied to forking new processes.
or even
devroot(#/)/devmnt could be tied to the ability of doing any kind of walks. (open fds would be preserved)

This would allow you to setup an environment where a fork bomb/fd exhaustion is not possible.
I also have some interest in getting clean instances of some kernel drivers, namely /srv and /proc.
My current running thought is through an attach argument:

bind -c '#sc' /srv
bind -c '#pc' /proc

This would of course affect future walks without the attach option.
This allows the devices to be used without having to introduce the global state.
Another thought that has been kicked around is a permanent bind/mount flag: MPERM.
Which could prevent future binds/mounts/unmount of that specific file/dir.

A bit of a thought dump, but wanted to get some input on potential ways we can go
with cutting off further capabilities.


Thanks,
moody