Slashdot Mirror
New Kernel Security Features In 2.4 Explained
bewmIES writes: "Dave Wreski of linuxsecurity.com and author of the recent netfilter article here on slashdot has written an excellent introduction to some of the latest security enhancements to the 2.4 kernel entitled Linux 2.4: Next Generation Kernel Security. He speaks about the future of crypto integration, new character and block devices, and has a very well-written summary of capabilities."
Perhaps this will answer at least some people's needs for ACL capabilities in Linux.
Integrating Security-Enhanced Linux, the set of kernel and tool extensions to Linux (it is an NSA implementation of the University of Utah Flask secure system architecture) would be a much better Linux enhancement in the long run.
The architecture provides a single mechanism for enforcing security and seperates it from the security policy which can be modified to suit different needs (e.g., you could use it to implement ACLs, RBAC, Chinese Wall, MLS, or other types of security policies).
I seriously doubt Linus would consider integration of the extensions anytime soon because they touch so much of the code base. Plus, it's still on the researchy side of things (you *have* to use RedHat 6.1 or 7.0 to make it work at this point, for example). But once you get it working, it's amazing what kind of potential you can see in the system for enhancing security.
But the mechanism it provides makes it possible to restrict access on a very fine-grained level in a fashion similar to what this article talks about. And it could make the security features of Linux lightyears ahead of what NT provides. It would also be the first free software operating system to provide mandatory access control mechanisms.
BTW, SE Linux is a good example of why the claim that "open source" is never innovative is completely untrue; how proprietary code is and how innovative it is are orthogonal issues.
Role based security is a panacea for those who think they somehow need it at the OS level. It can easily be implemented at the application level using Unix's current security model. This is a stupid feature to add.
Now, what would be a good feature is this:
An 'untrusted' user that any process can switch to that has very limited access to anything on your system. This would provide a way to semi-safely run executable content without worrying about whether or not it will be a virus or not.
Need a Python, C++, Unix, Linux develop
ACLs are used to grant/restrict access to a particular resource - not just files. They are most often used for filesystem priveleges, but the model is easily extended to anything which can be viewed as an atomic resource. TCP ports, hardware devices, even more abstract entities like "network paramters" can be viewed in this way, and have ACLs attached to them
In this way, you could allow certain users read-only access to the network paramters, and others read/write access.
Linux, of course, would allow you to do all this within the filesystem, if we had ACLs. The /dev and /proc hierarchies are designed to map these sorts of resources onto the filesystem so that you can use common system calls to manage them.
<rant>
The biggest advantage of ACLs for security is that they are managed outside of the resources they govern. A resource does not get to tell the OS who can access it, rather, the access control is left up to the SA. The problem with these kernel capabilities, as described in the article, is that it is left up to the application to determine which priveleges it will have, and there seems to be no way for an administrator to deny the application access.
This whole model seems quite backward to me, and I don't think it gets around the problem of having to run untrusted code (ie, someone else's) as root, in order to do something simple like ping.
</rant>
I think I'll go look now to see who's actively working on ACLs for Linux, to see if there's anything I can do to help...
Living better through chemicals
To extend this scheme to privileged system calls, simply make up some pseudo file (e.g.
To implement capabilities, just make a new group for each pseudo-file (perm. 660), create a user for the privileged executable and make him a member of the necessary capability groups.
To stick with the xntpd example from the article:
-rwsr-x--- ntp admin
-rw-rw---- root settime
-rw-rw---- root deamon
while user "ntp" is member of the "settime" and "deamon". Any member of the "admin" group can then start xntpd, which then runs under SUID "ntp" and has only the necessary privileges to serve its supposed purpose.
Such an approach would have a number of advantages:
I'm sure that people more familiar with security systems will come up with an equally long list of drawbacks (lower flexibility in changing permissions dynamically or dropping privileges after startup comes to mind), I think, however, that the above scheme could solve a good deal of the existing problems without introducing too much new complexity.
The "capabilities" are a neat idea, but it is the honor system. Applications need to be written to relinquish the privs they don't need. Legacy apps will *still* have God privs...
System admins take note. No longer will you simply need to "find / -user root -perm -4000" to locate privledged programs. Introduces a new mechanism for hax0rz to hide things