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://www.friedhoff.org/posixfilecaps.html. And you can secure your system without a security infrastructure, of which quite a few people say they are to complicated to be securely applied. If you know people/systems that use capabilities to secure systems, let me know.
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.
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 so the resulting process is checked whether it has the needed capability (which is stored inside the xattr capability). Now you don't have to trust the program to reduce its set of capabilities, you can start it with and only with the needed capabilities. So if ping goes wild, it can only open more ports but not - lets say - change your/etc/passwd. Now, there is a mean to eliminate root-owned suid-bit binaries. For examples have a look at my documentation: http://www.friedhoff.org/fscaps.html
Slashdot Mirror
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://www.friedhoff.org/posixfilecaps.html. And you can secure your system without a security infrastructure, of which quite a few people say they are to complicated to be securely applied. If you know people/systems that use capabilities to secure systems, let me know.
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.
... but not for you as a user or admin usable to secure your system. Ideas how to use it: http://www.friedhoff.org/fscaps.html
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 so the resulting process is checked whether it has the needed capability (which is stored inside the xattr capability). Now you don't have to trust the program to reduce its set of capabilities, you can start it with and only with the needed capabilities. So if ping goes wild, it can only open more ports but not - lets say - change your /etc/passwd. Now, there is a mean to eliminate root-owned suid-bit binaries. For examples have a look at my documentation: http://www.friedhoff.org/fscaps.html