Complexity?
Complexity?
Posted Feb 28, 2013 10:31 UTC (Thu) by renox (guest, #23785)Parent article: Namespaces in operation, part 5: User namespaces
1) I've not invested enough effort understand Unix management
2) the problem is itself very complex
3) this is an historical baggage/legacy and other approaches (Plan9? Windows?) could provide the same type of services but in a simpler way..
Thoughts?
Posted Feb 28, 2013 17:26 UTC (Thu)
by hummassa (subscriber, #307)
[Link]
Windows-like ACLs (again IMHO) are simpler to apply but cause more esoteric and difficult-to-debug problems.
Posted Mar 5, 2013 10:07 UTC (Tue)
by malor (guest, #2973)
[Link] (2 responses)
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:
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.
Posted Mar 5, 2013 10:29 UTC (Tue)
by etienne (guest, #25256)
[Link]
Maybe that is not complex enough, and permissions should be granted to what the program is doing:
Ever seen a security system blocking half of the upgrade of a package?
Posted Apr 14, 2015 4:51 UTC (Tue)
by bandrami (guest, #94229)
[Link]
And this is not *necessarily* a good thing. Taking Unix permissions and then adding capabilities and ACLs triples (more than triples, really) the logic required to statically verify a configuration. I guess I sort of appreciate the idea that a library that isn't there can't be misconfigured -- I don't run ACLs or CAP_*s or namespaces on my production Linux servers for that reason even though that takes rebuilding the kernel. It's the same argument I have with mandatory access control systems: knobs I can twist are knobs that I can twist the wrong way. I want my security system to be so brain-dead that I can verify it at 3am in a loud server room with a client calling me every 30 seconds.
Complexity?
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. Complexity?
Complexity?
- if the program is updating itself (when no package manager) it should have rights to overwrite its own binaries
- if the program is configuring itself (when user changes something) it should have rights to change its configuration files
- if the program is being only "used", it shall do none of the above.
I did not say I would like to manage such a system...
Complexity?