2 ms·
You might be interested in the SubUser[1] project, which does exactly this application siloing for Linux. [1] http://subuser.org http://subuser.org
by chris_st 11y ago
You might be interested in the SubUser[1] project, which does exactly this application siloing for Linux.
[1] http://subuser.org http://subuser.org
- gizmo 11y agoI like what they're doing, but applications have to be written from the ground up knowing that they live in a sandbox, so they can ask for the appropriate permissions in the appropriate places explaining why the extra permissions are needed. Otherwise the user experience is going to be pretty bad. Security doesn't work as an add-on.
- heavenlyhash 11y agoNah, there's a lot of room for easy adoption. For example, for a text editor like vim, here's a completely reasonable lockdown: - see none of my filesystem... except `cwd` I launched you in - you get a homedir that's persistent for this application - (incidentally, whatever libraries you need are there; network namespaces dropped, clean env vars, clean pid space, etc etc etc.) The things on this list involve essentially Nothing Special and no changes to the program, and at the same time manages to radically reduce the surface area a malicious program can mess with on my computer. Even if, say, a malicious version of vim somehow made it in $distro's package tree and was signed: this still makes me... well, pretty safe. The scope of damage is confined to... exactly what I just laid out on those two bullet points. And subuser's configuration does an excellent job of exposing exactly those kinds of behaviors to you with very minimum amounts of fuss. (A json file with `{"access-working-directory": true, "stateful-home": true}` is all you have to say to subuser to set up an application to get... well, hey, if these aren't self-documenting names, I don't know what is.)