9front - general discussion about 9front
 help / color / mirror / Atom feed
From: "Frank D. Engel, Jr." <fde101@fjrhome.net>
To: 9front@9front.org
Subject: Re: [9front] git: use new /dev/drivers for privdrop
Date: Sat, 28 May 2022 20:23:01 -0400	[thread overview]
Message-ID: <77932a1a-62f8-d7e2-e98b-8da5cea46285@fjrhome.net> (raw)
In-Reply-To: <3e08a1f8-205c-dfbd-0d37-39503d9c363f@posixcafe.org>

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
>


  reply	other threads:[~2022-05-29  0:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-28 16:51 ori
2022-05-28 19:23 ` unobe
2022-05-28 19:41   ` ori
2022-05-28 22:54     ` Jacob Moody
2022-05-29  0:23       ` Frank D. Engel, Jr. [this message]
2022-05-29  1:00         ` Jacob Moody
2022-05-28 21:47 ` covertusername967
2022-05-28 22:07   ` ori
2022-05-28 23:24     ` adr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=77932a1a-62f8-d7e2-e98b-8da5cea46285@fjrhome.net \
    --to=fde101@fjrhome.net \
    --cc=9front@9front.org \
    --subject='Re: [9front] git: use new /dev/drivers for privdrop' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).