• 1
Do you intend to make this a separate package, or merge it into some existing selinux rpm?

Sandbox is in policycoreutils-2.0.62-12.6.fc11.
Policy is in selinux-policy-3.6.12-41.fc11

I also played with MLS levels and "worker-controller" for this...

When I played with SELinux (a while back) I tried something similar...

One approach I looked at was using to use a pipe between two processes, one running in unconfined_t providing services to the "main program" which was in a sandbox restricted to only talking to its parent. This was flawed as effectively I would end up rewriting vast chunks of the user/kernel interface, and piping it between processes.

The other approach I tried, which fits in better with how SELinux works, was to use the MLS security levels. Basically, base system files like libc and other standard libraries can be labelled s0, the "less used" libraries s1, and finally non-operating system files (home directory) would be s2 and above. Programs running in an s3-s3 security context then can read and write user files, running in s1-s1 and below could only see standard system libraries.

Ultimately though, the SELinux model is just not particularly friendly for anyone who isn't building a box from scratch using a system-wide policy. A more accessible model would be the Java sandbox model of "here is a list of files and network locations that my program is expecting to access"...

Still, a few general purpose sandbox types in SELinux wouldn't be a bad idea...

Re: I also played with MLS levels and "worker-controller" for this...

May I know more on MLS level and "worker-controller" ,Is it BLP access policy

Re: I also played with MLS levels and "worker-controller" for this...

You are better off asking questions like this on the

SELinux Developers Mail List


It might be worthwhile to do a simple screencast video (with istanbul or other screen recorder app) of a couple of polgengui usage scenarios that you think people will commonly want to perform. The goal being making people more comfortable working with selinux via the guis.

preventing file reads

in your case how can one prevent unconfined users, root etc. from reading
a file created by the sandbox_t domain?

i was hoping something like the following would work(but it does not):
neverallow {domain -mysandbox_t} mysandbox_rw_t:file *;


Re: preventing file reads

Well the idea is sandbox_t domain is not able to create any files. it is only able to read/write open files handed to the sandbox. Trying to prevent unconfined users from reading sandbox files is not the goal. If you want to have confined users then you need to set those up on your system. I have written previously on how to do this.

Another idea would be to allow you to specify a list of files or directories that were copied into the sandbox filesystem after it was created. And maybe a list of file descriptors you wanted set to particular sockets.

And, of course, ideally you would like to just be able to vet every single access a program tried to make. But that's beyond the scope of what SELinux can do.

Introducing the SELinux Sandbox

User jasper22 referenced to your post from Introducing the SELinux Sandbox saying: [...] passwd > /tmp/users /bin/cut: /etc/passwd: Permission denied Read more: Dan Walsh's Blog [...]

what about limiting memory allocation?

Great article, this might be exactly what I need! I was wondering whether it would be possible to limit the memory each sandboxed process is allowed to allocate.

Re: what about limiting memory allocation?

We have experimented with cgroup integration, but the last time we played with it Firefox would crash for strange reasons.

-C qualifier is still there and you can play with it.

Re: what about limiting memory allocation?

Make that "-c"

  • 1

Log in