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.2 required=5.0 tests=NICE_REPLY_A, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18996 invoked from network); 29 May 2022 00:25:26 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 29 May 2022 00:25:26 -0000 Received: from dpmailmta01.doteasy.com ([65.61.219.13]) by 9front; Sat May 28 20:23:33 -0400 2022 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=192.168.101.81; Received: from dpmailrp01.doteasy.com (unverified [192.168.101.81]) by dpmailmta01.doteasy.com (DEO) with ESMTP id 92050001-1394429 for <9front@9front.org>; Sat, 28 May 2022 17:23:22 -0700 Return-Path: Received: from dpmail01.doteasy.com (dpmail01.doteasy.com [192.168.101.1]) by dpmailrp01.doteasy.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTP id 24T0NL6P022915 for <9front@9front.org>; Sat, 28 May 2022 17:23:22 -0700 X-SmarterMail-Authenticated-As: fde101@fjrhome.net Received: from [192.168.1.75] (pool-173-67-134-144.hrbgpa.fios.verizon.net [173.67.134.144]) by dpmail01.doteasy.com with SMTP; Sat, 28 May 2022 17:23:03 -0700 Message-ID: <77932a1a-62f8-d7e2-e98b-8da5cea46285@fjrhome.net> Date: Sat, 28 May 2022 20:23:01 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US To: 9front@9front.org References: <3e08a1f8-205c-dfbd-0d37-39503d9c363f@posixcafe.org> From: "Frank D. Engel, Jr." In-Reply-To: <3e08a1f8-205c-dfbd-0d37-39503d9c363f@posixcafe.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Exim-Id: 77932a1a-62f8-d7e2-e98b-8da5cea46285 X-Bayes-Prob: 0.9999 (Score 4, tokens from: base:default, @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.1 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 017Aonl7m - 7217cd6eb5b6 - 20220528 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.81 X-Originating-IP: 192.168.101.81 List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: DOM service component Subject: Re: [9front] git: use new /dev/drivers for privdrop Reply-To: 9front@9front.org Precedence: bulk Fork bombing might not be possible in that scenario, but it is because forking would be impossible to do at all? People trying the OS through the type of sandbox test system being proposed wouldn't really be able to do anything to test the system if they cannot create new processes, but allowing that to go on unchecked (without limits) could impact other users. I tend to agree that if this is a use case to be considered, a quota of some kind would be in order. This would also eliminate the need for the somewhat questionable idea of using a "fake" device to serve as a process security mechanism for the fork call, as one could simply set a quota of zero. On 5/28/22 6:54 PM, Jacob Moody wrote: > 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 >