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

Posted Sep 18, 2009 7:49 UTC (Fri) by mjthayer (guest, #39183)
In reply to: Walsh: Cool things with SELinux... Introducing sandbox -X by drag
Parent article: Walsh: Cool things with SELinux... Introducing sandbox -X

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".

to post comments

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).