Re: POSIX

[Bas Wijnen]

On Wed, Oct 26, 2005 at 02:33:08PM -0400, Jonathan S. Shapiro wrote:
> 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 wasn't planning to give any access to it that it doesn't need.  As you said,
which programs need access to the filesystem at all anyway?  The low-level
utilities (ftp, cp, etc) do, but we'll port them so they work on our system.
We can configure which programs can access which files or directories if this
is desired.

Note that I planned to use a POSIX-box per process, so they all think they're
the only running process on the system.  Except perhaps if the user
specifically asked for two processes to be in the same jail, but that would be
an exception.

> 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.

I don't think this would happen.  You're not having a window with a POSIX
desktop like xvncviewer.  Each program has its own jail, and they have normal
windows which look completely normal to the user.  That's what I meant earlier
by "not second class citizens".

> 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.

That shouldn't happen, since firefox will not have access to the filesystem
except write-only access to ~/downloads.

> 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!

Obviously it isn't.  But this is not needed either.

> 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.

This problem, like the first one, is present for non-POSIX applications as
well.  If you want read-only access, what do you mean by it?  How do I prevent
my data to become shared when I don't want it?

Let me give an example of a program which will most probably need a POSIX box
to run: apache.

All the things that a web server needs to do are so different in POSIX than it
will be for us, that it is likely very hard to port it.  So we will put it in
a POSIX box.  What capabilities do we give it?

Well, probably read-only (with the usual "what is read-only" problem) access
to all parts of the filesystem where web-pages are located (/var/www,
~/public_html for all users) and its configuration files.  Perhaps write
access for some exportable server-side scripting stuff.  And of course,
network access to the ports it needs.

For the server-side scripting features we most likely need to give it access
to /bin as well (which should be constructed in a confined way, as you
indicated previously).

Then it can do all its usual POSIX things, and as long as he has the
capabilities for it, everything works fine.  Note that a non-POSIX web server
needs exactly the same capabilities.  Now if it's taken over by a cracker,
there isn't any security lost that was available in the non-POSIX version.
Well, ok, if there is password checking in there, then probably the password
file for that is compromised.

So when do we get problems?  When a POSIX program spawns a lot of processes
(which will all be in the same POSIX box) which all need different
capabilities.  In that case, the parent program will be given all those
capabilities, of course, and that should indicate that it's a problem.  So
what kind of programs are that?  I can think of only one: a session manager.
Well, you shouldn't be running that one in POSIX mode anyway, it's about the
first thing we need to port (if it doesn't simply compile without change).

So summarizing, I think that if you put every program in its own POSIX box (as
far as they need that at all), they aren't any less secure than non-POSIX
programs (as long as they don't spawn children.  If they do, they should be
ported).

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature