Idea: sandboxed portable apps

Okay, I have a vague outline of an idea for portable apps with filesystem sandboxing on Linux, using plain old chroot.

Folders containing the portable apps would reside somewhere in a user's home dir, and would look like a miniature Linux root filesystem:

Code:

Apps/
- appname-2.2.1/
-- bin/
-- dev/
-- etc/
-- proc/
-- share/
-- sys/
-- var/

Everything would be owned by the user in question.

The launcher obviously has to be a setuid root binary, or chroot won't work. It would be invoked as 'launch <appname> <app args>' by a user of the requisite group. On invocation, it would chdir to ~/Apps/appname, copy over the user's .Xauthority file, bind mount necessary virtual filesystems, and drop privileges to the limited user's via setregid() and setreuid(). Only then would it set necessary environment variables (including HOME=/), and finally invoke the application as the limited user who ran the launcher.

Result, in theory: one program running as a limited user in its own little filesystem sandbox, capable of reading and modifying files within that sandbox and nowhere else. If all the requisite libraries are included it should be quite portable too.

I'm thinking something like this might be useful for:
- Software development. (You want an IDE running in its own environment, with none of the host system's libraries and headers.)
- Web development. (You want to test a web app by running it locally.)
- Running different versions of the same software. (Chroot sandbox = no conflicts.)
- Running software designed for other Linux distributions. (Ditto.)
- Running Windows applications securely. (Wine in a chroot sandbox, you do the math.)

Does this sound sensible, or completely half-baked? What would be the possible problems with it (assuming that the setuid launcher is implemented securely, and that disk space is not an issue)?

 

I wouldn't rely on a chroot for a sandbox if the application isn't designed for it, or if measures aren't taken to harden it. Write access in a chroot can be a dangerous thing. What if the portable app needs root? Then the entire chroot protection is useless without some other form of protection.

For development purposes, yes, naturally chroot is a blessing.

Maybe look into LXC? It may interest you.

 

Yeah, I was thinking only for apps that do not need root.

I had been wondering about write access on binaries in the chroot though. Could that be abused to break out of the sandbox, even without root access?

LXC had struck me as another possibility. Much more complicated, but probably better in a lot of ways. Docker uses it now IIRC.

 

If they have write access to the setuid binary, possibly/ probably. Plus chroot + write access can sometimes mean escapes, though that always requires root as far as I know.

LXC is not production ready as far as I know, but it sounds more suitable for this.

 

That one's easy enough to avoid, just don't put any setuid binaries in the sandbox. Also setuid binaries run as the owner, so if everything is owned by the limited user...

Main problem I see is that binaries in the sandbox could be modified maliciously (e.g. to record keystrokes), or just plain deleted. But that is always a hazard when using binaries you have write access to, for things like browsing and opening documents. Still a problem though.

I'd thought of using UML (user mode Linux) for more complete sandboxing, at one point. But things like network access, getting a graphical display, and importing files into a UML jail are really nontrivial that way.

As far as LXC, my goal is basically to have a framework for sandboxed, portable applications that works on any current(ish) Linux distro, and does not require full root access. Like PortableApps for Windows, but with the added bonus of providing some level of isolation. LXC would qualify, except as you indicate it's not production-ready.

Any further suggestions? Are there any other ways that a standard Linux kernel can limit an application?

 

Namespaces may interest you as well. You could have a binary that sandboxes the application via ptrace, redirecting calls, etc. That's not great though, or easy.

 

Containers + cgroups.
Mrk