9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Jacob Moody <moody@mail.posixcafe.org>
To: 9front@9front.org
Subject: Re: [9front] [PATCH] private /srv attach option
Date: Tue, 31 May 2022 09:09:03 -0600	[thread overview]
Message-ID: <475b654b-641e-6f08-c5bc-bcf6aab4f51a@posixcafe.org> (raw)
In-Reply-To: <CAFSF3XOFoOwjY+SDNyDVo8dL8-VM_Y4uBjc=Q_GoqG5PCM2-eA@mail.gmail.com>

I spent the better half of yesterday thinking about how /srv fits into
the current work.

First lets talk about how we go about building an isolated namespace
as is. The general idea is to only use the root folders provided by #/,
then selectively binding in the necessities from the real root, then dropping
any reference to the real root from the namespace. This is roughly how the
current tcp80.namespace works, but this solution does not scale too well
to programs that require a lot of file system state.

An example is generally anything required out of /lib and/or /sys, these
are not folders given by #/ and binding in the entirety of them from
the real root isn't right either. So how do we setup the correct
state in /?

One way is to build a skeleton hierarchy stashed somewhere that can
be unioned on to /, and used as targets for binds from the real root
in the namespace file. This works pretty well for third party programs,
an example for this would be something like werc.

but shipping a skeleton for programs in tree sucks. So what else
do we have? Well there is always mntgen. But mntgen has some

1. There is some data leakage about what one client using through what folders show up when listing the root.
	Likely a somewhat easy fix
2. Mntgen only makes up directories at the root, we would want to extend this to child directories
	Also sounds like a doable fix
3. Mntgen is a userspace program, there is no facility for getting a fresh one in namespace files. You have to have
one sitting in /srv somewhere for it to be useful.

This last point is interesting and one I wanted to discuss more of. We could just provide a 'mntgen' command
to namespace files to get a private mount of mntgen. But you wouldn't want to do this if you are rebuilding
the namespace on each connection. A program wishing to do this could setup a mntgen/ramfs with the correct skeleton
in a private /srv to prevent having to share it with the rest of the system.

Now is the restriction to not being able to recurse through subsequent private /srv's once blocking
the global /srv an issue? I dont really think it is. I explicitly do not want chdev to proliferate
to every program on the system like openBSD's pledge. It is designed to be used at the very edge
of the process tree, for leaf processes that are handling potentially malicious input. In part due to
the fact that we never allow a process, or it's children, to regain access to something that has been lost.
This is to say that a program should know where it's process tree ends, and what capabilities it's children
will need. So you either end up with:

bind -c '#sp' /srv
chdev -r 's'

in the 'setup' phase of the parent if you know your children will never need to make another further private /srv.
If you do need to create a further private /srv, then simply kick that code snippet down the process
tree to the last place you need to substantiate the private /srv. If you know the child will want a private /srv
but the parent will not. Fork the child with RFNAMEG, then do 'chdev -r s' in the parent after the fork call.

This is only an issue if you:

1. Don't know what capabilities your children want.
	At which point chdev isn't very helpful to begin with.
2. Conditionally making a private /srv after you've begun reading potentially malicious input
	I think you kinda get what you aught to here.

I'm just trying to really rack my head for a scenario where you need to leave the global /srv on the table
because you don't know if your children will want another private /srv. If others have examples, please
let me know. I am pushing more because I _want_ it to be good enough for devsrv to just keep track of
sessions itself. I dont expect devsrv to be the last device we may want private sessions for, and growing
a new process group per device is not ideal. But maybe we can do a bit better then this,
I am going to poke around with an in-tree way (ctl file or similar) to see if that shakes out to being
a bit nicer. But I will say I do prefer the semantics of an attach option for getting a different 'tree'
of /srv, it feels right.

My grand plan is as you laid out, I want to turn namespaces in to security boundaries, and for the most part
we're there now. Chdev allows namespaces to be security boundaries.

The tricky part that we're trying to decide now is what tools do we want to give in order to make these types of namespaces
easier to build. It is much harder to lay out a plan for this. This mail serves to attempt to lay out what I have in my head
in this regard. The programs we choose to grow new features is dependent on their implementation quirks, such that our new use
case does not impose too much on to the existing code. So a lot of it turns in to 'see what the low hanging fruits are' and reflecting
on how/if these modifications produce a worthwhile tool.

So there's the big thought dump, pick it apart as desired.


  reply	other threads:[~2022-05-31 15:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-30 11:50 Jacob Moody
2022-05-30 14:44 ` ori
2022-05-30 17:26   ` Jacob Moody
2022-05-30 20:04     ` ori
2022-05-31  7:03       ` hiro
2022-05-31 15:09         ` Jacob Moody [this message]
2022-05-31 16:04           ` Jacob Moody
2022-06-08 14:48             ` Jacob Moody
2022-06-22 15:22               ` cinap_lenrek
2022-05-30 14:56 ` ori
2022-07-10 21:47 ` ori

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=475b654b-641e-6f08-c5bc-bcf6aab4f51a@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).