• 1

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
<selinux@tycho.nsa.gov>

  • 1
?

Log in