Re: [9front] git: use new /dev/drivers for privdrop

["Frank D. Engel, Jr." <fde101@fjrhome.net>]

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
>