Have an application that you want to run, but without giving it full access to the rest of your system? Welcome to SELinux’s sandbox utility. In a few fairly simple steps, you can box in an application and not have to worry about it having full access to your system.
I have to admit, I have not always been the biggest fan of SELinux. The syntax for security framework is, shall we say, less than user-friendly. Actually, it can be downright anti-social. Be that as it may, SELinux can also be really useful if you’re willing to slog through the syntax and complexity. Actually, the syntax for sandboxing an application isn’t all that bad and after playing with sandboxing for a while, I’m interested in checking out SELinux more fully to see how it’s (and its tools) evolved since I last poked it.
You can use the sandbox utility to run an application in an SELinux “sandbox” that is confined to reading and writing standard in (stdin), standard out (stdout), and other file descriptors passed on the command line.
To put it more simply: Applications running in a sandbox are very restricted, and can’t read or write to files that aren’t explicitly allowed. Unless explicitly permitted, they also have no network access and so on.
Hands on with SELinux Sandbox
First, I’m doing this on a Fedora 14 system. If you’re running an earlier release or a different distribution with SELinux, it’s possible that some of the syntax has changed or the types will look at later aren’t present. If you’re using Ubuntu or openSUSE, or other distros that don’t have SELinux on by default, you may have to jump through some hoops to enable SELinux, but that’s beyond the scope of this article.
Let’s start off with a simple application. Let’s say you’d like to edit a file using Vim, within a sandbox. Run sandbox vi filename. Note that you get an error in Vim saying “permission denied” when trying to edit the file. This is because SELinux wasn’t explicitly told about the file you wanted to give Vim permission to.
Try sandbox vi -i filename instead. You’ll get a bit farther, but still have errors because the default behavior of Vim is to write a swap file (.filename.swp) and info file about its history. Now, that’s fairly benign behavior and we really don’t have a problem with that as a rule — but the assumption when running an application in an SELinux sandbox is that you don’t want it to do anything unexpected.
So, lesson one: The sandbox is very effective. Lesson two? You need to be fairly specific, because SELinux is very restrictive about what it allows and does not allow.
Before we get into the right way to do it, let’s try one more thing: Try to Ctrl-z out of Vim to get to a shell. What happens? If you’re running Vim within a terminal on the desktop, you should see a notice in the upper right-hand corner warning you about a SELinux security alert. Click on the SELinux icon and you’ll get a handy dialog that tells you what the alert was and what the offending application tried to do. In this case, it was a “signal” alert — Vim was trying to send a signal to the shell that is not allowed.
Doing it Right
Now, let’s fire Vim up again, but with a few more options. First, create a tmp and a sehome directory in your home directory or somewhere convenient. Note that it won’t allow you to use /tmp, so you’ll want to create a tmp directory elsewhere. Strictly speaking, it doesn’t have to be called tmp, but I prefer to have a tmp directory under my home directory anyway. Now that you have the extra dirs, try this:
sandbox -M -H sehome/ -T tmp/ vi
Now you can read and create files that exist in the sehome directory, and Vim can create its temporary files without being stopped by SELinux. But, you still can’t use Ctrl-z to get to a shell from within Vim.
Another thing you might notice — things are just a bit slower in the sandbox. SELinux does add a bit of overhead, not a lot — but it will be noticeable.
Running Firefox in a Sandbox
In particular, you’ll notice a slowdown with more complex GUI apps. But you may want to run things like Firefox in a sandbox if you’re very security and privacy conscious.
Now, Firefox is pretty useless without network access. The good news is that you have sandbox types that allow for Web browsing. Here’s what you want to run to get a Firefox session going:
sandbox -X -H sehome -T tmp -t sandbox_web_t firefox
Here you’re adding two things — the -X option, which tells SELinux “hey, I want an X sandbox,” and the type (-t) option which specifies a set of policies that offer the services (like networking) that Firefox needs to operate in a sane way.
SELinux runs a Firefox in a restricted session that doesn’t have access to rest of the system. That includes the X session. Firefox will run in a nested X server (Xephyr), and you won’t be able to even copy & paste from or to the Firefox session and other apps. But, it also means that Firefox is totally restricted from reading any other files on your system and that malicious Web pages or attacks on plugins like Flash are sandboxed as well.
Summary
This is, of course, just the tip of the iceberg. You can do quite a lot with an SELinux sandbox — if you can figure out what you want to do in a sandbox, odds are it can be done. We haven’t touched on several, more advanced functions yet — like sandboxing specific Firefox plugins or restricting resource usage in a sandbox.
If you’re using Fedora, Red Hat Enterprise Linux, CentOS, or another distribution that includes SELinux, you should definitely check out the sandbox functionality. Interested in more SELinux tips and tutorials? We’ll be covering more in the near future, along with tips on using the AppArmor framework as well.
