Could we write an SELinux policy that allows users to build scripts to process untrusted content into some output that they could safely use.
cat /tmp/UNTRUSTEDCONTENT | sandbox /sbin/filter.sh > /tmp/SEMITRUSTEDCONTENT
Another possible use case would be to tie sandbox into GRID jobs, or Condor. I could image an administrator saying that I will allow a grid job to run on my machine but I want SELinux to sandbox the job and make sure it causes no harm to my system, or from my system. I do not want GRID jobs becoming Spam Bots or somehow attacking the rest of my system. I definitely do not want them touching my homedir, since that is where firefox stores my credit card data.
I decided to write a policy called sandbox, it took me approximately 10 button clicks using system-config-selinux/polgengui in F11. I will show you how I did this later in the blog, if you are interested. You could use runcon to cause unconfined_t user domain to transition to the sandbox_t domain, but I decided to build a new tool called /usr/bin/sandbox that would do this for you.
The tool and policy are currently available in selinux-policy-3.6.12-41.fc11 and policycoreutils-2.0.62-12.6.fc11. My current intention with sandbox is not to handle X Apps, since these apps want to write all over the home directory ~/.gconf, ~/gnome., ~/.config ... and all over /tmp, along with use privs to talk to the X Server. I have some ideas on this for the future that I hope to experiment with.
So what were my security goals in writing sandbox.
- Has to be able to execute any binary on the system in a domain called sandbox_t.
- Since the goal here is to make a general purpose tool that anyone could use in a script, I did not want to limit the user to a particular app.
- Later we added a sandbox_file_t type that sandbox apps can Manage, files, directories, sock_files, fifo_files
- sandbox_file_t is only currently created if you execute sandbox as root, with the -M flag, this creates a temporary file system mount labeled sandbox_file_t under /mnt
- Sandbox_t needs to be able to read the executables, in order to execute them, we might experiment with using fexece, although there are currently no python bindings.
- sandbox_t domain to use shared libraries, so sandbox_t can read all libraries on the system.
- sandbox_t can use any open file descriptors passed to it by the shell, or any other app that would be able to execute the sandbox domain.
- But it remember it CANNOT OPEN or CREATE any file.
> sandbox id -Z
This command shows that sandbox ran the id command under the sandbox_t domain and chose the MCS label s-:c87,c905
If I wanted to create a file of users on my system from the /etc/passwd file, I could try
> sandbox cut -d: -f1 /etc/passwd > /tmp/users
/bin/cut: /etc/passwd: Permission denied
Read more: Dan Walsh's Blog