9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Jacob Moody <moody@mail.posixcafe.org>
To: 9front@9front.org
Subject: Re: [9front] git: use new /dev/drivers for privdrop
Date: Sat, 28 May 2022 16:54:05 -0600	[thread overview]
Message-ID: <3e08a1f8-205c-dfbd-0d37-39503d9c363f@posixcafe.org> (raw)
In-Reply-To: <FA4FA4789598BE723F7D8E68D7D8AA37@eigenstate.org>

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.


  reply	other threads:[~2022-05-28 22:56 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 [this message]
2022-05-29  0:23       ` Frank D. Engel, Jr.
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:

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

  git send-email \
    --in-reply-to=3e08a1f8-205c-dfbd-0d37-39503d9c363f@posixcafe.org \
    --to=moody@mail.posixcafe.org \
    --cc=9front@9front.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).