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

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Security Linux

Mastering POSIX File Capabilities 80

Posted by kdawson from the wee-dram-of-privilege dept.
An anonymous reader passes along an IBM DeveloperWorks article on POSIX file capabilities, which have recently become available in the Linux kernel; they are expected in the mainline kernel by 2.6.24. POSIX file capabilities parcel out root user powers into smaller privileges. The article details how to program using file capabilities and how to switch on the ability of a system's setuid root binaries to use file capabilities.
This discussion has been archived. No new comments can be posted.

Mastering POSIX File Capabilities More

Mastering POSIX File Capabilities

Comments Filter:
  • Wow, they've invented a neutered version of RBAC. [sun.com]

    way to be innovative.

    • Re: (Score:3, Interesting)

      by amorsen ( 7485 )
      RBAC has been in Linux for a long time, in the form of SELinux. The new thing is that you can store the privileges in the file system. The advantage is that you don't need to modify your formerly set-uid applications, so it is easier on the system administrator. The disadvantage is that you don't need to modify your applications, so any security vulnerabilities caused by running with a lower privilege (yes, that is possible) might not be discovered by the good guys first.
    • Years ago, we swiped the idea from SGI's Irix. They seem to have swiped it from Data General's DG-UX.

      We implemented everything but the filesystem support. Filesystem support is complicated. It's actually SE Linux that has driven our ability to put arbitrary security markings on files, along with non-security desires for various extended attribute and multi-fork things.

      Unfortunately the set of bits was nearly copied from SGI's Irix, where it was botched. The bit choice is inflexible, redundant, and rather sm
  • How do POSIX capabilities compare to systrace?

  • Recently become available? (Score:3, Interesting)

    by RAMMS+EIN ( 578166 ) on Sunday December 23, 2007 @03:48AM (#21796490) Homepage Journal
    Quoth the summary:

    ``POSIX file capabilities, which have recently become available in the Linux kernel; they are expected in the mainline kernel by 2.6.24.''

    Recently become available? Haven't POSIX capabilities been in Linux for some time? I seem to recall reading about them in the documentation for some 2.4 kernel, and there is a Gentoo page about them from some time in 2005. Am I missing something?
    • I just looked at the capability.h on my system, and it has

      #define _LINUX_CAPABILITY_VERSION 0x19980330

      This suggests to me that Linux has had capabilities since 1998 at least...

    • Re:Recently become available? (Score:5, Informative)

      by Junta ( 36770 ) on Sunday December 23, 2007 @04:05AM (#21796536)
      POSIX capabilities are old, the ability to store which capabilities are permitted just like ACLs/owner/permission is new.

      So before, ping gets executed and it's up to ping code to assume/give up unneeded POSIX capabilities as permitted by the rather broad setuid bit. Now, it's execed only with the appropriate capabilities even being possible, without needing the rather broad setuid bit being set. Setuid can be safe with effort, but if the program can operate under a more specific security context, all the better.

    • Re: (Score:3, Interesting)

      by RAMMS+EIN ( 578166 )
      Ah, I see now that I _was_ missing something.

      What is new is not that Linux has POSIX capabilities.

      What is new is that you can store a description of the capabilities an executable is to receive _on the executable_.

    • Re: (Score:3, Insightful)

      by jd ( 1658 )
      Patches for POSIX ACLs have existed for some time. Patches for controls in excess of POSIX have also existed for some time. Some filesystems have also supported ACLs (POSIX or their own) for some time, independently of the rest of the kernel. Linux also has very sophisticated security modules, including Linux capabilities and SELinux.

      Linux having full POSIX capabilities is good, but frankly there are getting to be too many wholly independent security mechanisms. That's not to say that a single system woul

      • Re: (Score:1)

        by devangm ( 869429 )
        There are too many security mechanisms, and apart from those offered as patches, it's the distro that decides what you end up with. Some have multiple options, most don't. I use grsec/PaX with TPE to run all internet programs under a different user which can't execute anything except what's installed in /usr/bin. Combined with building all those internet programs using -fstack-protector-all on gentoo and restrictive user/group permissions on important directories, I think it's pretty good security without A
      • The biggest problem I see with the current system is that it isn't comprehensive. There's no easy way to provide trusted computing to memory (especially shared on the system, distributed or otherwise networked), security models generally don't work over clusters (eg: migrating a process from one machine to another won't necessarily migrate security labels or permissions), VNIC and Infiniband cards can RDMA direct into and out of memory without reference to security models, etc. This isn't a Linux problem, p

        • Re: (Score:2)

          by jd ( 1658 )
          Oh, I completely agree that that is what is done in practice. However, I think it's stupid and naive - even if you completely trust all the users, you can't trust all of the users' applications to be so bug-free all the time that they don't disrupt the system or delete critical files. For that matter, from the earliest known AT&T malware to computer viruses, malware has got itself added without the knowledge of users onto software.

          If you want to get a bit more paranoid, the sorts of companies using hi

    • int Yes = setreuid(owned, biatch);

  • I mastered them... (Score:5, Insightful)

    by m2943 ( 1140797 ) on Sunday December 23, 2007 @05:21AM (#21796696)
    by not using them. They are some holdover from a time when people thought that VMS was so much better than UNIX because it had so many more features.

    The first principle of security is KISS, and they violate this principle big time.

    • Re: (Score:2, Insightful)

      by devangm ( 869429 )
      Yes they do, give me memory/stack protection over POSIX ACL's any day.
    • Lots of programs try to limit themselves when run as setuid root. For example, they refuse some kind of user input. If they see that they are NOT running setuid root, then they assume that they have no privilage and that thus there is no need to limit themselves.

      Other programs assume that if ONE privileged operation succeeds, then some OTHER privileged operation will also succeed. (because root can traditionally do everything) When that other operation fails unexpectedly, you may get some sort of inconsista

      • With this new feature, both sorts of sloppy programming become security holes.

        Sloppy programming is security holes.

        Assuming the implemenation works fine, then if an app is making the assumption that because it can do X then it can do Y, well, it will find out that it really cannot do Y, and it'll get killed. Then you can fix it. Ah, the tragedy!

        • Re: (Score:2)

          by r00t ( 33219 )
          That could be a big problem, commonly a denial-of-service.

          Suppose the app takes a lock (or similar) which requires privilege. This succeeds. The app then does something else which requires privilage, and fails.

          If the app dies at this point, things are stuck. Hopefully a reboot can clear the problem. Depending on the nature of the app, you may well have database corruption.

          BTW, maybe I shouldn't have referred to the first case as sloppy programming. It's perfectly legit on a traditional system that lacks the

  • old news (Score:2)

    by Tom ( 822 )
    What a misleading article. There are some technical details that are new, but capabilities are extremely old and have been available for Linux for almost a decade. They haven't seen much use, and that's the part that might change, but filing this as a new development is stupid. It'll only invite the windos shills to claim that windos is so much better because they've had granular permissions for sooo long (yes, they had, for about the same time Linux did. same story, almost nobody uses them.)

    • Re: (Score:2)

      by IkeTo ( 27776 )
      > There are some technical details that are new, but capabilities are
      > extremely old and have been available for Linux for almost a decade.

      I don't think so. Process capabilities are there for a long time, but file capabilities has not been there (in other words, there is no file system that support letting users to set programs to be "setuid 0, but only allow sending signals to arbitrary processes, without any other special ability of the root user"). Without file capabilities, only programmers can

      • Re: (Score:2, Informative)

        by cocacoch ( 1207052 )
        Since the so called sendmail capabilities bug there was no broad use of capabilities. But inside the kernel, capabilities "survived". If a process was asking for a privileged action like opening a privileged port, the process was checked for having the needed capability. As there was no way to grant a process a distinct capability the only way was to start this process in the context of root, who has by definition all capabilities. Now its possible to give the binary the extended attribute capability and if

        • Re: (Score:2)

          by Monkius ( 3888 )
          Well, there was and is broad use, I think. For example, grsecurity (http://www.grsecurity.org/) allow policies to be created wherein policies are granted and revoked to specific processes. Neither modification of programs nor file labelling is required. Selinux of course also allows administrators fine-grained control over capabilities--in a much more comprehensive framework than these file capabilities.
          • I'm accompanying this implementation with documentation and testing of file capabilities since more than a year. My impression is since the usage of capabilities is as simple as storing them in the file system and using the in-kernel infrastructure, there is wider interest in capabilities and more development in this field. Now you can control the power of programs and daemons/server, in a simple and intuitive way. You don't have to trust the program to decrease its capabilities. See here for examples http: [friedhoff.org]

      • Re: (Score:2)

        by nuzak ( 959558 )
        > (in other words, there is no file system that support letting users to set programs to be "setuid 0, but only allow sending signals to arbitrary processes, without any other special ability of the root user"

        Doesn't it sound barkingly insane to say "run as a God User except only able to do X, Y, and Z?" Why indeed even have root in the first place? But that's still what these capabilities are -- set a single set of bits in a process (to all zeros no less) and let it do everything, THEN strip out what
        • If you grant the necessary capability, there is no reason to run the binary in the context of root. Just give enough power in the form of capabilities and you don't need and don't have any suid0 progs. Before the you had to rely on the root-started binary to reduce the set of capabilities itself. Now you start the binary in an unprivileged user context with just this needed set of capabilities.

  • More complexity = less security (Score:3, Interesting)

    by xtronics ( 259660 ) on Sunday December 23, 2007 @05:14PM (#21800706) Homepage
    Be afraid of complexity junkies where security is involved.

    I've used and supported both Windoze and Unix systems and find that the more complex file permissions are the more likely they are to be simply turned off. The Current Linux system works well enough and users can understand it well enough. These other fixes will only create 10 times the problems they claim to fix.

    • Be afraid of complexity junkies where security is involved.

      I don't think that the OpenBSD folks [openbsd.org] are complexity junkies. OK, I'm not really up on all this stuff, but I think I get the gist of their thinking. Here's what I believe the pro-capabilities people would tell you:

      You're advocating a false economy. Sure, capabilities are potentially complex and the implementation is hard to get right. Still, you only have to do it right one time and everything else benefits. In today's situation, we have things like "ping" running setuid root so that it can create r

      • You're advocating a false economy. Sure, capabilities are potentially complex and the implementation is hard to get right. Still, you only have to do it right one time and everything else benefits. In today's situation, we have things like "ping" running setuid root so that it can create raw sockets and Apache launching as root so that it can bind port 80 before dropping privileges.

        Yup. If Debian came out with an apt package that implemented ACLs that just worked with apt, dozens of people around the world

  • Too much to hope for? (Score:3, Informative)

    by glwtta ( 532858 ) on Sunday December 23, 2007 @06:02PM (#21801038) Homepage
    Does this mean that I'll finally be able to allow servers to bind to port 80, without having to run the whole thing as root? Please?

    Apache does pretty well with "downgrading" its running privileges, but many others, not so much.

    • Re: (Score:3, Interesting)

      by Nevyn ( 5505 ) *

      Yes, CAP_NET_BIND_SERVICE is a distinct capability. See "man capabilities" on a Linux box, although you may also want to give it CAP_SYS_CHROOT ... depending on how paranoid you are.

Slashdot Top Deals

C'est magnifique, mais ce n'est pas l'Informatique. -- Bosquet [on seeing the IBM 4341]

Close