Re: POSIX

[Jonathan S. Shapiro]

On Wed, 2005-10-26 at 19:55 +0200, Bas Wijnen wrote:
> On Wed, Oct 26, 2005 at 11:30:39AM -0400, Jonathan S. Shapiro wrote:
> > On Wed, 2005-10-26 at 11:06 +0200, Bas Wijnen wrote:
> > > No, not as alternative.  Programs which need a POSIX box to run should 
> > > still
> > > be allowed to use all the cool Hurd features directly.
> > 
> > This would be very very pleasant. Unfortunately, it is very difficult to
> > achieve. The difficulty comes when you allow the insecure subsystem to
> > access things like your local files, which you want to protect.
> 
> That's what the POSIX box is for.  When the process makes POSIX calls, they
> will return as if it has access to a complete filesystem.  But in fact, it
> only accesses its own jail.  However, the jail does not prevent the process
> from making library/system calls to services which all Hurd processes (also
> non-POSIX) can access.

Then how is it a jail?

It sounds like we may be talking past each other. Let me use a concrete
scenario. I imagine from your description that I might have a protected
non-POSIX home directory, I might start up a POSIX jail, and I might
give that jail read-only access to my home directory. Personally I think
this would be unwise, but let me set aside my reservations for a moment.

I think you are proposing that as long as (a) the access is read-only
and (b) the POSIX subsystem is in fact a jail, then I should be okay.
And this does seem plausible.

Here is the first difficulty I anticipate:

The next move is that somebody decides to open up a network port for the
jail. For example, they wish to run firefox inside the jail.
Unfortunately, they forget that the POSIX jail has read-only access to
the home directory. All of your files are now disclosed to the world.

I see that both things are desirable, but I am not clear how to safely
manage them in a user-sensible way. Note that turning off home directory
before opening the network port is NOT good enough!

Here is a second difficulty:

My home directory isn't really a file system. It is a mapping from
strings (the filenames) to capabilities. These capabilities do not name
files. They name objects implemented by servers. One of these servers
may be the file server, but at the kernel level of abstraction we do not
know that.

The problem here is that you wanted read-only file system access. In
order to enforce this, we can either:

  1. Enforce it conservatively, which would preclude letting the POSIX
     box talk to servers, or
  2. Have a list of servers we "trust" to implement the "read-only"
     restriction correctly, or
  3. Allow confined subsystems that are "clone on open".

Possibly there are other variations that would work. I'm only trying to
point out that enforcing a read-only restriction in a system consisting
of active objects can be a tricky thing to get right.

shap