Re: [Plash] What sandboxing would be the best?

[Mark Seaborn]

address@hidden wrote:

> Recently I had the idea to make an application packaging,
> sandboxing, and distribution system, similar to klik2 (see
> http://klik.atekon.de/wiki/index.php/Virtualization_Options).
> Essentially I want to make a system that executes an unmodified
> application (such as Firefox, GIMP, VLC...) inside a COW system (as
> seen in the image), so that the application can see some/all of the
> base system, its own files, and its configuration files. The entire
> tree looks RW, so the application can write and delete whatever it
> wants, but all the changes go to a separate COW folder.
> This would only be necessary for existing applications. If an
> application is designed specifically for this system, it could see
> the real filesystem but only be able to write in its designated
> configuration directory. No application can damage the computer.

I don't think copy-on-write (or a union FS with a write layer as
implemented in Plash) is very important.  I used COW/union directories
in Plash's Debian-based package system because it was easy to do and
because some Debian preinst/postinst scripts write to /etc or /var.
But beyond that, it is not really used.

What's more important is to provide a way for the user to grant
applications access to their files (read/write or read-only) via a
file powerbox interface.  That will give you confidentiality as well
as integrity.


> I have tried a few sandboxing methods:
>
> 1: aufs + chroot: My original idea was to mount a union filesystem
> somewhere and then chroot the program there. This would be the
> simplest and best approach for the COW part, but chroot jails are
> not very secure, so my second idea was to add some AppArmor
> restrictions. The real problem is that aufs refuses to mount
> anything that includes root because that would cause a recursion
> problem, although that could be patched or worked around.

I am not sure how well AppArmor works with chroot jails.  My
understanding of their path-based permissions system is that after
resolving a filename to an inode, they try to map the inode back to a
filename on which they do a permissions check.  This doesn't coexist
well with chrooting, hence some of the criticism of AppArmor when it
was proposed for inclusion in the mainline kernel.

How important is security to you?  Do you want to be secure against
malicious applications, or do you just want a safety net to guard
against accidents?


> 2: VServer (http://linux-vserver.org/): VServer is designed for
> running multiple virtualized operating systems using the same
> kernel. It has a COW option that maybe could be tweaked to do what I
> need. I wouldn't have considered this if it wasn't because Bitfrost
> (from the OLPC project, see http://wiki.laptop.org/go/Bitfrost )
> uses it.

I don't think Bitfrost does use VServer now, although they planned to
use it initially and may have started off using it.  I am not sure how
much of Bitfrost got implemented in the end.

How much do you want to depend on a non-mainline kernel?


> 3: Plash: It seemed the ideal tool to use, except for a few things:
> first, some things look "unpolished", and there doesn't seem to be a
> lot of information available, compared to other methods; second, and
> that's the important thing, according to
> http://article.gmane.org/gmane.comp.security.plash/104 , it seems
> the COW part is not yet implemented.

Adding COW - copying a file at the point where it is opened for
writing - would be trivial.  I just didn't hit the point where I
needed it.  Adding whiteouts for directory entries would be a little
harder, but not difficult if the COW layer were written in Python.
(The current implementation is in C.)

One of the problems I found was that some programs do not work under
Plash because they use /proc/self/maps or /proc/self/fd, which are
hard to implement in Plash's architecture.  I think in most cases it
would not be hard to change applications to use other mechanisms, but
I don't have the resources to package and maintain patches against
lots of applications.

At the moment I am doing some work on Native Client [1], which has the
potential to be more secure than Plash and virtualize more operations,
but work under Windows and Mac OS X as well as Linux [2].  It's still
at an early stage, however [3].

Mark

[1] http://plash.beasts.org/wiki/NativeClient
[2] 
http://lackingrhoticity.blogspot.com/2009/01/what-does-nacl-mean-for-plash.html
[3] http://lackingrhoticity.blogspot.com/2009/05/progress-on-native-client.html