Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 8:22 UTC (Wed) by epa (subscriber, #39769)
In reply to: Walsh: Introducing the SELinux Sandbox by gdt
Parent article: Walsh: Introducing the SELinux Sandbox

For example, you might run a script to encode all your FLAC music into Ogg Vorbis. That script will run as you, pr1268, so traditional Unix access control gives the script access to all of the files marked as owned by pr1268.

It seems the root of the problem (no pun intended) is that creating new users is such a heavyweight operation. It's like creating branches in CVS or SVN. You have to have root access to the whole system and edit some centralized files. Cleaning up a user is even more tedious (you have to check for any files the user owns). It would be better if there were a lightweight way to create new users, so user fred could create fred_x that has a subset of fred's permissions, and launch a process as user fred_x with certain capabilities such as network access masked out. Then when the process is finished, fred_x disappears (it was only visible to fred anyway).

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 12:37 UTC (Thu) by nix (subscriber, #2304) [Link]

Yes indeed. Long ago in the mid-1990s I had a pile of fugly sudoed shell scripts on Solaris that did exactly this: users could create and remove subusers that belonged to them, transfer files into those users and get them back afterwards. It was stymied by several things: lack of kernel support for 'subusers' (i.e. I wanted to express that user A could access all files belonging to user subA but not vice versa); and the fact that it was written in the shell, which meant I was never really confident that it wasn't actually adding security problems.

I should do it again, probably with help from PAM and/or userv this time to do the privileged gruntwork.