Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 17, 2009 23:22 UTC (Thu) by drag (guest, #31333)
In reply to: Walsh: Cool things with SELinux... Introducing sandbox -X by martinfick
Parent article: Walsh: Cool things with SELinux... Introducing sandbox -X

On most desktop machines the user account is the important target, not root. The important stuff is stored in /home, and that is all you need to do stuff like run keyloggers or sniff user's network traffic.

Therefore the biggest deal for security on a desktop is to contain a attacker in case they find a hole in one of your applications.

to post comments

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 17, 2009 23:26 UTC (Thu) by drag (guest, #31333) [Link] (6 responses)

I misread what your saying, sorry.

But I suppose a application running restricted in a Selinux is not really that much different then trying to make a a whole new container for each application. Your still going to have to find a way to manage permissions and poke holes in your containment system so that applications and users can interact in meaningful ways.

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 17, 2009 23:43 UTC (Thu) by martinfick (subscriber, #4455) [Link] (1 responses)

I was suggesting only putting real users in their own containers, not os users, not each application in its own container. Applications would get their own os users inside the real user's container. This way, real users would be root (in their container) and could manage creation/deletion/permission setting of application users using "adduser", "chmod", chown" ... Application users would be appropriately restricted to fs (/home...).

Naturally, a desktop environement that understood this could set up these application users with the appropriate settings for you, much like the way android does. Effectively, you could create an entire new distribution with this sole purpose with a true focus on desktop sandboxing. Sandbox profiles could be used. Default profiles could be created by the distribution and each app would have a suggested profile. Real users would be allowed to create/script their own sandbox profiles and could apply them to any application over ridding the distribution's suggestions.

If the real user needs to interact with other real users on the system, then appropriate bridges should be created, such as: mount a shared directory in both user's containers (a real host sysadmin would have to set these up)...

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 18, 2009 0:00 UTC (Fri) by martinfick (subscriber, #4455) [Link]

If you step back and think about it, most distributions sandbox servers quite a bit already by giving them their own users, and sometimes by putting them in chroots (and by using various other security mechanisms). Any bridging that needs to be done between server applications that was not anticipated by distributions (and there always is some) can be done because the person managing the servers typically has root privileges. This same ability needs to be extended to desktop users (on a multi-human user system).

But, distributions typically stop at sandboxing servers, why? Because to manage sandboxing you need root priviliges! Distributions do not typically sandbox human-user apps (desktop apps) because most human users do not have the privileges on a machine to create the necessary bridges between their apps if they were sandboxed. Human users really need "root level" control of their own domain to ever make sandboxing of applications manageable; no distribution can anticipate all the bridges between user applications that might need to be created. Thus, the need for a separate container for each human user, to give human users "root" privileges without compromising the host or other human users.

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 18, 2009 7:49 UTC (Fri) by mjthayer (guest, #39183) [Link] (3 responses)

For the general case of sandboxing applications to make sure they don't do nasty things to your user data, I wonder whether a user equivalent of dropping privileges (in this case for example access to the filesystem) would make the most sense? An application opens the resources it needs when it starts up and then drops the rights to open any new ones (and if necessary it forks off another, simple and specialised, process before dropping privileges to open any new resources for it that it needs to acquire later). If the application is open source, you mainly just have to study the initial code (opening and dropping privileges) for safety, and even if it is closed source, the author could provide a small open source wrapper to do that bit if they want to convince their users that they are "clean".

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 18, 2009 15:25 UTC (Fri) by martinfick (subscriber, #4455) [Link] (2 responses)

Wouldn't it just be easier any more in line with traditional unix methods to use user and group permissions for this?

My bookmark files should be owned by the bookmark group, my email by the mail group and my financial info by the finance group. No new API needed, if I want an application to be able to read my email, I put the user for that application in the mail group. No fancy language restricted APIs like in android, and no fancy privilege mechanisms needed. Scripts could do it today. This security binding would remain external to programs (and thus user changeable) instead of having to be programed into every app. Maybe the programmer gets it right, maybe not, you should be able to chose and see it easily. Maybe you want to have multiple instances of the same app with different privileges! You could have a secure web browser that runs as a secure user that you only use to access your bank and is the only one you ever let access your bank. This way, it would not be exposed to compromises from other sites. Imagine a uzbl front end which launches an a uzbl browser instance as a separate user for every site it visits! You could then tweak the privileges that your browser has for every site and assign groups to those users.

No new tools required, but certainly new/better/easier to use GUI tools might be developed to make it easier to manage user/groups and permissions. Security might become something that is considered important to be able to manipulate inside applications. Save dialogs might eventually have options to set group ownership and permissions on saved files, options tabs would have settable defaults for various internally saved files (bookmarks, cookies, passwords...) This would be helpful even today in multi-human user systems. This GUI integration does not typically exist and I suspect would be welcomed by many corporate environments?

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 22, 2009 18:22 UTC (Tue) by salimma (subscriber, #34460) [Link] (1 responses)

Managing with only user/group permission is probably impossible. Your mailbox is in the 'mail' group, say, but clearly the mail reader should be given additional permissions so that it can access the mailbox within your home directory.

At the same time, you want to prevent other users from using *their* mail readers (also in the 'mail' group, no?) from reading your mail.

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 22, 2009 18:38 UTC (Tue) by martinfick (subscriber, #4455) [Link]

I think that you misunderstood my suggestion that started this thread, on which I was following up...

There would be no other human users in my container in the mail group to have to shield from. Every linux user in the container would be a user owned and managed by one and only one human user, and would be used for the purposes of running applications by the same human user with different privileges.

Servers, such as the real mail server in this case, would be run by an admin in a completely separate container or on the host... likely served up via imap. They would not run in a human user container and have to share linux user-groups with it (but it could be setup that way too, it's just more complicated for the reasons you described).