Is it possible to sandbox the entire system?

Xyne · 2009-09-18 01:38:27

DISCLAIMER
This is partly just thinking out loud.
There may be some completely obvious solution for achieving this that I have not come across.
My ideas may be flawed.

I saw the other thread about sandboxing but that had a different focus and went in a different direction than this hopefully will.

First, by sandboxing I mean the following:
* let an application see the actual system, but only selectively, e.g. make /usr visible but /home inaccessible
* intercept all writes to the system
* let an application see all intercepted writes as though they have actually occurred
* intercept all network communication and allow the user to approve or deny it, e.g. enable a source download from one site but prevent the application from calling home to another
* the application cannot escape the sandbox
* the application should not be able to detect the sandbox

Is this possible?

First I thought about using FUSE to mask the entire filesystem but this would affect all applications and probably wouldn't work on a running sysem.
Then I thought about using virtualization. Maybe it would be possible to create a fake base image of the live host system and then add an overlay to that to create a sandboxed virtual clone of the host system. The network connection could probably by the host in that case.

I don't know if it would be at all possible though to create a fake base image of the live host system. I also don't know if it would need to be static or if the image could remain dynamic. In the latter case. it would probably be possible to create the image with FUSE. Using FUSE it might even be possible to forgo the overlay image as FUSE itself could intercept the writes. There are obvious complexities in that though, such as how to present changes to a file by the host to the guest if the guest has modified it previously. I also have no idea if the guest system could use a clone of the hosts file system.

Why I would want to do this:
* "Safely" test-run anything while protecting your system (hide your sensitive data, protect all of your files, control network access)**.
* Simplified package building: build the application as it's meant to be built in the sandbox, compare the sandbox to the host and then use the differences to build the package***.
* It would be cool.

** Before anyone interjects with the "only run trusted apps" mantra, this would also apply to trusted apps which might contain bugs. Let's face it, most people do not plough through source code of trusted apps before building/installing/running them.

*** This was prompted by my ongoing installation of SAGE which is built in the post-install function instead of the PKGBUILD itself due to the complexities of the build process. The general idea is to create a way in which all application that can be built can be packaged uniformly.

chpln · 2009-09-18 01:57:35

I think per-process namespaces will be able to fulfill half of the requirements. Intercepting writes and network traffic, however, I'm not so sure about.

See here: http://glandium.org/blog/?p=217 for a nice explanation of per-process namespaces.

Xyne · 2009-09-18 02:36:27

chpln wrote:

I think per-process namespaces will be able to fulfill half of the requirements. Intercepting writes and network traffic, however, I'm not so sure about.
See here: http://glandium.org/blog/?p=217 for a nice explanation of per-process namespaces.

Thanks chpln, I think that might fulfill much more than half the requirements.

I need to look into it, but my first thought is that it should be possible to use FUSE to mask the entire system in a per-process namespace. That takes care of both selective reading and write interception. Obviously I need to test it with some proof-of-principle implementation but this looks promising (from your link at least).

ngoonee · 2009-09-18 03:41:03

Am not in any way an expert in these matters, but a simple chroot with selective symlinking and a fake networking layer should do it, shouldn't it?

Xyne · 2009-09-18 03:51:15

ngoonee wrote:

Am not in any way an expert in these matters, but a simple chroot with selective symlinking and a fake networking layer should do it, shouldn't it?

I've found too many articles that say that chroot is not meant for creating a secure environment and should not be used as such. There seems to be plenty of ways to break out of a chroot "jail". I don't think that symlinking would work either as that could give an application write access to whatever is symlinked (maybe that can be configured).

I'll look into creating a fake networking layer though (I have no idea how, but I'm sure a few searches will get me started).

Thanks.

ngoonee · 2009-09-18 06:21:22

I think if you change the permissions of a symlink then it would be like changing the const-ness of a C++ pointer, it means THAT pointer can't be used to manipulate the object.

Concerning the non-security of chroots, sure its possible to 'break out' (I've probably read some of the articles you've mentioned), but this would require specific actions on behalf of the app. I'm sure a 'bugged' app isn't trying to break out of a chroot, only real-life humans who know to ask themselves whether they're in a chroot or not.

Xyne · 2009-09-18 07:20:06

Are you sure that you can change the permissions of symlinks themselves? I think I've tried to make files read-only via symlinks on a local server but ended up using bindfs because it wasn't possible. Even if you can, symlinking everything that might be necessary for a given environment would not be ideal, plus I don't think symlinks can be used across different filesystems.

If a real-life human can figure out if it's he/she is in a chroot and break out of it, then he/she can write a script to do the same. I want a sandbox that could run malicious code with no effect on the system (if that's possible). Also, I think if the chroot idea were truly feasible, makepkg would have been using it for years already to simply install packages in the chroot as you normally would and then package them. There would also be several sandbox applications that could run applications safely. So far I have yet to find any.

I admit that I haven't looked into using a chroot in detail though and of course I may have missed some application which creates such a setup. Right now I think using per-application namespaces with fuse seems the most promising but I won't know until I've finished implementing a test application. If it turns out that it's a dead end I'll take harder look at chroot but it really doesn't seem to be able to do what I want.

SiC · 2009-09-18 08:35:53

Have you looked at UserMode Linux? It could be a starting point for you, not sure though.

Xyne · 2009-09-18 09:56:37

@SiC
Interesting. I'll have to look into that too. Thanks.

General note: this community rocks

scorpyn · 2009-09-18 11:54:46

RSBAC Jail perhaps?

http://books.rsbac.org/unstable/x2223.html

