User: Password:
Subscribe / Log in / New account

File-based capabilities

File-based capabilities

Posted Dec 1, 2006 19:10 UTC (Fri) by giraffedata (subscriber, #1954)
Parent article: File-based capabilities

The article misses the point that Linux capabilities were designed from the beginning to have this. It is not a new idea; it's just completing the job. (It hasn't been completed before now because people just haven't been interested in fine-grained capabilities).

The capability masks stored with the file completely overwrite the process's current capabilities.

However, this flies in the face of the original design. I know the meanings of the 3 capability sets is hard to grasp, but it looks like someone failed here. A file's permitted set is supposed to be those capabilities that get added to a process by virtue of execing the program in that file (the traditional effect of setuid 0). A file's inherited set is supposed to be those that a process is allowed to keep even though it execed that program (it removes capabilities -- the traditional effect of setuid non-zero).

A process also has 3 permission sets that are unfortunately identically named. Simply setting those masks from an attribute of the exec'ed file isn't nearly as useful.

The setting of capabilities is done outside of the check for filesystems mounted with the nosuid option.

This is dangerous as all hell. If it goes in this way, they had better make sure this entire function is disabled by default, or a bunch of systems are going to be compromised by installing the new kernel code.

Here's some interesting information from someone with experience in Linux capabilities (me):

  • I analyzed them all once and found that 6 of them are equivalent to all of them (having any one allows you to get all the others). They're still effective against accidental damage, but not against intentional damage.
  • Most privileges are piled into one capability: SYS_ADMIN.
  • The most frequently useful one (NET_BIND_SERVICE) lets you bind a reserved port number and nothing else, but the problem of programs that have setuid 0 just for that can be solved more cleanly by having separate program bind the port and pass the file handle to the untrusted program.
  • The setuid 0 programs that have had the scariest security bugs in them are usually the ones that can't be limited to weak capabilities. E.g. SSH server, file server, mail server.

(Log in to post comments)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds