• 1
It would sure be nice if you could control the limitations from the sandbox commandline.

For example, if I had some randombinarygame that needed to connect to to connect to the game server I shouldn't need to give it full network access (sandbox_net_t) I should be able to explicitly allow the few ports and destinations which are required and do this without having to modify my system wide SELinux policy.

Likewise, it would be very useful to allow that kind of targeted access to the file system. I.e. allowing access to a single file, (to avoid the copy performed by the sandbox tool, esp where the intent it to ultimately write back to that file) or to a dotfile directory. (Game can still keep a high score table but can't go stealing all my data)

Re: Ease of control

Lets take these one at a time. SELinux does not really give us the flexibility to change the policy on the fly like you suggest. Allowing you to open up a few selected ports would involve writing policy and assigning ports to it, compiling it up and loading it into the kernel. Not something I am going to allow the setuid app to do. You should bring this up for dicussion on the nsa selinux list because I agree that it is a good suggestion.

I think having a -S share option would be a good idea. The problem is in the execution. Do I bind mount the file into the new userspace or do I copy it in and copy it back out when I am complete. I would think bind mounts would be the best idea, although I would need to change the context on the file/directory that is being shared while it is in the sandbox.

  • 1

Log in