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.
No, I'm talking about doing things like having a program you ask for file decriptors of resources you want to have access to. That actually works, as opposed to your half-baked renditions of what you thought I was trying to say.
Unix is almost as good as Eros because of the ability to pass file desciptors between programs through pipes and AF_UNIX sockets. It's a very underutilized ability.
I think trying to put any kind of role based security in the kernel itself is just asking for a slow, buggy kernel with lots of security holes. Something even worse than you have now.
Need a Python, C++, Unix, Linux develop
Every tried this with an NT service? They all run under this weird pseudo user called 'System'. Sure, you can change the user they run under, but good luck getting them to work with a user other than 'System'. Microsoft documents that some services will work ONLY as system. I spent about 5 hours once trying to create an 'ftp' user and run the ftp service under it. No dice.
-josh
Some Unix systems (but not yet Linux) support strongly authenticated extensions of the RPC protocol. NFS+ is built on top of RPC-DES(?) from Sun, and uses a form of PKI and DES session encryption; it is nominally in glibc 2.1.2 et seq. (iirc), but the necessary infrastructure is not yet present. This uses a distributed PKI system.
Another uses GSSAPI authentication, usually using Kerberos. This uses a centralized authentication server.
Both allow you to set up your server so that only specific users can mount the drives, and I believe they also allow you to specify that encrytion should be used on the wire.
Since both involve extensions to RPC, you can easily add strong authentication and encryption to other RPC-based applications.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
They'll pry my root account from my cold, dead passwd.
--Omar
In a modern OS; one with a virtual memory subsystem (read: basically every modern OS), all memory accessed is virtual memory. To an application, memory is memory. To the upper half of the kernel, a page of memory is a page of memory. It's only deep in the lower half does the fact that some pages are stored on a swap medium, and others are in actual physical memory.
It's called virtual because the addressing system that the OS uses for accessing pages is independant from the physical addressing of the RAM. This lack of direct memory access also makes protected memory less of a bitch to implement on non-protected mode processors.
-bugg
Eros: in the process of doing just that.
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Higher Logics: where programming meets science.
The upcoming NFSv4 standard will support strong authentication, encryption, and server-side access control. A group at CITI is working on a Linux implementation of NFSv4.
True capabilities (as found in EROS or E) are completely different, more powerful, and older than the stuff that came out of the POSIX committee; it's unfortunate to see yet another article which confuses this issue.
If you want more information on Linux and DVD see http://www.linuxvideo.org/
For a nice player go to http://xine.sourceforge.net/
Current situation: A daemon that needs to bind to a port lower than 1024 must run as root, the most powerful user account on the system -- capable of reading/writing any file, creating arbitrary devices, shuting down the machine, and lots of other manifestations of sheer power.
Under capabilities: A daemon that needs to bind to a port lower than 1024 is granted one of the network-specific capabilities. Should this daemon be compromised, the cracker can't use it to, say, read /etc/shadow as that's under a completely different capability.
As far as competent versus incompetent admins go, a good distribution should handle those details much like current distributions handle making things like "ping" setuid root. In short, it should (mostly) transparently cut down on the exposure level of various security compromises.
ACL determine who can access a particular file. It's an extention for the traditional owner/group/mode scheme.
ACL's are good for giving certain permissions for certain users. On the other hand, kernel capabilities are not for users, they are mostly for daemons that must run as root often just to do one particular thing, e.g. accept connections on a reserved port.
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
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