[Plash] Re: Plash Digest, Vol 36, Issue 2

[xavierpij]

Hello, and sorry for the delay.

> 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 agree with the powerbox idea, and that's why Plash would be helpful. The COW 
or Union FS was meant to allow existing binary applications that insist in 
modifying system/user files to run, while being able to keep all these changes 
in a single location. That way, an application may put its files wherever it 
wants to without messing with the whole system. Currently if you want to run, 
for example, Firefox, you have to put some parts in /etc, some in /usr/bin, 
some in /usr/lib, and some in /home/user/. However if you put a layer which 
redirected all writes to /apps/firefox/config/, you could then simply delete 
the folder and have a clean Firefox.
So basically, I want a method to convert an application into an application 
directory (http://roscidus.com/desktop/AppDirs)



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

I really haven't tried it, but a quick Google search of "AppArmor chroot" 
returns 
http://en.opensuse.org/AppArmor/Changes_AppArmor_2_1#Modification_to_chroot_handling
 , which seems to say that chroot works if you prepend the path.

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

Well, my primary objective was just the relocatable Application Directories, as 
an alternative to using repositories when downloading Linux software. Basic 
security like filesystem access control, or advanced security like resource 
limits or I/O control would definitely be useful, but if they are too hard to 
implement maybe I'll just skip them. Besides, there is still a very low amount 
of Linux malware.


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

That's true, http://wiki.laptop.org/go/Rainbow says that since version 0.7 it 
uses traditional file permissions by making new users on demand.

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

I'd not be very worried if I had to patch the kernel. Application sandboxing 
should actually be the kernel's job.

> 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.)
That is good to know. If I were better at programming I would try to do it 
myself.
> 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.
The original idea was to avoid patching applications. Some programs come only 
in binary form, or the makefile does not work and you have to spend two hours 
looking for the error, etc.
Does this happen with many applications or just a few ones?
Also what I noticed while trying pola-run was that console applications that 
use the curses library (bash, nano, less...) don't work properly. In bash, for 
example, tab completion and history don't work and the command prompt doesn't 
show.
> 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

Yes, Native Client looks promising, but it's not exactly what I need. I think 
I'll stick with Plash or AppArmor.