New Kernel Security Features In 2.4 Explained 98
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.
Re:Have you ever wondered... (Score:1)
--
OlympicSponsor - banned
NPR Real Audio: Linux and the OSS Revolution (Score:1)
Listen to Author Glyn Moody. His new book is called Rebel Code: Linux and the Open Source Revolution. It charts the movement begun by computer programmers who believe software should be given away for free. Moody is a London-based writer whose work has appeared in Wired, The Economist, and The Financial Times
Re:It's different things! (Score:1)
Linux's capabilites are NOT the same as ACLs (Score:1)
But it not ACLs.
Re:Open-Source non-NIX OSs? (Score:1)
penny wise, dollar foolish? (Score:1)
[root@magneto /root]# head -c 6 /dev/urandom | mmencode
Re:Linux is well on the way (Score:1)
Yet another lame article on linux security. (Score:1)
I am sick of seeing 100 different netfilter documents explaining how to setup NAT. How about taking some time and documenting something that isn't documented so well. Or better yet, actually getting a clue when it comes to security before you go around writing security articles.
Reliability & Ads (Score:1)
lcap is screwed, or you system (Score:1)
Re:This is silly, what would be good is.. (Score:1)
Yes, but chroot is a pain to code because oftentimes you want to provide _some_ access to local files. Also, it still doesn't solve the socket problem.
Re:This is silly, what would be good is.. (Score:1)
Yeah, except I don't think a random process can su to 'nobody'.
Crypto (and its absence) (Score:1)
I can't believe no one has mentioned this yet.
(Granted, it appears no less than three separate fixes for loop have happened in the ac kernels in the past day, but ...)
There have been no (that's right, no) entries under /pub/linux/kernel/crypto/v2.4/ since patch-int-2.4.0.3.bz2. Kernel 2.4.0,
and we're working on what now, kernel 2.4.2-ac9? (Perhaps later by the
time you read this.)
To neglect to mention this, in an article of this nature, seems inappropriate. Kernel crypto support needs work presently, and unless fact is mentioned, appropriate volunteers may not be aware their expertise is needed.
The article mentions the importance of kernel crypto support. Those who can help get it working again are encouraged (here) to contribute, even if the article implied all was rosy in that regard.
(Is it off-topic to mention that Debian's support for kernel crypto went away on November 23, 2000 [debian.org] when the util-linux maintainer moved from 2.10-p to 2.10q. It appears Debian [debian.org] could use some help with basic kernel crypto support as well. 99 days is bordering on criminal.)
"Coders wanted; apply ..."
Re:Creeping Complexity.. (Score:1)
Re:Linux is well on the way (Score:1)
Re:Neat idea, but ... (Score:1)
It's "if
It's "when
Re:Creeping Complexity.. (Score:1)
Actually, it has to be launched as root, so it can bind() to the privileged port (or do whatever it's required to do as root), but then it can setgid() and setuid() itself to act as a less powerful user/group (i.e. nobody) with limited access.
Re:This is silly, what would be good is.. (Score:1)
Oh, like the "nobody" user?
Re:Linux is well on the way (Score:1)
and this is supposed to help watching DVD on the TV how?
Here come the OS-bigots... (Score:1)
Also, if you were so secure in your choice of operating systems or your own abilities, you would not feel the need to criticize others without merit. Im willing to bet you have contributed nothing at all to any of the operating systems you just mentioned. Thanks.
Just like Pitbull (Score:1)
Re:Creeping Complexity.. (Score:1)
You are missing the point. The idea is that if a process is compromised, the cracker does not own the entire system since the superuser account is not tied to that process.
Re:Yet another lame article on linux security. (Score:1)
Re:Linux is well on the way (Score:1)
Re:NFSv4 is secure (Score:1)
Re:It's different things! (Score:1)
There is a mention in the article that there's a possibility of adding capability tags as a FS attribute, so you'll be able to add necessary capabilities to an otherwise unprivileged application rather than the rather backward approach of running the app as root and counting on it to give up needed privileges. Unfortunately that support does not yet exist, so it's still theoretical. If you're really interested in a more sophisticated security system, you might want to look at the NSA Security Enhanced Linux.
Re:Linux's capabilites are NOT the same as ACLs (Score:1)
ACLs don't have to be limited to just filesystem permissions. Admittedly that has been the only place I've heard them talked about wrt to Linux.
Re:LINUX, the kernal (Score:1)
AFAIK the amount of swap reported to be used with Linux 2.4 isn't the real amount at all.
It's a bit like with top reporting X to use many hundred megabytes of memory.
Re:Linux is dying (Score:1)
--
Re:This is silly, what would be good is.. (Score:1)
Re:2.4 security (Score:1)
That looks like exactly what I've been looking for
I hope you getting modded up for this one!
Re:Linux is well on the way (Score:1)
OK, by just supporting one chip they cover the lions share, but there are other chips out there which aren't supported.
Of course, given that the whole thing is non-commercial we shouldn't complain, if anything we should credit them for the stirling effort that they've already put in to get the support ar broad as it it. (I must look again and see if my ATI is now supported..., if not, it's bloody ATI's fault, grrr!)
FP.
--
Re:A KISS alternative to capabilities (Score:1)
How about modifying the bind code itself, in the system library, to authenticate a request to bind a port. Then a normal, non-special binary could call the routine, and ask for a priviliged port. The library, like PAM, would evaluate the request and decide to grant or deny.
And for those that ask about trojans, I don't think it would take much to have some other level of verification that the binary image requesting is the one you want running. Since this is calling from the kernel, it would have access to the exact file location, and image in memory. For example, it could compare a MD5 hash of the in memory binary with some secured list of allowed (port,program,hash) information.
Is this possible, or am I off my rocker??
Re:Linux is well on the way (Score:1)
But you already HAVE support for the TV tuner. Look at your kernel configuration. In fact, Mandrake 8.0 beta 1 detected and installed support for my TV tuner automagically.
As for the DVD decoder, most likely the manufacturer is not being very helpful. So use software mode:) It works well enough if you have a midrange or above CPU.
"just connect this to..."
BZZT.
Re:New Security Features (Score:1)
Too in-depth for script kiddies, thus requiring script kiddies? I dont get it.
Re:Linux is well on the way (Score:1)
Re:It's different things! (Score:1)
Create an acount, assign required capabilities ( on sys admin level - not code) to that acount and have new app run under it.
Re:Neat idea, but ... (Score:1)
Re:Here come the OS-bigots... (Score:1)
Thanks,
Andrew Pinski
Re:but... but... root = god! (Score:1)
That reminds me of the age-old philosophical problem: Can Root create a file such that even He can't delete it? :)
As far as I understand it, that "until after a reboot" thing applies to individual processes - that once a particular process has relinquished a capability, it can never regain it. That doesn't mean that all root processes have lost that capability though; otherwise, the first time you ran ping, root would lose all privileges except to open a network port.
Of course, after a reboot, there are no processes left from before, so everything is starting fresh anyway. As far as I can tell, the whole phrase was just used to emphasise the fact that the process can't get the capability back.
Re:Open-Source non-NIX OSs? Plan 9! (Score:1)
Re:Creeping Complexity.. (Score:1)
This raises a question with me: on my Debian system, apache binds to port 80 and runs as user www-data with no root privileges, and I can ping with impunity as a normal user without ping being suid.
In the light of your statements, how would that be possible?
MartRe:Creeping Complexity.. (Score:1)
Oops, sorry about that. I had never noticed ping among the programs that were setuid, and I was posting from work yesterday, so I couldn't check it out. A quick ls /bin/ping -l shows you're right. Thanks!
MartRe:Too bad they're not integrating SE Linux (Score:1)
I have used systems with ACL type structures and say that I like it. Fine grained privilege control seems to also catch a lot of software design issues.
If we could get SE Linux or anything else with similar features it would be really good in the server world. I can live with just root on a desktop but it doesn't really help on a server.
Deluged in ads (Score:1)
Only problem is, we're expected to work with NTFS. So brilliantly designed the NTFS that anyone allowed to sign on with any level of access can damage the entire system.
Perhaps, one day, M$ will just go on some form of Unix/Linux like Apple.
*prays*
Fine Print of Linux v. Windows (Score:1)
Re:Here come the OS-bigots... (Score:1)
How does this relate to the Sandbox concept ? (Score:1)
Re:Linux is dying (Score:1)
Slackware posts on Usenet are about half of the volume of GNU/Linux posts. Therefore there are about 7000 users of Slackware.
Perhaps Slackware users are more skilled. It is one of the oldest distro's. Perhaps, instead, they use the forums at slackware's sight.
How about this: your post represents %100 of the posts I've replied to today, therefor 100% of the posts on slashdot must be yours, including this one, and therefor I am you.
© 2001 Anusmouth_Cowherd.
Re:Open-Source non-NIX OSs? (Score:1)
EROS Architect
Re:A KISS alternative to capabilities (Score:2)
Open-Source non-NIX OSs? (Score:2)
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?
Re:Linux is well on the way (Score:2)
The Creative Labs DXR2 is already supported (By creative labs no less), and someone is working on support for the DXR3.
Re:NFS+ and RPC-GSSAPI (Score:2)
Re:A KISS alternative to capabilities (Score:2)
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.).
Re:Linux is well on the way (Score:2)
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.
Re:Linux "capabilities" are not capabilities (Score:2)
Uhhh... no he didn't [rif.org].
I do not find in orthodox Christianity one redeeming feature.
Re:This is silly, what would be good is.. (Score:2)
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.
Re:Creeping Complexity.. (Score:2)
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 [sourceforge.net]. 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.
Re:Creeping Complexity.. (Score:2)
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.
Re:It's different things! (Score:2)
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.
Re:Yet another lame article on linux security. (Score:2)
Instead, it's an informative piece on the security directions the kernel has taken. I'm really upset. Honest.
Re:Neat idea, but ... (Score:2)
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.
Re:Linux is well on the way (Score:2)
Re:Neat idea, but ... (Score:2)
Re:No filesystem support? (Score:2)
No filesystem support? (Score:2)
Been There Done That (Score:2)
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.
Re:NFSv4 is secure (Score:2)
v3 was new in 2.4 and still has a special config option.
Re:It's different things! (Score:2)
Re:Neat idea, but ... (Score:2)
The problems you mention will exist when capability support is added to the filesystem, however.
Re:This is silly, what would be good is.. (Score:2)
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?
Re:This is silly, what would be good is.. (Score:2)
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.
Re:Linux is well on the way (Score:2)
for your tuner card.
If it's in there, it's supported.
--
2.4 security (Score:2)
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?
New Security features - How to use ? (Score:2)
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 [berkeley.edu] 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
Linux is well on the way (Score:2)
Re:Yet another lame article on linux security. (Score:2)
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
Re:penny wise, dollar foolish? (Score:2)
Re:2.4 security (Score:2)
--
Creeping Complexity.. (Score:2)
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.
but... but... root = god! (Score:2)
Giving programs that don't need rootperms (/bin/ping being an excellent example) only the perms it needs seems great to me though.
----
Re:This is silly, what would be good is.. (Score:3)
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.
Re:It's different things! (Score:3)
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
NFS+ and RPC-GSSAPI (Score:3)
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.
Eventually the demise of WHAT? (Score:3)
They'll pry my root account from my cold, dead passwd.
--Omar
Re:LINUX, the kernal (Score:3)
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.
Re:Open-Source non-NIX OSs? (Score:3)
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
NFSv4 is secure (Score:3)
Linux "capabilities" are not capabilities (Score:3)
Re:Linux is well on the way (Score:3)
If you want more information on Linux and DVD see http://www.linuxvideo.org/ [linuxvideo.org]
For a nice player go to http://xine.sourceforge.net/ [sourceforge.net]
Re:Creeping Complexity.. (Score:3)
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.
It's different things! (Score:3)
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.
Too bad they're not integrating SE Linux (Score:4)
Integrating Security-Enhanced Linux [nsa.gov], 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.
This is silly, what would be good is.. (Score:4)
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.
Re:It's different things! (Score:4)
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...
A KISS alternative to capabilities (Score:5)
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.
Neat idea, but ... (Score:5)
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