Sandboxing Options

Question

I did some searching trying to determine what options are available for sandboxing an app on Arch.  For example, run Firefox in a sandbox that confines access to a subset of the entire filesystem (read access to some folders, read-write access to other folders).  Basically something like what Fedora 12 can allegedly do.
I thought I'd post my conclusions in case I missed something and you can set me straight.  My conclusion is that this isn't really doable in any reasonably painless way.  It just doesn't seem like Linux in general has supported this form of security very well at all.  I found Plash which is basically what I want, but that seems to be Ubuntu-oriented.  Even the build-from-source instructions seem to be Ubuntu-only.  And the author comments that building glibc is difficult.  So without any detailed instructions I doubt I would have any success getting it to run on Arch, and I see no trace of anyone who reports doing so.  Plash also seems to be somewhat abandoned.  Do you think this would run on Arch, and how would you go about building it?
The author is currently working on a glibc port to NaCl.  Aside from the fact that NaCl is a Google product, and I don't trust anything Google does anymore than I trust Microsoft, it looks like that is very much a work in progress and not of current use.
There is this community contribution, FacadeFS, but it looks incomplete, and no one is talking about running something like Firefox inside it.  But I might play with it and see what it can/can't do.
Then there is OpenVZ, which seems to be more for servers and OS virtualization and requires a modified kernel.  And again, no reports of anyone using it with Arch, or any how-tos.
And the only Arch Wiki entry for sandbox is this.
If I could master a method for this I'd be happy to write a wiki entry like 'How To Sandbox Firefox'.  But I more or less think I'm too early - the tools aren't there.  Any thoughts?

Answer 1

Leonid.I wrote:How does sandfox compare to the above tools?
Hi - I'll give you my limited answer to this.  I've never used SELinux or AppArmor deliberately except by using a standard install of SUSE and Ubuntu.  They are much more involved solutions.  My understanding is they not only sandbox files but can also deal with sandboxing memory, cpu and network usage.  Also, if there is a root exploit or privilege escalation issue, even root may not be able to break out and into the entire system.  By contrast, an app in a Sandfox sandbox has the normal user's access to memory, cpu, and network usage.  Also, if there is an exploit that allows that user to gain root access, it's not so hard to break out of a chroot jail as root.  So there is no root containment.  Sandfox simply uses the power of the root user to limit apps' access to the filesystem.
On the other hand, SELinux and AppArmor have corporate and even governmental (NSA) ties, and are very complex.  With this complexity comes the risk of intentional and unintentional backdoors and exploits.  To me this is sort of like the anti-virus software on Windows - it can be like a virus itself in many ways.  Open-source and peer review is great, but when you're dealing with thousands or millions of lines of code, it has its practical limitations.  Personally I think people put too much faith in software that is 'open source', assuming people have actually reviewed the source in sufficient detail.  If Ken Thompson could put a backdoor in the open source C compiler in the relatively simple code of the 80's, imagine what can be done in the mountains of code today.  I think examining who works on the software and why is also important.  Are the people whose job it is to steal secrets (NSA, and some would save Novell as well) really interested in your security?  Personally, I doubt it.  Simply put, I don't trust the source (pun accepted).
To its benefit, Sandfox is simple to understand and uses only core Linux commands like mount, which have been well tested over the years.  On the other hand, it's not as comprehensive a solution to overall security.  Will it stop Mozilla plugins from roaming your system?  Probably - if they can't get root then they're pretty well trapped (use a good root password).  Sandfox also uses virtually no system resources - one user told me he had two Sandfox sandboxes running on his EeePC, something he couldn't do with AppArmor.
Is there a way to bind/bindro with a kind of noexec option?
That's actually a good question.  Without looking into it I would say probably, although Sandfox does not currently implement this.  Sandfox bind mounts, and then remounts with nosuid and ro (for bindro).  So you could probably add noexec in that remount command as well.  If you want to mess with the script you could have it conditionally add noexec based on the name of the folder.  I may look into this next time I work on Sandfox.
Also, thanks for the cyberciti link - I hadn't come across that.