You are not logged in.

#1 2010-01-28 17:25:15

IgnorantGuru
Member
Registered: 2009-11-09
Posts: 640
Website

Sandboxing Options

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?

Offline

#2 2010-01-28 19:04:27

jason.blier
Member
From: Kakabeka Falls, ON
Registered: 2010-01-19
Posts: 11

Re: Sandboxing Options

EDIT:  My Bad - you already mentioned Xyne's project in your post.

-Jason

Last edited by jason.blier (2010-01-28 19:06:45)

Offline

#3 2010-01-28 19:21:58

IgnorantGuru
Member
Registered: 2009-11-09
Posts: 640
Website

Re: Sandboxing Options

jason.blier wrote:

EDIT:  My Bad - you already mentioned Xyne's project in your post.

-Jason

The specs on that project look promising, but I didn't get far following his instructions, as I posted there.  I assume the fuse mount can't read the password file since facadefs is run as a user, but as a result his su instructions don't work, and I was uncomfortable running it as root.  Maybe someone familiar with su and chroot can give me some advice.  I think he could use a debugged how-to on how to use/test it.

Offline

#4 2010-01-28 22:05:55

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,110
Website

Re: Sandboxing Options

Chromium in the extra repo is built with its own sandbox.

Ubuntu uses AppArmor, which behaves somewhat like a sandbox, although it requires the user to define how the sandbox actually behaves. More of a playpen than a sandbox. Wait, wat?

Seems like this wouldn't be hard to do in the context of a union mount or maybe a chroot.

Offline

#5 2010-01-28 22:14:42

IgnorantGuru
Member
Registered: 2009-11-09
Posts: 640
Website

Re: Sandboxing Options

falconindy wrote:

Chromium in the extra repo is built with its own sandbox.

Personally, I would never trust Google for my browser, so that's not an option.

Seems like this wouldn't be hard to do in the context of a union mount or maybe a chroot.

I'd like to see the rough details on that.  I think I'm starting to get how chroot could be used to do this... I might play with that.  How would a union mount be useful?

I just got Firefox sandboxed using Xyne's FacadeFS.  In fact I'm typing this post from it.  Only limitation is the Save As... dialogs don't work.  But maybe that can be fixed.

Offline

#6 2010-02-02 19:39:20

IgnorantGuru
Member
Registered: 2009-11-09
Posts: 640
Website

Re: Sandboxing Options

After familiarizing myself with Xyne's work I developed a solution for this.  Written entirely in bash and using only core commands like mount and chroot for sandbox creation, I believe it is quite secure and fills a niche for an easy to use sandbox for Firefox.  It can also create and use multiple sandboxes and can run any program in them with flexible profiles.  You can check out the details here...
http://igurublog.wordpress.com/download … t-sandfox/
http://aur.archlinux.org/packages.php?ID=34261

Offline

#7 2010-02-02 19:45:02

lucke
Member
From: Poland
Registered: 2004-11-30
Posts: 4,018

Re: Sandboxing Options

Let me just mention isolate.

Offline

#8 2010-02-02 19:54:06

broch
Banned
From: L.A. California
Registered: 2006-11-13
Posts: 975

Re: Sandboxing Options

1) chroot is not security tool (never was)
2) BSD jail (better OpenVZ) is ported to linux, I don't know how well though
3) Novell's Apparmor is probably what you looking for

Offline

#9 2010-02-02 19:57:37

IgnorantGuru
Member
Registered: 2009-11-09
Posts: 640
Website

Re: Sandboxing Options

lucke wrote:

Let me just mention isolate.

Sure now you tell me after I worked all week on this!  smile

That looks interesting and similar in some ways, although from the description of how it works it sounds like it serves a different purpose - not sure that you would easily get an app like Firefox to run under it.  Sandfox runs as your normal user, which is more flexible.  But I will look over that to see if I get an other ideas from it.  Thanks.

Offline

#10 2010-02-02 20:01:24

IgnorantGuru
Member
Registered: 2009-11-09
Posts: 640
Website

Re: Sandboxing Options

broch wrote:

1) chroot is not security tool (never was)

I don't claim to be an expert, and welcome feedback on the issue, but from my research on it, running a normal user in a chroot jail is highly secure.  Running root in a chroot jail is not, but that doesn't apply to this.

2) BSD jail (better OpenVZ) is ported to linux, I don't know how well though

I'll take a look at that.

3) Novell's Apparmor is probably what you looking for

There are other solutions for this - for example Fedora uses SELinux.  But I was looking for a solution that is more 'ready to run'.  I also don't trust Novell - that is why I ditched SUSE.  wink

