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.
Unix permissions just aren't fine-grained enough without having a veritable multitude of your "pseudo-files". Capabilities are simply better designed security - check out eros for a pure capabilities system (it is really, really, cool), or the Java 1.2+ security model (they call their hierarchical capabilities "permissions", but the prinicple's there). Everyone _knows_ that the (non-ACL) unix security model doesn't scale well. And ACLs are a bitch to maintain/admin. I would like a hierarchical groups kludge, personally (and that wouldn't be so hard to implement), but capabilities, particulalry hierarchical capabilties are the best solution overall, and have the advantage of being "provably secure" (within certain limits, and levels of admin competence, obviously)
Are there any non-*NIX open-source operating systems? And ... if not, why not? Is it because the UNIX design is so public and familiar?
What DVD Decoder?
The Creative Labs DXR2 is already supported (By creative labs no less), and someone is working on support for the DXR3.
There's some work on secure RPC and NFS for Linux and OpenBSD. Take a look at Dug Song's project list and the UMich NFSv4 project. Not sure how far these have progressed, the NFSv4 page at least seems somewhat out of date, but interested parties might still find them useful.
It is true that the Unix permission scheme is flat, but so is the current capabilities implementation described in the article. So this basically means that you need 1 group for each capability, which amounts to 30 extra groups for the currently implemented capabilities, which could be standardized across distributions.
As long as the overall permission scheme isn't also changed to something hierarchical (to cover fine grained device access), I think there is no point in providing a more complex capability system just for system calls. After all, you still would need to create an extra user to bundle device privileges (e.g. to allow xawtv access to all your TV and sound hardware, while restricting alevt to just the videotext device.).
Check it out, you can get a device called a "TV" and another called a "DVD Player". These incredible devices actually have specialized embedded systems that allow you to decode and view DVD content as well as standard television transmissions! The TV, while low resolution (the same resolution as the standard television signal, oddly enough), is available in giant display sizes... up to 20' diagonally on the projector-style models!
Additionally, since these amazing contraptions actually exist seperately from your computer you can switch between X and console, play Quake, and even reboot to upgrade your kernel without interrupting your movie or television show!
I'm suprised no mention is made of these great inventions on Slashdot.
I do not find in orthodox Christianity one redeeming feature.
Uhhh... no he didn't.
I do not find in orthodox Christianity one redeeming feature.
I need to use 'preview' more often.
Yeah, except I don't think a random process can su to 'nobody'.
Also 'nobody' has read access to everything that's world readable and write access to everything that's world writeable and can still create connections to the outside world. All of these things should be restricted to the 'untrusted' user I was thinking of.
Need a Python, C++, Unix, Linux develop
If that is going to be the case then we are all doomed, doomed!! If major commercial Unix vendors took security seriously there wouldn't be a need for post-install hardning scripts like Bastille. If "Out of the Box Experience" wasn't perceived to be so important things like the Ramen worm would never happen, the machine would be tight by default.
-- Remember: Wherever you go, there you are!
That's not entirely true, if you didn't intend to run FTP or NFS services, they shouldn't be enabled. Random Joe Cracker can't break into a service that isn't running. Joe Newbie isn't going to know that running any version of wu-ftpd is probably a bad idea let alone keep up with the security fixes.
There isn't one single point of failure but a common trait to many of these boxes is that they are running an unmodified, out-of-the-box install of RedHat. Giving Joe Newbie what is in effect a loaded weapon, instead of a safe unloaded weapon, is bad netizenship. Having your cracked box used to ping flood my network is as much your fault as the crackers, and is detrimental to me in any case.
-- Remember: Wherever you go, there you are!
That may be, but we've surpassed the security of their implementations long ago. (Security model on paper != security model actually in NT).
Hopefully we can get around the management problem of ACLs some time soon. Every OS where I have seen them implemented they were always too complicated to actually use. This lead to overly permissive ACLs being required because it would have been a mangement nightmare to do it the right way.
-- Remember: Wherever you go, there you are!
Ever think that this article had a totally different purpose than the one you think it should have? This was not supposed to be "How to secure Linux 2.4", and it wasn't. Big whoop.
Instead, it's an informative piece on the security directions the kernel has taken. I'm really upset. Honest.
No one is advocating running malicious programs with root privileges. The point of capabilities is to reduce the possible damage by a buggy program with root privilages.
For example, if BIND only had the privileges to access the DNS ports, it couldn't do anything nasty even IF a buffer overflow was uncovered.
It's not a move toward desktop, though. Linux 2.4 has some very advanced routing features that before BSD users have had over Linux. Some BSD users said Linux was a fine desktop but didn't cut it as a server as a result. 2.4 is making Linux a more viable desktop, server, dancing monkey -- whatever. :)
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
Couldn't whatever program launches the application define the capability set of an app before the app even gets the opportunity to reliquish it's capabilities. I mean, if init runs a program that reads configuration files that define what programs to spawn and what capability set they get, it can run as root and run apps as root, but if the program sets it's inheritable capabilities set to reflect the configured capabilities... then the application being spawned wont need to be trusted to relinquish capabilities - it wont have them in the first place.
Uhm....they kinda are. That's what the whole article was just about: New Kernel Security Features in 2.4.
Shouldn't capabilities be in the filesystem so that it can be managed like permissions? Or at least in crt1.o so it can be managed by some standard utility and isn't affected by most library bugs? Otherwise, you still have software being given more privilege than it needs.
It's actually pretty easy to bolt on this security to UNIX. It's a tribute to the flexibility of the system that it can be so easily extended in this way. So the process is evolutionary rather than revolutionary; very little in this business is actually revolutionary and chances are if you build up a system from scratch it'll end up either looking a lot like unix or being total crap. Or it might be great and no one use it anyway.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
you saw NFSv3, unless you saw something extra-special :-).
v3 was new in 2.4 and still has a special config option.
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
Whiskey, Tango, Foxtrot? I run services under trusted accounts all the time, and restrict the hell out of those accounts; what machines they can log into, what they can do whilst logged in, etc etc.
Vintage computer games and RPG books available. Email me if you're interested.
The problems you mention will exist when capability support is added to the filesystem, however.
Role based security... can easily be implemented at the application level using Unix's current security model. This is a stupid feature to add.
This is so true. In fact, all security should be taken care of at the application level anyhow. All applications should just be written to know what you're supposed to be able to do, and then prevent you from doing things you're not supposed to do.
For example, you shouldn't be able to rename the "C:\Windows" directory on your computer. All programs that allow you to rename files -- like Windows Explorer, or command.com, or Microsoft Word, should have special logic built into them to check if you're modifying the "C:\Windows" directory, and they should pop up a little paperclip to ask if you really want to do that.
Is that the kind of "application level" security you're talking about?
Slashdot is jumping the shark. I'm just driving the boat.
That isn't a problem. Naturally, Security only works when you can trust the user not to do anything stupid to circumvent it. Users should only be running programs that respect the level of security the user desires.
In particular, users shouldn't be compiling their own programs -- users can not be trusted to write code that respects the level of security they desire. Security is very complicated, and it is impossible for any mere computer user to understand all the nuances of writing a program that respects security. Similarly, the user should never attempt to use free programs, since without money exchanging hands, you have guarantee that the program respects security. Instead, users should only be purchasing pre-compiled programs from a reputable vendor, with the all the assurance that vendor gives that the application comes pre-configured to respect the level of security that the user desires.
Obviously, e-mail readers should continue be able to conveniently run programs sent to the user, but it's the users responsibility to make sure that those programs came from a reputable vendor, and aren't just some free program that may not respect the level of security the user desires.
I realize that holes will continue to be discovered in programs written by even the best, most respected vendors, and some of those holes will allow crackers to run arbitrary code to compromise a system. But again, it is the users responsibility to make sure that only representatives of trusted companies will be able to connect to the users machine, since only those representatives may be trusted to respect the correct level of security the user desirers. The importance of this can not be over-emphasized -- if a user allows anyone in the world to connect to a machine, the user has no way to ensure that only programs pre-configured to respect level of security the user desires will be run on the machine.
It is extremely important that all programs come pre-configured to respect the level of security the user desires. Users can not be trusted to manually configure all of the programs that they run, since each of those programs would obviously need a different set of dialog boxes and configuration files to manually configure their security levels. Users often get inexplicably bored viewing the hundreds of interesting and creative ways vendors choose to represent the unique and disparate security policies that vendors choose to implement. Only by using programs pre-configuring to the correct security level can the user be assured that he is recieving the correct level of security, so that the user can rest easily, knowing his computer is secure.
Slashdot is jumping the shark. I'm just driving the boat.
For the tuner, check in /usr/src/linux/Documentation/video4linux/bttv/CARD LIST
for your tuner card.
If it's in there, it's supported.
--
Soma: because a gramme is better than a damn.
Okay... Slightly off topic,
But what I'd like to see is some sort of secure way to mount a network file system.
(keep in mind that I'm a linux newbie)
My understanding of NFS is that it relies on trust. I trust my account on my school's server, but how is any computer on a school network supposed to trust me?
If I read about these new features I am remembered on the time I found out about Linux and the different group permissions. I was astonished and tried to set up the highly securest system possible.
Then came the time I started to more use application (then setting up my OS) and the problem that I had to decide to use the unclean written application in a unsecure manner (as root) or not to have the desired feature.
What I need is a system like Janus with a management frontend, which does not require me to spent 4 hours of trying, which are the least privileges possible. Or maybe a standard all programmers keep, so that I know what rights my application needs before downloading it.
---- "What would you try, if you knew you would not fail ?" Unknown
This only confirms my earlier feeling, that the 2.4 kernel is the beginning of linux's migration from the server farm to the desktop. While I was reluctant to use Linux before 2.4, because of incessant problems with my sound card(isapnp.conf anyone?), everything seems to work marvelously with this new kernel. Now if I could just get support for my TV tuner and DVD decoder,I would never need to book into Windows.
Sickman's spinfusor catches Anonymous Coward by surprise.
Obviously it is not that technical and does not give that much detail, but most people do not know the innards of the kernel as well as you. One of our goals is to increase awareness, which is exactly what this article was aimed to do, and does.
Just my $.02. Go blast somebody else, please.
Cheers,
Ryan
heh, you're right. it was actually a cut-and-paste error, believe it or not. To avoid further confusion, I've fixed it.
Not that I'm an expert on system security by any means, but the inclusion of more complex process permissions may have the exact opposite effect than intended. For each competent sysadmin, there is somewhere one that is less competent... and it seems that splitting powerful permissions away from the idea of a 'root' user may make system weaknesses harder to identify and close down.
Couple this with the buzzword effect that this idea would have.. (Our new Linux is more secure than that old Linux!)
Wait for kiddies to attack someone elses system before you trust how secure this kind of setup is.
Maybe it's just me, but I don't like the idea of root not being able to change some things on the system until after a reboot. The entire idea of the root account is that you can change *everything* that can be changed. Crippling it doesn't sound logical to me.
Giving programs that don't need rootperms (/bin/ping being an excellent example) only the perms it needs seems great to me though.
----
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
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.
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