Posted Mar 5, 2013 10:07 UTC (Tue) by malor
In reply to: Complexity?
Parent article: Namespaces in operation, part 5: User namespaces
The old Unix permissions system actually isn't very complex, which is its central problem. The permissions are very coarse, and it's very hard to describe complex security arrangements using those very dull tools. It's primarily based on user/group/other, read/write/execute, and the various permutations of those three permissions, granted to those three broad categories. And then you've got system-wide capabilities, which either grant or deny access to users to do things that can be dangerous to the system as a whole. As they presently stand, Unix permissions are very coarsely defined, and can be very far-reaching. Granting a given permission to a program can have nasty security implications that are difficult to understand.
On the Windows side, NT-derivative systems have used ACLs for a long time, and they're much more capable. The permissions themselves are fairly fine-grained, and then you can specify to a gnat's eyebrow exactly who should and should not get them. As long as you realize that the permissions system is looking for any possible excuse to deny a permission, and only if it A) can't find any reason to reject someone, and B) finds an explicit authorization, will it finally grant a permission. Just think of the NT permissions system as a big asshole, and the whole system ends up being easily understandable, and very powerful.
But, ACLs have a very fundamental problem: permissions are granted, normally, to users, not programs, so they do almost nothing to protect programs from each other. If they're being run by the same user (say, "malor"), then they can mess each other up. If I'm running Internet Explorer, then it has any permission that I do, and if it's hijacked, it can erase or corrupt anything that I could erase or corrupt.
Namespaces are kind of an ugly hack that seem to have three basic goals:
- Preserve compability with the old Unix blunt instruments;
- Allow finer-grained permission controls;
- Assign permissions based on programs, rather than users
Once this stuff has been really integrated into the system software, running Firefox as "malor" should grant a very limited exposure to my other files, should it be hijacked. The browser process might be restricted to creating new files in a download directory only, with no other write access anywhere in the filesystem. A separate, user-facing program might have the authorization to rewrite user configuration files, like bookmarks or the settings in about:config. By separating them in this way, it will be enormously harder for a remote exploit, even in a full-featured language like Java, to escape the virtual sandbox it's in. It probably won't be impossible, but it should be much more difficult, perhaps requiring a specific exploit be written to attack your particular combination of OS and Firefox, making it non-feasible for mass exploit attempts.
This is kind of the same thing that Microsoft and Apple are trying to do with their DRM-based software stores, and highly restricted environments, but in this case, YOU hold the keys, not Microsoft or Apple.
The overall solution ends up being kind of ugly, because of the simultaneous need to maintain compatibility with a 40-year-old permissions system, and also to implement a bunch of new permission types that have never existed in Unix before, but I'll tell you this: I'll take an ugly system I can control myself over an imposed system by a corporation any day. If I want the best security, where programs are isolated from one another, but I also want to own my own hardware, Linux namespaces seem to be the way forward.
to post comments)