Offline

#11 2010-02-02 20:15:08

Ultraman
Member
Registered: 2009-12-24
Posts: 242

Re: Sandboxing Options

IgnorantGuru wrote:

2) BSD jail (better OpenVZ) is ported to linux, I don't know how well though

I'll take a look at that.)

Are we talking about LXC here? Linux Containers.
I've been playing with that, and got stuck while trying to start a container. Seems my config file contains errors, but I just can't get seem to get them out of there... Followed the howto almost to the letter...
I'm interested in your progress smile

Offline

#12 2010-02-02 21:12:32

broch
Banned
From: L.A. California
Registered: 2006-11-13
Posts: 975

Re: Sandboxing Options

you would need to decide what do you want to do, then decide which set of security app will apply otherwise your arguments are contradictory (app sandboxing vs system hardening). Then you will be left only with few options.

your comparison of SELinux to apparmor is plain wrong:
SELinux vs RSBAC is more appropriate

Offline

#13 2010-02-02 21:24:11

lucke
Member
From: Poland
Registered: 2004-11-30
Posts: 4,018

Re: Sandboxing Options

I wouldn't say that comparison of AppArmor to SELinux is misguided. Both AppArmor and SELinux (and RSBAC and grsecurity's RBAC and TOMOYO and whatelse) provide mandatory access controls and this is what this is all about.

Offline

#14 2010-02-03 01:55:42

IgnorantGuru
Member
Registered: 2009-11-09
Posts: 640
Website

Re: Sandboxing Options

Ultraman wrote:

Are we talking about LXC here?

No - at least I'm not, but it looks interesting.  Unfortunately I think a lot of these approaches completely fail the Keep It Simple idea, which is bad for security.  Really we probably need a 'Linux2' that is designed from the ground up with this kind of resource isolation in mind, but that's not likely to happen, I think.  The alternative of trying to patch things, however elaborate, is never going to be reliable.  But as with security in general, you just do your best.

Offline

#15 2010-02-27 04:15:54

Viaken
Member
Registered: 2008-06-26
Posts: 14

Re: Sandboxing Options

How about sandfox?

Edit:

Oh...uh...don't mind me. Didn't get enough sleep last night. wink

Last edited by Viaken (2010-02-27 04:16:36)

Offline

#16 2010-02-27 13:34:26

IgnorantGuru
Member
Registered: 2009-11-09
Posts: 640
Website

Re: Sandboxing Options

Viaken wrote:

How about sandfox?

Edit:

Oh...uh...don't mind me. Didn't get enough sleep last night. wink

Thanks for the suggestion.  smile  Yours was the first email I read this morning at 5am before my brain was actually awake- and it didn't include the edit.  Needless to say you had me pretty confused.  lol

At any rate Sandfox has been working great.  In fact sometimes I forget it's there and wonder why I can't access a particular folder within Firefox.  Very trouble-free.

Offline

#17 2010-03-05 18:49:23

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 999

Re: Sandboxing Options

Just when I started thinking of creating a special user for firefox, I found this. Thanks IgnorantGuru

To those, who mentioned SELinux/AppArmor:
I think there is a difference between kernel level security and runtime sandboxing/chrooting. And there is a need of both.
For example, Ubuntu has AppArmored kernel (right?), but there are also tools like jailer, makejail and jailtool.

To stay on topic, I have a couple of pretty ignorant (not guru smile) questions. How does sandfox compare to the above tools? Is there a way to bind/bindro with a kind of noexec option? My /tmp is already noexec, but /home is exec...

Thanks.


Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd

Offline

#18 2010-03-05 20:11:12

IgnorantGuru
Member
Registered: 2009-11-09
Posts: 640
Website

Re: Sandboxing Options

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.

Offline

#19 2010-03-05 20:47:31

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 999

Re: Sandboxing Options

IgnorantGuru wrote:
Leonid.I wrote:

How does sandfox compare to the above tools?

... Sandfox simply uses the power of the root user to limit apps' access to the filesystem.

Oh, with this I agree (I read your post at ubuntuforums). I also prefer not to use SELinux/AppArmor, unless it's necessary.

What I meant is the comparison to simpler tools (which are perl/python scripts, AFAIK), like "makejail", or "jailtool", which are parts of Debian/Ubuntu... But perhaps I should use both side-by-side and compare myself -- I just found these apps to be quite debian specific, and completely absent in Arch, even in the AUR...

Thanks anyway,
L.


Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd

Offline

Board footer

Powered by FluxBB