Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Software

New Kernel Security Features In 2.4 Explained 98

Posted by timothy from the hey-you-can't-do-that!-bang-bang dept.
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.
This discussion has been archived. No new comments can be posted.

New Kernel Security Features In 2.4 Explained More

New Kernel Security Features In 2.4 Explained

Comments Filter:

  • Re:Have you ever wondered... (Score:1)

    by Anonymous Coward
    AC has the highest karma of any 'user'. It was around 3000, last time I hacked /. using social engineering and CowboyNeal's backdoor.

    --
    OlympicSponsor - banned :(
  • Here's the Real Audio link that Slashdot didn't want to you see: Linux and the Open Source Revolution [npr.org].

    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)

    by Anonymous Coward
    for those of you who need a translation of the article, it's this: linux just now caught up with the NT 3.51 security model, and they're talking about what a great idea it would be to copy the NT 4.0 security model.
  • Linux's capabilities address the "Root == god" problem. You can give a process just the capability to open ports below 1024, but nothing else. Or just the ability to set themselves at realtime priority. Its great, and required for good multimedia apps, unless you want to run them all as root.

    But it not ACLs.

  • Re:Open-Source non-NIX OSs? (Score:1)

    by Anonymous Coward
    as a professor of mine said in an Operating Systems class, "Unix got a surprising amount of things right."

  • penny wise, dollar foolish? (Score:1)

    by Anonymous Coward
    Why does this guy need finer-grained root priviledges if he's gonna run the most insignificant commands as root? I'm refering to:

    [root@magneto /root]# head -c 6 /dev/urandom | mmencode

  • The GATOS programs (xatitv et al) are no longer in active development. The current focus is on an Xfree 4.02 Xv module (hopefully to be included in 4.10). Overlay / colorspace conversion, and view-only TV input currently works. I'm working on CC and capture, but intermittently.
  • Come on people. Please quit writing security articles to get your sites hits. If you are going to take time to write an article atleast write a good one. This latest example gives a user new to security almost no useable information to improve security on their box. The Linux community needs to get a clue when it comes to security. They also need to quit writing bad documentation on the subject.

    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.

  • Even better for those ads (I just read one in Business Week), having talked about how Window 2000 is "designed for 5 9's" they talk about companies running W2K. Note that they don't say these companies are GETTING 5 9's from W2K. Nice miss-direction there.
  • according to this [securityfocus.com] bugtraq post, lcap is not that secure, you can easily reset capabilities if you have CAP_SYS_RAWIO enabled, which gives you access to /dev/kmem. if you disable it, you won't be able to run X and a bunch of other apps. but on servers this shouldn't be a problem...

  • 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.

  • Yeah, except I don't think a random process can su to 'nobody'.

  • 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 ..."

  • Apache starts as root and then drops it's privs (su's to www-data), so apache does infact run as root initially. As for ping, that really doesn't seem possible. ping must be setuid root in order to function, same with traceroute.
  • The ATI tuners are supported by the gatos project. Just search freshmeat for it. Last time I tried it (sometime over a year ago), it was usable, but not perfect.

  • Murphy's law rules.
    It's "if ... uncovered" if it is harmless.
    It's "when ... uncovered" if it can do damage.
  • A daemon that needs to bind to a port lower than 1024 must run as root

    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.

  • 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.

    Oh, like the "nobody" user? ;)
  • >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.

    and this is supposed to help watching DVD on the TV how?
  • Theres the OS-bigot remark we are so used to seeing. As usual, it includes no quantitative information or relevance. Heaven forbid a positive or informative article about Linux security appears on a primarily Linux site.

    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.
  • Except free! After the recent demonstration at Openhack III, this [argus-systems.com] looks like a really Good Thing. Now the kernel can do effectively the same thing :)
  • splitting powerful permissions away from the idea of a 'root' user may make system weaknesses harder to identify and close down.

    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.

  • Valid point. However *completely non-responsive*. How about some suggestions for Linux?
  • I think the original poster meant something more along the lines of 'an expansion to the desktop' rather than a move.
  • Correct me if I'm wrong, but when I compiled Linux 2.4 I saw this option (NFSv4). So is the security aspect built-in now, or just protocol complience? Or is security a part of said complience?

  • 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.

  • You are right about capabilities, but ACLs are just finer grained permission lists. There is nothing stopping the capabilities implementation using ACLs to configure those rights.

    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.
  • The amount of swap used really isn't a good way to measure system performace.
    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.
  • Dude... Sorry to break it to you, but three inches isn't enormous.

    --
  • How do you deal with users compiling their own programs?
  • Dude - You Rock!
    That looks like exactly what I've been looking for
    I hope you getting modded up for this one!
  • If I'm not mistaken the 'bt' in bttv stands for "Brooktree", which are the manufacturer of one of the most common chips used in motion vieo applications.
    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.
    --
  • Rather than play games with identification, switching users, and arbitrary collections of capabilities/permissions, what of a bind-proxy?

    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??

  • Now if I could just get support for my TV tuner and DVD decoder,I would never need to book into Windows.

    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.

  • "Too in-depth for script-kiddies to crack, thus requiring a real hacker to create their scripts for them."

    Too in-depth for script kiddies, thus requiring script kiddies? I dont get it.
  • Re: The DVD decoder, It's a Sigma-Pro RealMagic Hollywood Plus, and yes, the manufacturer has actually been extremely unhelpful. They won't even release the chipset info so those good citizens at vid4linux can support it for them. They released a new card with linux support though, so i guess they want to force me to buy that. Re: The TV Tuner Its a Voodoo3 3500+ AGP video card + TV tuner, the video card is supported but I was never able to find support for the tuner or an app. to use it. Haven't tried Mandrake yet though, maybe that'll help.
  • How about using NT style security...
    Create an acount, assign required capabilities ( on sys admin level - not code) to that acount and have new app run under it.

  • Well, it is still progress as compared to current situation.
  • Is that why there is no linux section!!
    Thanks,
    Andrew Pinski

  • 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.

  • Was that not the idea behind Plan 9?

  • 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?

    Mart

  • 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!

    Mart
  • I agree. For various reasons, I had to leave SE Linux almost as soon as I tried it - I needed a newer kernel and 2.4.0 was out.

    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.

  • Personally, I just flat-out don't care much for the Windows operating system; it's designed for PHB's and Alpha-Geek-Wish-I-Were's. But, I will say this or the NT 5 series and up, they are, for the first time in M$ history, actually stable enough for server use.
    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*
  • Yeah, yeah, yeah, Linux is secure, and will continue to become more so. I'm just popping in to show peices of an advertisement for the "Windows 2000 Server Family" Yeah, whatever, you'll love this. "For a server operating system, the five nines are a measure of reliability that translates into just over five minutes of server downtime per year.* *This level of availability is dependent on many factors outside of the operating system, including other hardware and software technologies, mission-critical operational processes and professional services." What I am reading, expecially with the "mission-critical operational processes" is that when M$ tests this thing, they just install it and don't actually DO anything with the server. I'm willing to bet they don't even use software-dependant hardware, just to make sure they make that "99.999%" Hmm, upside down, that's ,,÷66666,, Funny how the truth sneakes out in the most peculiar way.
  • Well Andrew. As long as I've been reading this site (which has been quite while this user account is new) this site has been a pro Linux site. If you don't like that fact why do you bother coming here?
  • Can somebody explain the difference of this to the Sandbox concept of Java or Janus ? (http://www.cs.berkeley.edu/~daw/janus/) Wouldn't it be better to have a good syscall-interception interface like Solaris ? Then there could be competing implementations for the "SecurityManager" (Java Terminology)
  • You have no clue.
    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.
  • For the record, the anonymous poster was not me (though I agree with him). I'm too busy building a securable OS to give a hoot about karma.
    • Jonathan S. Shapiro

    • EROS Architect

  • Re:A KISS alternative to capabilities (Score:2)

    by Anonymous Coward
    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 [eros-os.org] 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)

  • Open-Source non-NIX OSs? (Score:2)

    by Anonymous Coward
    Instead of bolting this stuff onto the side of a legacy OS design (*NIX) why not write an OS from the ground up with "advanced" security features like this in mind?

    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 [monkey.org] project list and the UMich NFSv4 [umich.edu] 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 [rif.org].

    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.

  • 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.

    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.

  • 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.

  • 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.

  • 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. :)
  • 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 called VMS. You can't turn around without a system priv (SYSPRIV_TURN_AROUND.)

    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.

  • you saw NFSv3, unless you saw something extra-special :-).

    v3 was new in 2.4 and still has a special config option.
  • 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.
  • Actually, capabilities aren't implemented in the filesystem yet, so you have to have root privilege in the first place to fiddle with capabilities, and in that case you are removing privilege, not elevating it. Root has to run sucap or capexec and specify the privileges he wants. Thus, the need for suid programs hasn't gone away, just the need for most daemons to run with full root permission when started by root, like in system boot scripts.

    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?
  • 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.
  • 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.

    --
  • 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 [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
  • 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.
  • Well perhaps it's because not everybody knows that much about linux security? "The Linux community needs to get a clue when it comes to security." I could not have said it better myself, which is why we publish articles like this. This is intended to be an introduction on the topic for people who do not even know what a capability is.

    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.
  • Your best bet, if you're using NFS to link to a remote system, is to set up a VPN solution like FreeS/WAN [freeswan.org].

    --

  • 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!) ..and I forsee too many people jumping on board without really understanding the mechanics of how this changes their jobs. Paranoia is a virtue, don't let your guard be lulled because your system is only vulnerable to certain exploits some of the time.

    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.

  • Re:It's different things! (Score:3)

    by joshv ( 13017 ) on Thursday March 01, 2001 @04:30PM (#391021)
    How about using NT style security... Create an acount, assign required capabilities ( on sys admin level - not code) to that acount and have new app run under it.

    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)

    by coyote-san ( 38515 ) on Thursday March 01, 2001 @03:46PM (#391022)
    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.

  • I may be a nostalgic traditionalist, or I might just be a crazy fool, but I would just be depressed if I couldn't have my root account. It would suck! I WANT my special prompt. I WANT to be able to type "su -" and gain magical superpowers.

    They'll pry my root account from my cold, dead passwd.

    --Omar

  • Re:LINUX, the kernal (Score:3)

    by bugg ( 65930 ) on Thursday March 01, 2001 @04:00PM (#391024) Homepage
    This needs to be said. You aren't even the only person in this thread who's misused the term..

    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)

    by naasking ( 94116 ) <naasking AT gmail DOT com> on Thursday March 01, 2001 @03:01PM (#391025) Homepage
    Eros [eros-os.org]: in the process of doing just that.

    -----
    "People who bite the hand that feeds them usually lick the boot that kicks them"

  • NFSv4 is secure (Score:3)

    by Wesley Felter ( 138342 ) <wesley@felter.org> on Thursday March 01, 2001 @04:19PM (#391026) Homepage
    The upcoming NFSv4 [nfsv4.org] standard will support strong authentication, encryption, and server-side access control. A group at CITI is working on a Linux implementation of NFSv4 [umich.edu].
  • True capabilities [erights.org] (as found in EROS [eros-os.org] or E [erights.org]) 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.

  • Re:Linux is well on the way (Score:3)

    by syrjala ( 139739 ) on Thursday March 01, 2001 @05:33PM (#391028)
    Driver for your DVD card can be found at http://dxr3.sourceforge.net/ [sourceforge.net]

    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)

    by Erasmus Darwin ( 183180 ) on Thursday March 01, 2001 @06:29PM (#391029)
    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.

    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)

    by BlowCat ( 216402 ) on Thursday March 01, 2001 @03:29PM (#391030)
    Capabilities in the kernel determine whether you can do certain things, e.g. change parameters of the network or create devices with mknod.

    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)

    by MrKhuel ( 10637 ) on Thursday March 01, 2001 @06:50PM (#391031) Homepage

    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.

  • 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)

    by cicadia ( 231571 ) on Thursday March 01, 2001 @04:04PM (#391033)

    ACL determine who can access a particular file.

    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)

    by Ignatius ( 6850 ) on Thursday March 01, 2001 @07:07PM (#391034)
    Why not take the same approach to capabilities as it is done with devices: Standard UNIX permissions already allow any arbitrary combination of access rights to character and block-devices to be granted to users and (via. the SUID flag) also to programs.

    To extend this scheme to privileged system calls, simply make up some pseudo file (e.g. /proc/cap/settimeofday) and let the kernel check the permissions of these files against the uid of the calling process.

    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 /usr/bin/xntpd
    -rw-rw---- root settime /proc/cap/settimeofday
    -rw-rw---- root deamon /proc/cap/privport

    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:
    • No recompiles of userland programms necessary.
    • Consitent with the existing permission scheme for device drivers.
    • Can be applied to users as well as programms.
    • Privileges can be revoked at any time without having to rely on proper behaviour of the program (e.g. gobally drop permissions to open privileged ports after boot-up phase)
    • No new userland tools necessary.
    • No extra process data structures in the kernel.
    • Dosn't require any new filesystem features.
    • Probably a lot easier to implement.
    • Just give all capability files perm 600 root.root and you have everything as it is now.

    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)

    by ip4noman ( 263310 ) on Thursday March 01, 2001 @03:03PM (#391035) Homepage

    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...

    Quite powerful. At the same time, it's also contains a certain potential danger due to making an unprivileged binary slightly privileged.
    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 ...

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close