Requires a patched kernel though iirc.

Xyne · 2009-09-18 13:25:59

@scorpyn
That seems to have some nice features but the need for a patched kernel would be a problem. It's on the "look into it" list now though. Thanks.

flamelab · 2009-09-18 13:50:01

When I read your first post, I though of SELinux http://danwalsh.livejournal.com/28545.html

Is it what you want ?

moljac024 · 2009-09-18 14:48:15

Xyne, no doubt that you've heard about the OLPC project. I read a long time ago that they had some sort of sandboxed system that was immune to malicious code, it was achieved with some virtualization technology.... I don't remember the details, but I'm sure you could google it up...

Last edited by moljac024 (2009-09-18 15:08:05)

Skoll · 2009-09-23 17:43:31

There should be a sandbox in the new Fedora but it's based on SELinux.
http://danwalsh.livejournal.com/31146.html
http://danwalsh.livejournal.com/28545.html

Last edited by Skoll (2009-09-23 17:43:44)

kjon · 2009-09-23 18:58:08

Xyne, about sandboxing the entire filesystem. Why don't you try using aufs?. Setting the root as a read-only branch and your /sandbox as the writable one. That should do the trick. You can capture the differences using this directory.

smartboyathome · 2009-09-23 19:01:39

kjon wrote:

Xyne, about sandboxing the entire filesystem. Why don't you try using aufs?. Setting the root as a read-only branch and your /sandbox as the writable one. That should do the trick. You can capture the differences using this directory.

+1! I was just about to suggest this. This would be a perfect application of it.

Xyne · 2009-09-23 22:00:51

I'm in the middle of writing my own FUSE application. I'll take a look at aufs but I"m really hoping that it's not capable of doing exactly what I have in mind.

Then again, I enjoy reinventing the wheel.

Thanks in both cases.

Gen2ly · 2009-09-23 22:05:26

Fedora is doing sandboxing for the desktop:

Fedora 12 demonstrates sandbox for desktop applications

Pretty cool concept really. And I thought apparmor was being the rage.

Xyne · 2009-09-24 01:33:12

I've been testing aufs and it can do almost exactly what I want.

mount -t aufs -o br=/tmp/rw=rw:/=ro none /tmp/mount

That will make everything in "/" appear to be in "/tmp/mount". Changes to files that appear to be in "/" will be intercepted and applied to copies of the targes in "/tmp/rw". That's exactly what the FUSE application that I'm working on does.

The problem is that all filesystems mounted under "/" (e.g. /home) do not appear. It's probably possible to set up, but at this point the FUSE approach seems more promising because the entire system remains visible inside the mountpoint.

There's a good chance that I've missed something in the aufs documentation (which would benefit greatly from more examples) but it feels like it would take longer to master the documentation and search for usage than it would take to finish what I'm working on now.

It's frustrating not to know which path is most likely worth the effort.

Xyne · 2009-09-27 15:44:16

Anyone following this thread should take a look at http://bbs.archlinux.org/viewtopic.php?id=81027

Skoll · 2009-09-27 16:38:35

If you are still interested I found Plash http://plash.beasts.org/wiki/ . However I didn't try it.

Last edited by Skoll (2009-09-27 16:38:45)

shining · 2009-09-27 21:52:14

Xyne wrote:

*** This was prompted by my ongoing installation of SAGE which is built in the post-install function instead of the PKGBUILD itself due to the complexities of the build process. The general idea is to create a way in which all application that can be built can be packaged uniformly.

This reminded me of some interesting doc about package management I read when doing LFS years ago .

Read the first two sections of http://www.linuxfromscratch.org/hints/d … g_trip.txt : background and idea.

Arch Linux

#1 2009-09-18 01:38:27

Is it possible to sandbox the entire system?

#2 2009-09-18 01:57:35

Re: Is it possible to sandbox the entire system?

#3 2009-09-18 02:36:27

Re: Is it possible to sandbox the entire system?

#4 2009-09-18 03:41:03

Re: Is it possible to sandbox the entire system?

#5 2009-09-18 03:51:15

Re: Is it possible to sandbox the entire system?

#6 2009-09-18 06:21:22

Re: Is it possible to sandbox the entire system?

#7 2009-09-18 07:20:06

Re: Is it possible to sandbox the entire system?

#8 2009-09-18 08:35:53

Re: Is it possible to sandbox the entire system?

#9 2009-09-18 09:56:37

Re: Is it possible to sandbox the entire system?

#10 2009-09-18 11:54:46

Re: Is it possible to sandbox the entire system?

#11 2009-09-18 13:25:59

Re: Is it possible to sandbox the entire system?

#12 2009-09-18 13:50:01

Re: Is it possible to sandbox the entire system?

#13 2009-09-18 14:48:15

Re: Is it possible to sandbox the entire system?

#14 2009-09-23 17:43:31

Re: Is it possible to sandbox the entire system?

#15 2009-09-23 18:58:08

Re: Is it possible to sandbox the entire system?

#16 2009-09-23 19:01:39

Re: Is it possible to sandbox the entire system?

#17 2009-09-23 22:00:51

Re: Is it possible to sandbox the entire system?

#18 2009-09-23 22:05:26

Re: Is it possible to sandbox the entire system?

#19 2009-09-24 01:33:12

Re: Is it possible to sandbox the entire system?

#20 2009-09-27 15:44:16

Re: Is it possible to sandbox the entire system?

#21 2009-09-27 16:38:35

Re: Is it possible to sandbox the entire system?

#22 2009-09-27 21:52:14

Re: Is it possible to sandbox the entire system?

Board footer