Sunday, January 20, 2013

POSIX


With the inclusion of File POSIX Capabilities in Kernel 2.6.24 has Linux finally reached a stage, where POSIX Capabilities are usable and useful. Although POSIX Capabilities arrived at Kernel 2.2, the File part waited up to 2.6.24 to make its appearance. Now Linux is closing its gap to other systems in regards of POSIX Capabilities.Well, from far above, thats true and even closer its not wrong. But there were plans and patches for file support of PCaps for 2.3. Later different patches were also available. Due to a bug called the sendmail bug, they hadn't had enough support. And further an open question was, where actually store the File POSIX Capabilities.

Now the dark age is over and the bright future of POSIX Capabilities in Linux is awaiting us.POSIX Capabilities are Privileges. They are called POSIX Capabilities because the POSIX document 1003.1e describes the idea of having a system of privileges - called capabilities -, which are taken into account in the decision of granting a process access to certain actions. As Capabilities are something different - a subject-object-right relationship - these privileges following the idea of the POSIX document 1003.1e are dubbed for Linux POSIX Capabilities.Practically speaking, the sum of all POSIX Capabilities forms the Root power or the other way around the root power is split up in discrete privileges -

POSIX Capabilities.POSIX Capabilities break with the root model. The everything or nothing principle in regards of privileges is not necessary and not justified. Neither is it adequate to give a program the whole power of root to just open a socket (-> ping) nor to give the user with the back up role this whole power, when he or his tools shall only read all files of all user to back them up.

Depending of the set-up, a program itself might hold the necessary privilege to fulfill his task. Not the user credentials are decisive, but the programs privileges are now. The idea of ACLs is in the same POSIX document developed. Combining the shift of granting privileges from users to programs with access control to these programs opens new possibilities in creating privilege distribution models and role models.The technique of Inheritance opens for the POSIX Capabilities infrastructure further fascinating solutions. Granting users and applications PCaps in a form, where only the adequate user-application PCaps combination results in actually effective privileges.Types of usage of POSIX Capabilities - Substitution of suid-0 privilege with POSIX Capabilities privilegeTypes of usage of POSIX Capabilities - Server running as a distinct unprivileged userTypes of usage of POSIX Capabilities - Different privilege levels for different user rollsTypes of usage of POSIX Capabilities - On the code level application insidePOSIX Capabilities - Capability Flag, Set and StatePOSIX Capabilities - Permitted Flag, Permitted SetPOSIX Capabilities - Effective Flag, Effective SetPOSIX Capabilities - Inheritable Flag, Inheritable


SetPOSIX Capabilities - Capability RulesMotivationHowTo - Requirements - Check your systemHowTo - Kernelspace - Compile and InstallHowTo - Userspace - Compile and InstallHowTo - Configuring and Using PCapsHowTo - Detection of needed capabilities - IntroHowTo - Detection of needed capabilities - straceHowTo - Detection of needed capabilities - capable_probe moduleHowTo - Removing capabilitiesFile system operations - updating distro packagesFile system operations - mv and cp (coreutils)File system operations - Back up and restore with tarFile system operations - back up and restore with rsyncExamples - Substitution of suid-0 privilege with POSIX Capabilities privilegeExamples - Server running as a distinct unprivileged user - ApacheExamples - Server running as a distinct unprivileged user - BindExamples - Server running as a distinct unprivileged user - CupsdExamples - Server running as a distinct unprivileged user - DHCPDExamples - Server running as a distinct unprivileged user - SAMBAExamples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - IntroExamples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - Installing the bitsExamples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - Exploring InheritanceExamples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - SUID-BIT 0 reloadedExamples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - ConvenienceExamples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - Different Administration RollsLectures, Talks and Presentations 


Types of usage of POSIX Capabilities - Substitution of suid-0 privilege with POSIX Capabilities privilegeA program runs in the privilege context of the user, who has started the process. For some tasks the privilege level of the user is insufficient to achieve the task. To solve this limit, it is possible to run an program in the context of the file owner, which is signified by the suid-bit. Hence referring to the privilege level there are only two user types, the super user aka root and the unprivileged user, the file owner is to overcome the lack-of-privilege-problem obviously root. Resolving the lack of privilege problem by using suid-bit technique results therefore in processes running in the right context and on the power level of root.



A famous example is /usr/bin/passwd which changes the password depending on your configuration in /etc/passwd or /etc/shadow. Whereas world is allowed to read /etc/passwd only user root is allowed to change /etc/passwd or /etc/shadow. To offer nevertheless the unprivileged user the possibility of changing his password, he has to start an application with the required privilege. Because his credential is insufficient the suid bit offers the way to use the credential of the file owner aka root. The file ownership of root in combination with the suid bit and the right to execute this file for the group owner or even world makes it possible for members of the mentioned group or even world to perform an action, where the own level of privileges is not adequate.The idea of joining the necessary privilege to perform successful a certain action with the executable to call instead of deriving the privileges from the calling user, the idea of the suid bit, is one way of using POSIX Capabilities. The difference is, root is equivalent to granting all for the system available


PCaps, whereas with PCaps you can grant just the minimal necessary privileges. Substituting the suid bit root technique with PCaps follows the 'principle of least privilege'.More technically speaking, a further difference is, that the suid-bit-root privilege handling derives its privileges from the user root, again a user-privileges combination. Where the real user stays the calling unprivileged user, the effective user of the resulting process changes to root.With PCaps, the through PCaps granted privileges to the binary are connected directly to the binary and in executing the binary the real and effective user don't change.In the examples section, you will find different suid-0 binaries with their respective PCaps.top  Types of usage of POSIX Capabilities - Server running as a distinct unprivileged userServer in the sense of software are started either by in the root context running programs or have to be started as root. They are running in the privilege level of root because they are requesting or performing action for which special privileges are necessary. Because with PCaps it is possible to grant individual privileges to binaries, there is no need to give a server process the full set of privileges through running in the root context.A conceivable server occupies a privilege port, accesses its configuration files and writes log data. We create a user and group solely reserved to this server. We change user and group ownership of the file the server has to write to, his log files, to his user and group. We grant this server the privilege to open privilege ports. We start this server in the context of his user and group. Now we have a server, running as a distinct but unprivileged user, which has just the needed minimal privileges and still protected from other user. If this server goes wild, all the server can do now is in the limit of his granted privileges to his binary, here opening privileges port, and further in the limit of his unprivileged user, for example changing his file. Getting the root level of privileges is through problems in the server software not possible anymore.top  Types of usage of POSIX Capabilities -


Different privilege levels for different user rollsThe everything or nothing of the privilege root model can be substituted. Now we can grant users certain privileges, which are only becoming effective with binaries, which are expect to be called by a process, and a logged in user is system intern one or more processes, who has also this privileges. The sets of PCaps of the calling process and the called binary have to match to be effective. Effective in the sense that only by matching the PCap will be granted the Permitted (p) Flag.A PAM based login process grants according to the configuration a user a set of POSIX Capabilities to his Inheritance Set. Now this user can start a process of which the corresponding binary expect through his Inheritance Set to be called by a process with the same POSIX Capabilities in his Inheritance Set. Unprivileged user, without the required PCaps in their Inheritance Set, won't be able to start the binary successful. The resulting process will lack the needed privileges and because of this will bail out or fail.Applicable is this concept in two directions. Granting additional privileges to user and preparing the corresponding applications will enables this user to call and execute that application successful. Imaginable are back up roles in combination with back up tools, the user is allowed to cross ownership limits for reading files, or time changing roles, module loading roles or network interface configuration roles.The other direction looks at former suid-0 binaries. Not enabling them for every user but only for adequate empowered user, results in user roles without these privilege. This users will not even allowed to call and execute programs, which are today through suid-0 accessible.top  


Types of usage of POSIX Capabilities - On the code level application insideThe easiest way of handling privileges is ignoring them. Just execute. If the level of privilege is not sufficient, the system gives a permission denied. By checking the return code, the program is more friendly in stopping instead remaining in an undefined state.Checking for being called as root, if the program needs privileges is another way. If not executed as root exit with an error message.Using PCaps without relying on granted PCaps means expecting to be started as root, decreasing into an unprivileged user and keeping the PCaps, that are necessary.PCaps aware means checking on program start for the needed PCaps in the Permitted Set and clearing the Effective Sate. Setting needed PCaps around the adequate code Effective and leave them otherwise only in the Permitted Set. Further remove PCaps from the Permitted Set if not needed anymore.top  POSIX Capabilities - Capability Flag, Set and StateThe Capability Flag is a per-capability attribute. The Capability Flags are named Permitted (p), Effective (e) and Inheritable (i). These flags apply to each capability separately.All POSIX Capabilities, which have a certain Flag form the respective Set. So there exists the Permitted (P), Effective (E) and Inheritable (I) Set.All POSIX Capabilities with all their Flags form the POSIX Capability State. The POSIX Capability State contains therefor all three Sets (obviously).top  POSIX Capabilities - Permitted Flag, Permitted SetThe Permitted Flag (p) marks a PCap as available. The Permitted Set (P) is the sum of all PCaps with the Permitted Flag.The File Permitted Set (fP) forces the PCap into the Permitted Set of the resulting process. The File Permitted Set is also called the Forced Set.The Permitted Set of a process, the Process Permitted Set (pP), contains all PCaps a process can use. The Process Permitted Set marks also the maximum set of all usable PCaps for a process. For processes only PCaps in the Permitted Set may have the Effective and / or Inheritable Flag rsp be part of the Effective Set and / or Inheritable Set.To enhance the security, process may also irrevocable delete PCaps out of his Permitted Set, if the process doesn't need them anymore.top  


POSIX Capabilities - Effective Flag, Effective SetThe Effective Flag (e) marks a PCap as armed, in effect and direct usable for a process. The Effective Set (E) is the sum of all PCaps with the Effective Flag.PCaps of the File Effective Set (fE) must also have the Permitted Flag or the Inheritable Flag. The File Effective Set (fE) populates the Process Effective Set of the resulting process if and only if the PCaps is also in the Process Permitted Set of the resulting process.PCaps unaware programs are not capable of populating their Effective Set them self. This has to be done through the File Effective Set of their respective executable.PCaps of the Process Effective Set (pE) give the associated privilege to the now running process respectively to the sequence of the now executed code. PCaps of the Process Effective Set must also be part of the Process Permitted Set. A PCaps aware program will raise and lower itself his PCaps into and out of his Effective Set on a as-needed basis.top  POSIX Capabilities - Inheritable Flag, Inheritable SetThe Inheritable Flag (i) marks a Pcap as hereditary/heritable (erbbar) for file or inheritable (vererbbar) for processes. The Inheritable Set (I)is the sum of all PCaps with the Inheritable Flag.The File Inheritable Set (fI) contains PCaps which go only into the per exec() resulting Process Permitted Set (pP') if the calling process has the same PCaps in his Process Inheritable Set (pI).The File Inheritable Set migrates not in the new Process Inheritable Set (pI'). The calling Process Inheritable Set (pI) becomes unchanged the new Process Inheritable Set.PCaps aware applications may change, clear or populate their own Process Inheritance Set. PCaps unaware applications pass the Process Inheritance Set unchanged to a new per exec() created process.By using PCaps Inheritance, only selected processes with the adequate Process Inheritance Set may call and execute successful applications with accordingly prepared File Inheritance Sets.top  POSIX Capabilities - Capability RulesThe POSIX Capability State is calculated upon an exec(). A forc() or clone() doesn't change the PCaps State.As defined in 1003.1e p. 17Definition:p{I,P,E}' = post-exec() POSIX Capability Sets aka the PCaps State of the new processX = was not specified by 1003.1e and has subsequently become cap_bset - /proc/sys/kernel/cap-bound for LinuxfP = File Permitted Set of the called executable, also Minimal Forced Set calledfE = File Effective Set of the called executablefI = File Inheritance Set of the called executablespP = Process Permitted Set (here of the calling process)pE = Process Effective Set (here of the calling process)pI = Process Inheritable Set (here of the calling process)& --> Intersection| --> UnionRules: 1) pI' = pI 2) pP' = (X & fP) | (pI & fI) 3) pE' = fE & pP'Explanation:1) The Process Inheritable Set (pI) of the calling process becomes unchanged the Process Inheritable Set (pI') of the newly created process. So exec() is not changing the Process Inheritable Set.2) The Process Permitted Set (pP') of the per exec() newly created process is the union of two intersections. The first is the intersection of the system upper limit of possible PCaps (X) with the File Permitted Set (fP). The second is the intersection of the calling Process Inheritable Set (pI) with the File Inheritable Set (fI). In one sentence explained is the Process Permitted Set of the per exec() created process the union of the intersection of the system upper limit with the File Permitted Set and the intersection of the Process Inheritable set with the File Inheritable Set.3) The Process Effective Set (pE') of the newly created process per exec() is the intersection of the File Effective Set (fE) with the Process Permitted Set (pP') of the newly created process.Discussion:1) Through the transmission of the unchanged Process Inheritable Set (pI), as far as no PCaps aware application changes this set for them self and the following processes, is it possible for a user with his Inheritabtle Set to kick off and execute successful a chain of applications if his Inheritable Set meets the File Inheritable Sets (fI) of the called applications.2) The effect of the File Permitted Set (fP), also called Minimal Forced Set, is limited through the System Wide Upper Limit (X).A process gains its PCaps with Permitted Flags either through File Permitted Set (fP) (Minimal Forced Set) limited by the System Upper Level (X), or through the intersection of the calling Process Inheritable Set (pI) with the called File Inheritable Set (fI). By relying totally on inheritance a program can only be successfully executed, when both the caller and called have the same necessary PCaps in their Inheritable Set. Hence its possible to selectively allow only certain processes the succesful execution of adequately configured executables.3) After computing the new Process Permitted Set (pP'), only the PCaps which are in both the File Effective Set (fE) and the Process Permitted Set (pP') can be in the initial Process Effective Set (pE'). Initial because if the application is PCaps aware it will clear and populate himself his Process Effective Set. For PCaps unaware application it is evidently crucial, that the needed PCaps have to be in the Process Effective Set (pE) and therefor in the Process Permitted Set (pP).Remark: Dependencies of SetsPCaps of File Effective Set have either to be part of the File Permitted Set or the File Inheritable Set.Only PCaps of the Process Permitted Set can be part of the Process Effective Set or the Process Inheritable Set.top  MotivationThe kernel version 2.6.18 introduced the privilege requirement to have the CAP_NET_ADMIN capability to create a tuntap interface. I was using qemu (www.qemu.org). To interact with a virtual machine you need a lan connectivity through a tuntap interface. Qemu needed from now on this privilege and through lack of alternatives root privilege.


I was uneasy having a not so trusty os running in an suid-0 container. First I patched the three lines out of the kerneldiff -ruN linux-2.6.18-orig/drivers/net/tun.c linux-2.6.18/drivers/net/tun.c--- linux-2.6.18-orig/drivers/net/tun.c 2006-09-20 05:42:06.000000000 +0200+++ linux-2.6.18/drivers/net/tun.c 2006-10-02 09:21:52.000000000 +0200@@ -489,9 +489,6 @@ err = -EINVAL;- if (!capable(CAP_NET_ADMIN))- return -EPERM;- /* Set dev type */ if (ifr->ifr_flags & IFF_TUN) { /* TUN device */and I was back where I was before 2.6.18, but this was not super elegant. In the process of understanding capabilities I found Serges Hallyn's fscaps patch and applied it. I accompanied this patch with tests and documentation. It made it into 2.6.19-rc5-mm2 and stayed for one year in the -mm tree to mature. With 2.6.24-rc2 entered the patch now named 'posix file capabilities' mainline to form the option 'File POSIX Capabilities' under security. KaiGai Kohei was from the end of 2006 to the end of 2007 (11?) providing the user space tools by adding different patches to the libcap1 package. At the end of 2007 Andrew Morgan was again taking care of his libcap packages and with the changes from KaiGai it became the libcap2 package.The initial reception of the first version summer 2006 of fscaps patch was friendly but reserved. The second version in 10/2006 hadn't gained more attention. It was like asking "who needs this what for". I was the one who had a real use of this patch and was happy about it. And I started again the discussion on LKML. I gave test comments and wrote a documentation to help others to use the patch. Slowly the train started to move and a 'give it a round in -mm' brought it into the -mm tree. For a patch being in -mm, it got more attention, but it has taken one year.The coincidence chain was qemu-tuntap-2.6.18-cap_net_admin-me. I thought after File POSIX Capabilities went mainline everyone would be happy to substitute suid-0 binaries through File POSIX Capabilities. But nothing happens. So I do my part in spreading the news and promise of this technique through writing documentation, giving talks and coding conversion tools.top  HowTo - Requirements - Check your systemYou will need- a kernel >= 2.6.24- a filesystem that supports extended attributes like ext3- File POSIX Capabilities enabled- libcap2 package >=2.08Check the Kernel with$ uname -rCheck your Kernel Config by$ grep '\(XATtr\|CAPA\)' /boot/config-`uname -r`$ zgrep '\(XATtr\|CAPA\)' /proc/config.gzCONFIG_EXT3_FS_XATtr=yCONFIG_SECURITY_CAPABILITIES=yCONFIG_SECURITY_FILE_CAPABILITIES=yCheck your libcap package$ ls -l /lib/libcap.so*lrwxrwxrwx 1 root root 11 Mar 9 10:58 /lib/libcap.so -> libcap.so.2lrwxrwxrwx 1 root root 14 Mar 9 10:58 /lib/libcap.so.2 -> libcap.so.2.08-rw-r--r-- 1 root root 14660 Mar 9 10:54 /lib/libcap.so.2.08top  HowTo - Kernelspace - Compile and InstallIf your distribution repository has not an adequate configured kernel, you have to build your own kernel.Since 2.6.24-rc2 the file system support for POSIX Capabilities is part of mainline. So there is no kernel patching needed. Because the PCaps for files are stored in the extended attributes of that file, a further prerequisite is a file system, that supports extended attributes like ext3.kernel make menuconfigSecurity options ---> Enable different security models Default Linux Capabilities File POSIX Capabilities (EXPERIMENTAL)File systems ---> Ext3 journalling file system support Ext3 extended attributesIf you are working with "different security model" option, than check for "Default Linux Capabilities"Security options ---> Enable different security models Default Linux CapabilitiesAfter you finished your kernel configuration, call make, make modules_install, copy your new kernel to /boot, update your boot loader and reboot.top  HowTo - Userspace - Compile and InstallIf your distribution repository has not an adequate libcap2 package, you have to build your own libcap2 package.Since version 2.03 Andrew Morgan's libcap2 package supports 32-bit (mainline -rc of 2.6.24) and 64-bit (-mm of 2.6.24) capabilities. KaiGai Kohei's developments are integrated into the libcap2 package. You will find the tools setcap to set File PCaps State, getcap to read File PCaps State and getpcap to get the Process PCaps State.Note: As a discussion on LKML revealed, SUSE's libcap-1.92 package in SuSE-9.1 to SUSE-10-1 is not compatible to kernel >= 2.6.25 (24?) and might break apps. Replace this package with the old and original libcap-1.97, if you don't want to use PCaps or libcap-2.08, if you want to use PCaps.[http://lkml.org/lkml/2008/4/22/18]Andrew Morgan's libcap2Get the libcap2 package, extract, compile and install it.$ tar xjf libcap-2.xx.tar.bz2$ cd libcap-2.xx$ make$ sudo make installIts a good idea to test your configuration by executing quicktest.sh in root context.$ cd progs$ sudo ./quicktest.shtop  HowTo - Configuring and Using PCapsAfter building, installing and rebooting the new kernel with extended attributes and File POSIX Capabilities and compiling and installing the userspace tools, we use setcap and getcap to do the work.To get an idea of the available capabilities have a look atless /usr/include/linux/capability.hman capabilitiesThis will clarify the complete set of capability the root power consist of. It is not justified to arm a binary or process with all these capabilities, when its just shopping for a raw socket. Only the lack of mean to adequately equip a binary with the appropriate set of capabilities has leaded to suid-0 binaries.Granting a PCap is as simple as$ sudo setcap cap_net_admin=ep /bin/pingReading granted capabilities is as simple as$ getcap /bin/ping/bin/ping: = cap_net_raw+epChecking the extended attribute$ attr -l /bin/pingAttribute "capability" has a 12 byte value for /bin/pingRemoving PCaps$ sudo setcap -r /bin/pingtop  HowTo - Detection of needed capabilities - Introping is a nice tool to exercise the hunt for the necessary capabilities. It is a root owned suid-bit-0 binary. All the commands will be executed by an unprivileged user. If we need root power, we will use sudo.By checking ping with ls -l we see the suid-bit (s) and that it is root owned. By executing, we see it works.$ ls -l /bin/ping-rws--x--x 1 root root 29364 2006-08-14 00:20 /bin/ping$ ping -c 1 localhostPING localhost (127.0.0.1) 56(84) bytes of data.64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.111 ms--- localhost ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.111/0.111/0.111/0.000 msNow by removing the suid-bit, ping - as expected - can't do it's work by lack of the needed capability.$ sudo chmod u-s /bin/ping$ ping -c 1 localhostping: icmp open socket: Operation not permittedHence the error message is not very explicative, we try strace.top  HowTo - Detection of needed capabilities - stracestrace is a diagnostic tool, which intercepts and records called system calls by a process and the signals which are received by this process by giving the name of each system call, its arguments and its return value. The EPERM error signifies that the caller was not privileged to call a certain function or resource.$ strace ping localhost 2>&1 | grep EPERMsocket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = -1 EPERM (Operation not permitted)The caller ping lacks the privilege to create a socket of type SOCK_RAW. /usr/include/linux/capability.h shows/* Allow use of RAW sockets *//* Allow use of PACKET sockets */#define CAP_NET_RAW 13This well chosen example showed us easily the needed PCap. You can expect programs that got denied different stuff with -EPERM, which they actually don't need to do. Here to deduce the needed PCaps will be far more complex. But we have another tool at hand.top  HowTo - Detection of needed capabilities - capable_probe moduleSerge E. Hallyn provides in his article 'POSIX file capabilities: Parceling the power of root' the source for the module capable_probe. This module helps us to see the requested PCaps by replacing any calls to cap_capable() by a call to cr_capable(). This function prints out the name of the program together with the requested PCaps. Afterwards it calls the cap_capable() function.Under Tools and Patches you will find a link for the package from this site. The included Makefile is expanded for an install target for the running kernel.Kprobes allows the insertion of probes. It allows to write small kernel modules to run code at the start of a function (jprobe), the end of a function (kretprobe) or at any address (kprobe). Enabling kprobes and the loading of the module capable_probe will allow us to see the PCaps which are required by the kernel to run the program successful.kernel make menuconfigInstrumentation Support ---> Kprobescapable_probetar capable_probe.tar.bz2cd capable_probemakesudo make installAfter inserting the capable_probe module, /var/log/messages will contain the program name with the requested capabilities, when the program is executed. Don't forget to unload the module afterwards. Otherwise your /var/log/messages log file gets flooded.Here we will work with 2 console. The first to observe /var/log/messages and the second to issue the commands.console1$ tail -f /var/log/messages/ | grep pingconsole2$ sudo modprobe capable_probe$ ping localhostping: icmp open socket: Operation not permitted$ sudo modprobe -r capable_probeconsole1...Dec 26 14:57:21 apollo kernel: cr_capable: asking for capability 21 for pingDec 26 14:57:21 apollo kernel: cr_capable: asking for capability 13 for pingDec 26 14:57:21 apollo kernel: cr_capable: asking for capability 7 for pingDec 26 14:57:21 apollo kernel: cr_capable: asking for capability 21 for pingAgain /usr/include/linux/capability.h clarifies the capabilities 7, 13 and 21.The capability "7: CAP_SETUID" is not what we want ping to do. We need no setuid manipulation.The catch-all capability "21: CAP_SYS_ADMIN" is better never granted to any program. We are talking about hardening a system by following the principle of least privilege and not about punching holes in.Common sens helped us to arrive again at capability "13: CAP_NET_RAW.Granting capabilities - PingAfter the long way around we arrived where we started, but now we know, that ping just needs the CAP_NET_RAW capability to send ICMP packets to a host. There is no need to have and run ping anymore as a suid-0 binary.$ sudo setcap cap_net_raw=ep /bin/pingtop  HowTo - Removing capabilitiesIf for some reason it is necessary or desirable to get rid of File PCaps ...Our favorite binary ping will serve us again as an example.ping is now a non-suid-0-bit binary and has the cap_net_raw file capability granted.In restoring the original state we have to remove the cap_net_raw capability and restore the suid-0-bit.before we restore, we check the point of departure ...$ getcap /bin/ping/bin/ping = cap_net_raw+ep$ ls -l /bin/ping-rwx--x--x 1 root root 28992 May 9 2007 /bin/ping$ attr -l /bin/pingAttribute "capability" has a 12 byte value for /bin/ping... and here we go back to the original state$ sudo setcap -r /bin/ping$ sudo chmod u+s /bin/ping$ ping -c 1 localhostPING localhost (127.0.0.1) 56(84) bytes of data.64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.090 ms--- localhost ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.090/0.090/0.090/0.000 msSo, that was not very dramatic ...top  File system operations - updating distro packagesA system is never static. At least security updates have to be applied, to keep the system as secure as possible.This maintenance of updating distro packages will unfortunately remove the system hardening with File PCaps as long as distro packages don't support PCaps. Updating a binary results in a new inode of the new binary. So the update of the old binary with his old inode will remove the granted capabilities.top  File system operations - mv and cp (coreutils)The cli tools mv and cp are part of the coreutils package (http://www.gnu.org/software/coreutils/). As of version coreutils-6.9, the package is except for ACLs not supporting extended attributes. Thanks to the coreutils-xattr.diff patch external support is available.Before the patched coreutils package compiles sucessfully, the required attr package (ftp://oss.sgi.com/projects/xfs/cmd_tars) has to be expanded by the xattr_conf.diff patch. This patch provides the needed attr_copy_action function. With this patch, the config file /etc/xattr.conf defines, which xattr are respected and which xattrs are ignored by file system operations.mvFor moving file, we have to differentiate between moving inside a file system and moving from one file system to another.Moving inside one file system is just a renaming the file system table entry and not touching inodes. Hence moving inside a file system doesn't require xattr support.Observing this operation with strace shows, that moving the binary myping from the current working directory to the sub folder testdir calls just rename.$ strace mv myping testdir/execve("/usr/bin/mv", ["mv", "myping", "testdir/"], [/* 53 vars */]) = 0...stat64("testdir/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0lstat64("myping", {st_mode=S_IFREG|0711, st_size=28992, ...}) = 0lstat64("testdir/myping", 0xbf97a664) = -1 ENOENT (No such file or directory)rename("myping", "testdir/myping") = 0...Process 28411 detachedMoving from one file system to another on a different partition is actually writing the file to the new file system and unlinking the old file. The extended attributes have to be assigned new. As a bonus I'm showing here the calls for libacl and libattr and the permisssion error. The permission error shows, that calling fsetxattr is only sucessful, when the process has the required priviledge. So beside allowing the file system operation binary to transport xattr through /etc/xattr.conf, the binary needs the PCap cap_set_fcap. Here in this example, as a consequence the xattr capability is lost.$ strace mv myping /var/testdir/execve("/usr/bin/mv", ["mv", "myping", "/var/testdir/"], [/* 53 vars */]) = 0...open("/lib/libacl.so.1", O_RDONLY) = 3...open("/lib/libattr.so.1", O_RDONLY) = 3...stat64("/var/testdir/", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0lstat64("myping", {st_mode=S_IFREG|0711, st_size=28992, ...}) = 0lstat64("/var/testdir/myping", 0xbfb36824) = -1 ENOENT (No such file or directory)rename("myping", "/var/testdir/myping") = -1 EXDEV (Invalid cross-device link)unlink("/var/testdir/myping") = -1 ENOENT (No such file or directory)open("myping", O_RDONLY|O_LARGEFILE) = 3...open("/var/testdir/myping", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0700) = 4...read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\340\216"..., 8192) = 8192write(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\340\216"..., 8192) = 8192read(3, "\204\355\2\0\0\201=T\373\4\10\347\3\0\0\17\216\33\n\0\0"..., 8192) = 8192write(4, "\204\355\2\0\0\201=T\373\4\10\347\3\0\0\17\216\33\n\0\0"..., 8192) = 8192read(3, "\300\17\204\351\2\0\0P\215E\360Ph\264\342\4\10S\350a\316"..., 8192) = 8192write(4, "\300\17\204\351\2\0\0P\215E\360Ph\264\342\4\10S\350a\316"..., 8192) = 8192read(3, "SUM)\0!E\0!EC\0From %s: \0ping: loca"..., 8192) = 4416write(4, "SUM)\0!E\0!EC\0From %s: \0ping: loca"..., 4416) = 4416...flistxattr(3, (nil), 0) = 20flistxattr(3, 0xbfb365d0, 20) = 20open("/etc/xattr.conf", O_RDONLY|O_LARGEFILE) = 5...fgetxattr(3, "security.capability", 0x0, 0) = 12fgetxattr(3, "security.capability", "\x01\x00\x00\x01\x00 \x00\x00\x00\x00\x00", 12) = 12fsetxattr(4, "security.capability", "\x01\x00\x00\x01\x00 \x00\x00\x00\x00\x00", 12, 0) = -1 EPERM (Operation not permitted)...unlinkat(AT_FDCWD, "myping", 0) = 0...Process 28422 detachedWithout strace we have a nice error message:mv myping /var/testdir/mv: setting attribute `security.capability' for `/var/testdir/myping': Operation not permittedcpThe cli tool cp provides the option --preserve. With cp --preserve=xattrs the copy operation dublicates also the extended attributes. In contrast to the example above with the nessecary privilege. As we can see, the PCap is copied.$ strace cp --preserve=xattr myping testdir/execve("/bin/cp", ["cp", "--preserve=xattr", "myping", "testdir/"], [/* 55 vars */]) = 0...open("/lib/libacl.so.1", O_RDONLY) = 3...open("/lib/libattr.so.1", O_RDONLY) = 3...stat64("testdir/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0stat64("myping", {st_mode=S_IFREG|0711, st_size=28992, ...}) = 0stat64("testdir/myping", {st_mode=S_IFREG|0711, st_size=28992, ...}) = 0open("myping", O_RDONLY|O_LARGEFILE) = 3...open("testdir/myping", O_WRONLY|O_trUNC|O_LARGEFILE) = 4...read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\340\216"..., 8192) = 8192write(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\340\216"..., 8192) = 8192read(3, "\204\355\2\0\0\201=T\373\4\10\347\3\0\0\17\216\33\n\0\0"..., 8192) = 8192write(4, "\204\355\2\0\0\201=T\373\4\10\347\3\0\0\17\216\33\n\0\0"..., 8192) = 8192read(3, "\300\17\204\351\2\0\0P\215E\360Ph\264\342\4\10S\350a\316"..., 8192) = 8192write(4, "\300\17\204\351\2\0\0P\215E\360Ph\264\342\4\10S\350a\316"..., 8192) = 8192read(3, "SUM)\0!E\0!EC\0From %s: \0ping: loca"..., 8192) = 4416write(4, "SUM)\0!E\0!EC\0From %s: \0ping: loca"..., 4416) = 4416flistxattr(3, (nil), 0) = 20flistxattr(3, 0xbfc78410, 20) = 20open("/etc/xattr.conf", O_RDONLY|O_LARGEFILE) = 5...fgetxattr(3, "security.capability", 0x0, 0) = 12fgetxattr(3, "security.capability", "\x01\x00\x00\x01\x00 \x00\x00\x00\x00\x00", 12) = 12fsetxattr(4, "security.capability", "\x01\x00\x00\x01\x00 \x00\x00\x00\x00\x00", 12, 0) = 0...Process 15337 detachedtop  File system operations - Back up and restore with tarThe back up tool tar up to version 1.20 from http://www.gnu.org/software/tar/ doesn't support extended attributes. Thanks to the external xattr patch, tar supports the saving and restoring of the extended attributes security.selinux, acl.access, acl.default, user.* and trusted.* with the flag --xattr. The patch I provide here adds support for the extended attribute security.capability.When we create the tarball and observe this with strace, we can see, that the PCaps are read and stored:$ strace tar --xattr -cf tarball mypingexecve("/usr/bin/tar", ["tar", "--xattr", "-cf", "tarball", "myping"], [/* 53 vars */]) = 0...open("/lib/libacl.so.1", O_RDONLY) = 3...open("/lib/libattr.so.1", O_RDONLY) = 3...open("tarball", O_WRONLY|O_CREAT|O_trUNC|O_LARGEFILE, 0666) = 3...open("myping", O_RDONLY|O_LARGEFILE) = 4...flistxattr(4, 0x8086130, 1024) = 20fgetxattr(4, "security.capability", "\x01\x00\x00\x01\x00 \x00\x00\x00\x00\x00", 1024) = 12...write(3, "./PaxHeaders.16524/myping\0\0\0\0\0\0\0"..., 10240) = 10240read(4, "}]\213\r\350,\6\10\205\311u\7=\370\377\0\0v7RPht\332\4"..., 10240) = 10240write(3, "}]\213\r\350,\6\10\205\311u\7=\370\377\0\0v7RPht\332\4"..., 10240) = 10240read(4, "\213\3+E\354\211\3\215\4\200\215\4\200\215\4\200\215\4"..., 10048) = 10048...write(3, "\213\3+E\354\211\3\215\4\200\215\4\200\215\4\200\215\4"..., 10240) = 10240write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 10240) = 10240...Process 16524 detachedWhen we extract the created tarball and observe this with strace, we can see, that the PCaps are restored. For restoring the xattr, tar needs the necessary privilege.$ strace tar --xattr -xf ../tarballexecve("/bin/tar", ["tar", "--xattr", "-xf", "../tarball"], [/* 55 vars */]) = 0...open("/lib/libacl.so.1", O_RDONLY) = 3...open("/lib/libattr.so.1", O_RDONLY) = 3...open("../tarball", O_RDONLY|O_LARGEFILE) = 3read(3, "./PaxHeaders.16524/myping\0\0\0\0\0\0\0"..., 10240) = 10240...open("myping", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0700) = 4write(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\340\216"..., 8704) = 8704read(3, "}]\213\r\350,\6\10\205\311u\7=\370\377\0\0v7RPht\332\4"..., 10240) = 10240write(4, "}]\213\r\350,\6\10\205\311u\7=\370\377\0\0v7RPht\332\4"..., 10240) = 10240read(3, "\213\3+E\354\211\3\215\4\200\215\4\200\215\4\200\215\4"..., 10240) = 10240write(4, "\213\3+E\354\211\3\215\4\200\215\4\200\215\4\200\215\4"..., 10048) = 10048...chown32("myping", 1000, 100) = 0...setxattr("myping", "security.capability", "\x01\x00\x00\x01\x00 \x00\x00\x00\x00\x00", 12, 0) = 0chmod("myping", 0711) = 0...Process 16751 detachedtop  File system operations - back up and restore with rsyncThe back up tool rsync supports since 3.x xattr. Just look for the string xattr in the output of 'rsync --version'.The flag {-X|--xattrs} preseves extended attributes. Executed in the context of root, rsync will copy all namespaces except system.*. Called by an unprivileged user, rsync will only copy the user* namespace.To sync files with PCaps, the files have to be owned by root and rsync has to be executed as root.$ strace -f rsync -a --xattrs testdir1/ testdir2/execve("/usr/bin/rsync", ["rsync", "-a", "--xattrs", "testdir1/", "testdir2/"], [/* 54 vars */]) = 0...open("/lib/libacl.so.1", O_RDONLY) = 3...open("/lib/libattr.so.1", O_RDONLY) = 3...getuid32() = 0geteuid32() = 0...getcwd("/home/chris/pcaps-testdir", 4095) = 26...clone(Process 13937 attached...[pid 13936] chdir("/home/chris/pcaps-testdir/testdir1") = 0...[pid 13936] llistxattr(".", 0x80c8eb8, 1024) = 0...[pid 13936] llistxattr("./myping", 0x80c8eb8, 1024) = 44[pid 13936] lgetxattr("./myping", "security.capability", 0x0, 0) = 12[pid 13936] lgetxattr("./myping", "security.capability", "\x01\x00\x00\x01\x00 \x00\x00\x00\x00\x00", 12) = 12...[pid 13937] chdir("/home/chris/pcaps-testdir/testdir2/") = 0...[pid 13937] clone(Process 13938 attached...[pid 13936] open("myping", O_RDONLY|O_LARGEFILE) = 3...[pid 13938] open("myping", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)...[pid 13938] open(".myping.MvDXAT", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 1[pid 13938] fchmod(1, 0700) = 0...[pid 13938] llistxattr(".myping.MvDXAT", 0x80ba538, 1024) = 0[pid 13938] lsetxattr(".myping.MvDXAT", "security.capability", "\x01\x00\x00\x01\x00 \x00\x00\x00\x00\x00", 12, 0) = 0...[pid 13938] chmod(".myping.MvDXAT", 0755) = 0[pid 13938] rename(".myping.MvDXAT", "myping") = 0......Process 13938 detached...Process 13937 detached...Process 13936 detachedtop  Examples - Substitution of suid-0 privilege with POSIX Capabilities privilegeHere we keep sticking to the idea of connecting the needed privileges to the binary. But instead of giving the binary all the privileges the root power consist of, we just grant the needed privileges in form of POSIX Capabilities as File POSIX Capabilities. Following the 'principle of least privilege', we reduce the amount of privileges.There is are reasons for suid-0 binaries to be usable for the unprivileged user. Here we don't doubt this decision, we just reduce the level of power.To have the binaries just ready to execute with their privileges without expecting them to be PCaps aware, we have to grant the PCaps with the Permitted (p) and Effective (e) Flag.To find the binaries with suid-0 we use find. Here the result from my installation$ find {,/usr}/{,s}bin -user root -perm -4000 -exec ls -l {} \;-rwsr-xr-x 1 root root 26352 Mar 9 03:54 /bin/su-rws--x--x 1 root root 28992 May 9 2007 /bin/ping-rwsr-xr-x 1 root root 49120 Mar 31 23:56 /bin/mount-rwsr-xr-x 1 root root 32208 Mar 31 23:56 /bin/umount-rwsr-xr-x 1 root root 19836 Mar 8 02:52 /bin/fusermount-rws--x--x 1 root root 26804 May 9 2007 /bin/ping6-rwsr-xr-x 1 root root 23344 Mar 9 02:42 /sbin/unix_chkpwd-r-s--x--x 1 root root 65048 Apr 1 05:09 /sbin/mount.nfs-rwsr-xr-x 1 root root 38464 Mar 9 03:54 /usr/bin/chage-rwsr-xr-x 1 root root 29196 Mar 9 03:54 /usr/bin/chfn-rwsr-xr-x 1 root root 24612 Mar 9 03:54 /usr/bin/chsh-rws--x--x 1 root root 10480 Dec 13 2006 /usr/bin/crontab-rwsr-xr-x 1 root root 18152 Mar 9 03:54 /usr/bin/expiry-rwsr-xr-x 1 root root 42956 Mar 9 03:54 /usr/bin/gpasswd-rwsr-xr-x 1 root root 22600 Mar 9 03:54 /usr/bin/newgrp-rwsr-xr-x 1 root root 30176 Mar 9 03:54 /usr/bin/passwd-rws--x--x 1 root root 14828 Apr 30 2007 /usr/bin/rcp-rws--x--x 1 root root 10764 Apr 30 2007 /usr/bin/rlogin-rws--x--x 1 root root 7944 Apr 30 2007 /usr/bin/rsh-rws--x--x 1 root bin 90400 Feb 6 2006 /usr/bin/sudo-rws--x--x 1 root bin 16100 Mar 3 2003 /usr/bin/traceroute-rws--x--x 1 root root 11484 May 9 2007 /usr/bin/traceroute6-rwsr-xr-x 1 root root 10104 Feb 26 21:40 /usr/bin/kcheckpass-rwsr-xr-x 1 root root 5412 Mar 8 05:49 /usr/bin/start_kdeinit-rwsr-xr-x 1 root root 11003 Oct 1 2006 /usr/bin/fileshareset-rwsr-xr-x 1 root root 5824 Mar 8 05:49 /usr/bin/kgrantpty-rwsr-xr-x 1 root root 6132 Mar 8 05:49 /usr/bin/kpac_dhcp_helper-rwsr-x--- 1 root floppy 19076 May 1 2002 /usr/bin/fdmount-rwsr-xr-x 1 root root 572008 Feb 26 03:52 /usr/bin/kppp-rwsr-sr-x 1 root mail 65368 Sep 19 2006 /usr/bin/procmail-rwsr-xr-x 1 root root 1651720 Dec 14 19:42 /usr/bin/XorgOut of this list have I substituted for the following binaries the suid-0 bit with PCaps.ping - CAP_NET_RAW (13)traceroute - CAP_NET_RAW (13)chsh - CAP_CHOWN (0), CAP_DAC_READ_SEARCH (2), CAP_FSETID (4), CAP_SETUID (7)chfn - CAP_CHOWN (0), CAP_DAC_READ_SEARCH (2), CAP_FSETID (4), CAP_SETUID (7)chage - CAP_DAC_READ_SEARCH (2)passwd - CAP_CHOWN (0), CAP_DAC_OVERRIDE (1), CAP_FOWNER (3)unix_chkpwd - CAP_DAC_OVERRIDE (1)mount - CAP_DAC_OVERRIDE (1), CAP_SYS_ADMIN (21)umount - CAP_DAC_OVERRIDE (1), CAP_SYS_ADMIN (21)First you have to remove the suid-0 bitsudo chmod u-s /usr/bin/chshthen grant the necessary PCapssudo setcap 0,2,4,7=ep /usr/bin/chshand at last test the binary.I provide the conversion tool pcaps4suid0 to do conversion and reversion for suid0 to PCaps and back.top  Examples - Server running as a distinct unprivileged user - ApacheServer software is usually executed as root. It might degrade itself to an unprivileged user, when the privileges the root power consist of are not necessary anymore or only a few privileges are needed further. But as so many suid-0 bit software these server software usually needs only a fraction of the privileges the root provides.The typical server software opens one or more privileged ports, accesses his files in his directories and might handle files of local users (might not be complete). So there is no need to load modules, change system time or kill processes of other users.To protect the process and files of the server from other users, the server will run with his own user and group.Apache is started with root privilege to bind itself to the privileged port 80 and 443 and open its usually only root owned config file, certificate, log files and pid file.I choose for the apache httpd daemon the newly created user id and group id apache. I will change the installation and configuration of apache to start and run as user:group apache:apache.This changes the configuration to be able to start apache as an unprivileged user and run apache as user:group apache:apache.First we add user apache and group apache to the system$$ sudo groupadd apache$ sudo useradd -g apache -d / apache$Than we make sure apache stays apache:apache by changing the User and Group directive in the configuration file /etc/httpd/httpd.conf$ sudo sed -i -e "{s|^\(User\).*|\1 apache|; s|^\(Group\) .*|\1 apache|}" /etc/httpd/httpd.confIf we like to have written a pid file, we create the private directory httpd under /var/run and adjust the reference in the httpd.conf.$$ sudo mkdir /var/run/httpd$ sudo sed -i "s|\(^PidFile\).*|\1 /var/run/httpd|" /etc/httpd/httpd.conf$Now we change ownership to apacha:apache of various directories and its content belonging to the httpd server$$ sudo chown -R apache:apache /var/run/httpd/$ sudo chown -R apache:apache /etc/httpd/$ sudo chown -R apache:apache /var/log/httpd/$ sudo chown -R apache:apache /PATH/TO/YOUR/HTTPD-DOCDIR$To ensure, that only the file owner apache or root may start the httpd binary, we change the permissions and ownership$$ ls -l /usr/sbin/httpd-rwxr-xr-x 1 root root 332996 Feb 14 22:39 /usr/sbin/httpd$ sudo chown apache:apache /usr/sbin/httpd$ sudo chmod g-x,o-x /usr/sbin/httpd$ ls -l /usr/sbin/httpd-rwxr--r-- 1 apache apache 332996 Feb 14 22:39 /usr/sbin/httpd/$Because the apache server doesn't need now any privileges accept for opening and binding to privileged ports we just have to grant CAP_NET_BIND_SERVICE to the httpd binary. Assuming, that the httpd binary can't populate its Effective PCaps Set, we grant beside the Permitted Flag (p) also the Effective Flag (e) for the PCap.$ sudo setcap cap_net_bind_service=ep /usr/sbin/httpdFor not messing up the file permissions and to prevent excessive privilege granting, root shall start the httpd daemon as user apache with something like$ su -c /usr/sbin/httpd apacheAs an unprivileged user you may, if your sudo configuration allows this, start apache just by typing$ sudo -u apache /usr/sbin/httpdSee how its running$$ pidof httpd15259 15258 15257 15256$$ ps -o cmd,pid,ppid,stime,time,euser,ruser -H f -U apache -u apacheCMD PID PPID STIME TIME EUSER RUSER/usr/sbin/httpd 15256 1 09:55 00:00:00 apache apache \_ /usr/sbin/httpd 15257 15256 09:55 00:00:00 apache apache \_ /usr/sbin/httpd 15258 15256 09:55 00:00:00 apache apache \_ /usr/sbin/httpd 15259 15256 09:55 00:00:00 apache apache$An other way to ensure, that httpd runs only as (effective user) apache is granting the suid-0 bit. In the combination with the execute right only for the owner, still no other unprivileged user may start this binary.$ sudo chmod u+s /usr/sbin/httpdWe simulate a root call per sudo and check again how it is running with euser and ruser. The real user stays root but as intended by the suid-0 bit the effective user changes to apache$$ sudo /usr/sbin/httpdchris@apollo ~ $ ps -o cmd,pid,ppid,stime,time,euser,ruser -H f -U apache -u apacheCMD PID PPID STIME TIME EUSER RUSER/usr/sbin/httpd 15320 1 11:37 00:00:00 apache root \_ /usr/sbin/httpd 15321 15320 11:37 00:00:00 apache root \_ /usr/sbin/httpd 15322 15320 11:37 00:00:00 apache root \_ /usr/sbin/httpd 15323 15320 11:37 00:00:00 apache root$To push it a little further, if we like to allow members of the apache group to start the httpd daemon, we first add this user to the group and change the permission accordingly to allow group members to execute the binary. Now members of the group apache may start the daemon. Non members are still not capable of starting the daemon. Here we use also the suid-0 bit to ensure, that the effective user of the httpd processes is apache.$$ ls -l /usr/sbin/httpd-rwsr--r-- 1 apache apache 332996 Feb 14 22:39 /usr/sbin/httpd$ /usr/sbin/httpdbash: /usr/sbin/httpd: Permission denied$$ iduid=1000(chris) gid=100(users) groups=100(users)$$ sudo usermod -a -G apache chris$ sudo chmod g+x /usr/sbin/httpd$ sudo su - chris$ iduid=1000(chris) gid=100(users) groups=60(apache),100(users)$$ /usr/sbin/httpd$ ps -o cmd,pid,ppid,stime,time,euser,ruser -H f -U apache -u apacheCMD PID PPID STIME TIME EUSER RUSER/usr/sbin/httpd 15490 1 12:00 00:00:00 apache chris \_ /usr/sbin/httpd 15491 15490 12:00 00:00:00 apache chris \_ /usr/sbin/httpd 15492 15490 12:00 00:00:00 apache chris \_ /usr/sbin/httpd 15493 15490 12:00 00:00:00 apache chris$I provide the conversion tool pcaps4server to do conversion and reversion for the apache daemon to PCaps and back.top  Examples - Server running as a distinct unprivileged user - BindThe name server bind provides name resolution to network clients. Instead of running as root, this daemon will run in the context of an unprivileged user.We will expand the level of privilege just to open and bind itself to privileged ports. Privileged ports are ports up to 1024.Here we choose as name for the user and group bind. First we have to add the user and the group$$ sudo groupadd bind$ sudo useradd -g bind -d / bind$Then we change the ownership of the directories and files belonging to the daemon.$$ sudo chown -R bind:bind /var/run/named$ sudo chown -R bind:bind /var/named$ sudo chown bind:bind /etc/namend.conf$ sudo chown bind:bind /etc/rndc.key$We make sure, that only the file owner bind (and root per definition) is allowed to start the daemon.$$ ls -l /usr/sbin/named-rwxr-xr-x 1 root root 338920 Apr 14 00:07 /usr/sbin/named*$ sudo chown bind:bind /usr/sbin/named$ sudo chmod g-x,o-x /usr/sbin/namedls -l /usr/sbin/named-rwxr--r-- 1 bind bind 338920 Apr 14 00:07 /usr/sbin/named$By not running as the privileged user root the binary named now misses the needed privilege of opening and binding to privileged ports. So we grant the CAP_NET_BIND PCap.$ sudo setcap cap_net_bind_service=ep /usr/sbin/namedTo keep the installation clean and to prevent granting an excessive privilege level root shall execute named by$ su -c /usr/sbin/named bindIf an unprivileged user is allowed through the configuration of sudo, he may execute$ sudo -u bind /usr/sbin/namendInstead of specifying the user we may also use the suid-bit and the effective user will be bind$ sudo chmod u+s /usr/sbin/namendWith named we also may populate the group bind by user, who are allowed to start named.$$ ls -l /usr/sbin/named-rwsr--r-- 1 bind bind 338920 Apr 14 00:07 /usr/sbin/named*$ /usr/sbin/namedbash: /usr/sbin/named: Permission denied$ iduid=1000(chris) gid=100(users) groups=100(users)$$ sudo usermod -a -G bind chris$ sudo chmod g+x /usr/sbin/named $ ls -l /usr/sbin/named-rwsr-xr-- 1 bind bind 338920 2008-04-14 00:07 /usr/sbin/named$$ sudo su - chris$ iduid=1000(chris) gid=100(users) groups=62(bind),100(users)$ /usr/sbin/named$ ps -o cmd,pid,ppid,stime,time,euser,ruser -H f -U bind -u bindCMD PID PPID STIME TIME EUSER RUSER/usr/sbin/named 19354 1 14:09 00:00:00 bind chris$The pcaps4server tool also covers bind/named.top  Examples - Server running as a distinct unprivileged user - CupsdReducing the privilege level of the common unix printing system daemon follows the same principle. We create a special user and group which we will call cupsd. We will adjust the ownership of files and directories. And we will grant the needed privileges as PCaps.We create the user cupsd and the group cupsd$$ sudo groupadd cupsd$ sudo useradd -g cupsd -d / cupsd$We make sure, that cupsd will stay with his uid and gid.$ sudo sed -i -e "{s|^\(User\).*|\1 cupsd|; s|^\(Group\) .*|\1 cupsd|}" /etc/cups/cupsd.confWe change the ownership to cupsd:cupsd of various directories and its content$$ sudo chown -R cupsd:cupsd /etc/cups$ sudo chown -R cupsd:cupsd /var/cache/cups$ sudo chown -R cupsd:cupsd /var/log/cups$ sudo chown -R cupsd:cupsd /var/run/cups$ sudo chown -R cupsd:cupsd /var/spool/cups$To ensure, that only the file owner bind or root may start the cupsd binary, we change the permissions and ownership$$ ls -l /usr/sbin/cupsd-rwxr-xr-x 1 root root 296800 Apr 30 14:37 /usr/sbin/cupsd*$ sudo chown cupsd:cupsd /usr/sbin/cupsd$ sudo chmod g-x,o-x /usr/sbin/cupsd$ ls -l /usr/sbin/cupsd-rwxr--r-- 1 cupsd cupsd 296800 Apr 30 14:37 /usr/sbin/cupsd$So all cupsd needs is the privilege to open and bind to privileged ports$ sudo setcap cap_net_bind_service=ep /usr/sbin/cupsdTo prevent messing up ownership and an excessive privilege level root, shall start the cupsd daemon like$ su -c /usr/sbin/cupsd cupsdIf allowed by the sudo configuration, an unprivileged user may start cupsd by$ sudo -u cupsd /usr/sbin/cupsdInstead of specifying the user we may also use the suid-bit and the effective user will be cupsd$ sudo chmod u+s /usr/sbin/cupsdTo allow unprivileged user the execution of cupsd they might be added to the group cupsd. We adapt the file system configuration of cupsd to ensure, that the effective user will be cupsd.$$ ls -l /usr/sbin/cupsd-rwsr--r-- 1 cupsd cupsd 296800 Apr 30 14:37 /usr/sbin/cupsd*$ /usr/sbin/cupsdbash: /usr/sbin/cupsd: Permission denied$ iduid=1000(chris) gid=100(users) groups=100(users)$$ sudo usermod -a -G cupsd chris$ sudo chmod g+x /usr/sbin/cupsd$ ls -l /usr/sbin/cupsd-rwsr-xr-- 1 cupsd cupsd 296800 Apr 30 14:37 /usr/sbin/cupsd*$$ sudo su - chris$ iduid=1000(chris) gid=100(users) groups=64(cupsd),100(users)$ /usr/sbin/cupsd$ ps -o cmd,pid,ppid,stime,time,euser,ruser -H f -U cupsd -u cupsdCMD PID PPID STIME TIME EUSER RUSER/usr/sbin/cupsd 14346 1 15:46 00:00:00 cupsd chris$I provide the conversion tool pcaps4server to do conversion and reversion for the cupsd daemon to PCaps and back.top  Examples - Server running as a distinct unprivileged user - DHCPDWe are changing the set up and configuration of the Dynamic Host Configuration Protocol Server to run with the just needed privileges. The Dynamic Host Configuration Protocol allows hosts on a TCP/IP network to request and be assigned IP addresses, and also to discover information about the network to which they are attached.DHCPD requires CAP_NET_BIND_SERVICE and CAP_NET_RAW as PCaps. As the DHCPD is not PCaps aware, we provide legacy support by assigning the needed PCaps beside the Permitted (p) Flag also the Effective (e) Flag. The private user and group will be called dhcpd.We create the user dhcpd and the group dhcpd$$ sudo groupadd dhcpd$ sudo useradd -g dhcpd -d / dhcpd$To be able to write his pid file, we create a private directory, which will be owned by dhcpd:dhcpd$ sudo mkdir /var/run/dhcpdWe adjust the config file accordingly to use the new pid directory$ sudo sed -i 's|^\(pid-file-name\).*|\1 "/var/run/dhcpd/dhcpd.pid"|' /etc/dhcpd.confWe change ownership to dhcpd:dhcpd of various files, directories and its content$$ sudo chown dhcpd:dhcpd /etc/dhcpd.conf$ sudo chown dhcpd:dhcpd /var/run/dhcpd$ sudo chown -R dhcpd:dhcpd /var/state/dhcp/$The dhcpd binary shall only be executable by the file owner dhcpd or root. We change the permissions and ownership accordingly.$$ ls -l /usr/sbin/dhcpd-rwxr-xr-x 1 dhcpd dhcpd 507648 Apr 9 04:16 /usr/sbin/dhcpd*$ sudo chown dhcpd:dhcpd /usr/sbin/dhcpd$ sudo chmod g-x,o-x /usr/sbin/dhcpdchris@apollo ~ $ ls -l /usr/sbin/dhcpd-rwxr--r-- 1 dhcpd dhcpd 507648 Apr 9 04:16 /usr/sbin/dhcpd*$We grant the needed PCaps to the dhcpd binarysudo setcap cap_net_bind_service,cap_net_raw=ep /usr/sbin/dhcpdWhen started out of the context of root, as in start scripts, dhcpd shall be called to prevent messing up of file ownership and an excessive privilege level by$ su -c /usr/sbin/dhcpd dhcpdIf the system security policy and therefore the sudo configuration allows it, an unprivileged user may start the dhcpd daemon by typing$ sudo -u dhcpd /usr/sbin/dhcpdBy using the suid-bit, the user doesn't have to be specified. The effective user will change to the file owner.$ sudo chmod u+s /usr/sbin/dhcpdBy using the technique of group membership and the right to execute the binary for group members and the suid-bit technique, these group members may also execute dhcpd$$$ ls -l /usr/sbin/dhcpd-rwsr--r-- 1 dhcpd dhcpd 507648 Apr 9 04:16 /usr/sbin/dhcpd*$ /usr/sbin/dhcpdbash: /usr/sbin/dhcpd: Permission denied$ iduid=1000(chris) gid=100(users) groups=100(users)$$ sudo usermod -a -G dhcpd chris$ sudo chmod g+x /usr/sbin/dhcpd$ ls -l /usr/sbin/dhcpd-rwsr-xr-- 1 dhcpd dhcpd 507648 Apr 9 04:16 /usr/sbin/dhcpd*$$ sudo su - chris$ iduid=1000(chris) gid=100(users) groups=63(dhcpd),100(users)$ /usr/sbin/dhcpdInternet Systems Consortium DHCP Server V3.0.6Copyright 2004-2007 Internet Systems Consortium.All rights reserved.For info, please visit http://www.isc.org/sw/dhcp/Wrote 25 leases to leases file.Listening on LPF/eth1/00:0b:5d:29:73:3b/192.168.4/24Sending on LPF/eth1/00:0b:5d:29:73:3b/192.168.4/24Sending on Socket/fallback/fallback-net$$ ps -o cmd,pid,ppid,stime,time,euser,ruser -H f -U dhcpd -u dhcpdCMD PID PPID STIME TIME EUSER RUSER/usr/sbin/dhcpd 32674 1 09:59 00:00:00 dhcpd chris$The pcaps4server tool also covers dhcpd.top  Examples - Server running as a distinct unprivileged user - SAMBAWe will following here also the principle of least privilege to reduce the amount of privileges of the SMB/CIFS fileserver SAMBA.Of the SAMBA package SMBD requires CAP_NET_BIND_SERVICE, CAP_SYS_RESOURCE and CAP_DAC_OVERRIDE as PCaps. NMBD just requires CAP_NET_BIND_SERVICE. Here we provide also legacy support, because we grant beside the Permitted (p) Flag also the Effective (e) Flag to the PCaps. The user and private group will be called samba.We start by creating the privat group samba and the user samba, whose primary and only group is samba$$ sudo groupadd samba$ sudo useradd -g samba -d / samba$To be able to write his pid files, we create a private directory, which will be owned his user:group$ sudo mkdir /var/run/sambaWe adjust the configuration file accordingly to use the new pid directory$ sudo sed -i 's|\(pid directory =\).*|\1 "/var/run/samba"|' /etc/samba/smb.confTo be able to write his log file, we create a private directory, which will be owned his user:group$ sudo mkdir /var/log/sambaWe adjust the config file accordingly to use the new log directory. Adjust it to your log scheme like for example /var/log/samba/samba.%m .$ sudo sed -i 's|\(log file =\).*|\1 "/var/log/samba/samba.log"|' /etc/samba/smb.confWe adjust the ownership of various directories and file, which are belonging to SAMBA$$ sudo chown -R samba:samba /etc/samba$ sudo chown -R samba:samba /var/cache/samba$ sudo chown -R samba:samba /var/log/samba$ sudo chown -R samba:samba /var/run/samba$Only the file owner samba shall be allowed to start the daemon smbd and nmbd. We change the mode bits and ownership.$$ ls -l /usr/sbin/nmbd /usr/sbin/smbd-rwxr-xr-x 1 root root 1021704 Mar 15 21:52 /usr/sbin/nmbd*-rwxr-xr-x 1 root root 3677972 Mar 15 21:52 /usr/sbin/smbd*$ sudo chown samba:samba /usr/sbin/nmbd /usr/sbin/smbd$ sudo chmod g-x,o-x /usr/sbin/nmbd /usr/sbin/smbd$ ls -l /usr/sbin/nmbd /usr/sbin/smbd-rwxr--r-- 1 samba samba 1021704 Mar 15 21:52 /usr/sbin/nmbd*-rwxr--r-- 1 samba samba 3677972 Mar 15 21:52 /usr/sbin/smbd*$We grant the needed privileges as PCaps to the Permitted and Effective Set$$ sudo setcap cap_net_bind_service=ep /usr/sbin/nmbd$ sudo setcap cap_net_bind_service,cap_sys_resource,cap_dac_override=ep /usr/sbin/smbd$Out of a root context the daemons should be started as$$su -c /usr/sbin/nmbd samba$su -c /usr/sbin/smbd samba$Per sudo, if the configuration allows it, an unprivileged user might start it by using$$ sudo -u samba /usr/sbin/nmbd$ sudo -u samba /usr/sbin/smbd$By using the suid-bit technique we ensure that the effective user will be the file owner without specifying this user$ sudo chmod u+s /usr/sbin/nmbd /usr/sbin/smbdIf we want other users to allow the SAMBA daemons, they might be added to the samba group, which will also granted the execute bit. With the suid-bit we assure that the effective user will still be samba.$$ ls -l /usr/sbin/nmbd /usr/sbin/smbd-rwsr--r-- 1 samba samba 1021704 Mar 15 21:52 /usr/sbin/nmbd*-rwsr--r-- 1 samba samba 3677972 Mar 15 21:52 /usr/sbin/smbd*$ /usr/sbin/nmbd; /usr/sbin/smbdbash: /usr/sbin/nmbd: Permission deniedbash: /usr/sbin/smbd: Permission denied$ iduid=1000(chris) gid=100(users) groups=100(users)$$ sudo usermod -a -G samba chris$ sudo chmod g+x /usr/sbin/nmbd /usr/sbin/smbd$ ls -l /usr/sbin/nmbd /usr/sbin/smbd-rwxr-xr-- 1 samba samba 1021704 Mar 15 21:52 /usr/sbin/nmbd*-rwxr-xr-- 1 samba samba 3677972 Mar 15 21:52 /usr/sbin/smbd*$$ sudo su - chris$ iduid=1000(chris) gid=100(users) groups=61(samba),100(users)$ /usr/sbin/nmbd; /usr/sbin/smbd$$ /usr/sbin/nmbd; /usr/sbin/smbdchris@apollo ~ $ ps -o cmd,pid,ppid,stime,time,euser,ruser -H f -U samba -u sambaCMD PID PPID STIME TIME EUSER RUSER/usr/sbin/smbd 786 1 13:23 00:00:00 samba samba \_ /usr/sbin/smbd 787 786 13:23 00:00:00 samba samba/usr/sbin/nmbd 783 1 13:23 00:00:00 samba chris \_ /usr/sbin/nmbd 784 783 13:23 00:00:00 samba chris$The pcaps4server tool also covers SAMBA.top  Examples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - IntroPOSIX Capability Inheritance allows to control who might successful execute a binary, when this binary needs for successful execution a privilege level above of an unprivileged user. Only when both the calling process - and a logged in user is system intern a process - and the called binary have the - for successful execution necessary - PCaps in their Inheritance Set, this PCaps will get the Permitted (p) Flag for the resulting process.Up to here all examples were using the Permitted (p) and Effective (e) Flag. Permitted Flag signifies "you can use it - it is in your toolbox". Effective Flag says "you are using it - you have taken it out of your toolbox, it is in your hand". The Permitted (P) Set, the sum of all PCaps with the Permitted (p) Flag is also called the Minimal Forced Set. Independent of the calling process, the resulting process will have the PCaps of the File Permitted Set in his Process Permitted Set (limited by the System Upper Limit X /proc/sys/kernel/cap-bound or since 2.6.25 by the Inherited Per-Process Upper Limit X). The Effective Flag is only granted to binaries, who are not capable to populate their Effective Set on their own. Not PCaps aware applications are seen as legacy applications and their support through the use of the File Effective Set is called legacy support. So the use of the Effective Flag is actually legacy support.The Inheritance (i) Flag stays in contrast to the Permitted (p) Flag. Instead of granting the needed PCap the Permitted (p) Flag we might grant the Inheritance (i) Flag.To illustrate this, we use our beloved ping. Instead running in the context of root as suid-0, and so be able to load modules, change the system time and delete everyones file, we changed the file configuration by eliminating the suid-0 and by granting the needed PCap CAP_NET_RAW the Permitted (p) Flag. Because ping is PCaps unaware we also granted CAP_NET_RAW the Effective (e) Flag.Just for repetition - the whole story$$ ls -l /bin/ping-rws--x--x 1 root root 28992 2007-05-09 19:59 /bin/ping*$ ping -c 1 localhostPING localhost (127.0.0.1) 56(84) bytes of data.64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.108 ms--- localhost ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.108/0.108/0.108/0.000 ms$$ sudo chmod u-s /bin/ping$ ls -l /bin/ping-rwx--x--x 1 root root 28992 2007-05-09 19:59 /bin/ping*$ ping -c 1 localhostping: icmp open socket: Operation not permitted$$ sudo setcap cap_net_raw=ep /bin/ping$ getcap /bin/ping/bin/ping = cap_net_raw+ep$ ping -c 1 localhostPING localhost (127.0.0.1) 56(84) bytes of data.64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.120 ms--- localhost ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.120/0.120/0.120/0.000 ms$Now we have a binary which might be successfully executed by everyone (as before with the suid-0 but with less privilege - but that's not the point here).But for example our security policy might say, only certain users are allowed to execute applications with the privilege level of the PCap CAP_NET_RAW. These application in question needs for successful execution the CAP_NET_RAW PCap. We grant for the user and for the application this PCap CAP_NET_RAW a special flag, the Inheritable (i) Flag. For the calling process, here the logged in user, having a PCap in his Inheritable Set (pI) means to say, "I have a PCap (in my Inheritable Set), that may go into your Permitted Set (pP'), if you are allowed to receive it". For the called application, having a PCap in his Inheritable Set (fI) is like stating, "I have a PCap (in my Inheritable Set), that may go into my Process Permitted Set (pP') if you, who executes me, have the same PCap in your Process Inheritable Set (pI)". So caller and callee, both of them, have to have the PCap in question in their Inheritable Set, for this PCap to be in the Process Permitted Set (pP') of the new process.We change the PCap configuration of ping, to expect be called by a process, who is allowed to execute an application with this PCap.$$ ls -l /bin/ping-rwx--x--x 1 root root 28992 2007-05-09 19:59 /bin/ping$ getcap /bin/ping/bin/ping = cap_net_raw+ep$ sudo setcap cap_net_raw=ei /bin/ping$ getcap /bin/ping/bin/ping = cap_net_raw+ei$Now we check the PCaps of our logged in session with getpcaps, its as expected empty$$ /sbin/getpcaps $$Capabilities for `2545': =$And executing ping fails$$ ping -c 1 localhostping: icmp open socket: Operation not permitted$Now with a proper configured pam based log in process, our logged in process gains the necessary PCap in his Inheritable Set$$ grep chris /etc/security/capability.conf13 chris$$ su - chrisPassword:$$ getpcaps $$Capabilities for `3610': = cap_net_raw+i$$ ping -c 1 localhostPING localhost (127.0.0.1) 56(84) bytes of data.64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.123 ms--- localhost ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.123/0.123/0.123/0.000 ms$Looking at the appropriate line of the Capability Rules, we see how the Process Permitted Set (pP') of the new process is influenced by the Inheritable Sets. The Intersection of the Caller Process Inheritable Set (pI) and the Called File Inheritable Set (fI) populate (also) the new Process Permitted Set (pP').2) pP' = (X & fP) | (pI & fI)So instead of just granting the needed PCap the Permitted Flag and so allow every process (and user) to execute this application successful, we can create a link between a process/user and an application through the Inheritable Set. Only matching PCaps will go into the Permitted Set of the new process and only by this the application will be executed successful.top  Examples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - Installing the bitsTo be able to use PCaps, we have had already to install the libcap package. This package also installs since version 2.09 the needed PAM Module pam_cap.so into /lib/security and comes with an example configuration file capability.conf, which has to go into /etc/security.$$ tar xjf libcap-2.09$ cd libcap-2.09$ make$ sudo make install$ sudo mkdir /etc/security$ sudo cp pam_cap/capability.conf /etc/security$ cd progs$ ./quicktest$The configuration file /etc/security/capability.conf tells the pam_cap.so PAM Module which PCaps a user may get in his Process Inheritable Set.You may name the PCaps by their name or by their number. Just have a look at /usr/include/linux/capability.h .Example of capability.h for the ping exercise$$ cat /etc/security/capability.conf## /etc/security/capability.conf## this is a sample capability file (to be used in conjunction with# the pam_cap.so module)## In order to use this module, it must have been linked with libcap# and thus you'll know about Linux's capability support.# [If you don't know about libcap, the sources for it are here:## http://linux.kernel.org/pub/linux/libs/security/linux-privs/## .]## Here are some sample lines (remove the preceding '#' if you want to# use them## user 'morgan' gets the CAP_SETFCAP inheritable capability#cap_setfcap morgan## user 'luser' just inherits two capabilities (CAP_NET_RAW and CAP_FOWNER)# cap_net_raw,cap_fowner luser13 chris## 'everyone else' gets no inheritable capabilitiesnone *## if there is no '*' entry, all users not explicitly mentioned will## get all available capabilities. This is a permissive default, and## probably not what you want...$Naturally you must have a PAM based authentication process. The PAM configuration files are in /etc/pam.d.If you like to get the Inheritable Set populated through the login process, your login file may look like$$ cat /etc/pam.d/login#%PAM-1.0auth required pam_securetty.soauth include system-authauth required pam_cap.soaccount required pam_nologin.soaccount include system-authpassword include system-authsession include system-authsession required pam_loginuid.so$top  Examples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - Exploring InheritanceSo if and only if /etc/pam.d/login contains the call of the pam_cap.so PAM Module, we may see the following in exploring the effect of Inheritance.If we log in as user chris, we will got the CAP_NET_RAW PCap in our Inheritance Set. If we simulate a log in from this shell, the Inheritable Set will go unchanged over to the new process. If we log in per SSH from this shell, we have a new subprocess from init and hence /etc/pam.d/sshd contains no reference to pam_cap, the user will have no PCaps in his Inheritance Set. A simulated log in from here per su leaves obviously the Inheritable Set empty because /etc/pam.d/su also contains no reference to pam_cap.$Welcome to Linux 2.6.25-a (tty2)apollo login: chrisPassword:$ getpcaps $$Capabilities for `32168': = cap_net_raw+i$ su - chrisPassword:$ getpcaps $$Capabilities for `32183': = cap_net_raw+i$$ ssh apolloLast login: Mon May 5 14:36:55 2008 from apollo.friedhoff.locHave a nice Day ....$ getpcaps $$Capabilities for `32230': =$ su - chrisPassword:$ getpcaps $$Capabilities for `32245': =$$ pstree -upinit(1)-+-acpid(2422) |-agetty(2441) |-agetty(2443) |-agetty(2445) |-agetty(2447) |-crond(2417) |-dbus-daemon(2403,messagebus) |-gpm(32142) |-inetd(2390) |-klogd(2160) |-login(2437)---bash(2461,chris)---vim(32197) |-login(31451)---bash(32168,chris)---su(32182)---bash(32183)---ssh(32222) |-sleepd(2435) |-smartd(2414) |-spamd(2429)---spamd(333) |-sshd(2394)---sshd(32223)---sshd(32228,chris)---bash(32230)---su(32244)---bash(32245)---pstree(32261) |-syslogd(2158) |-udevd(1053) `-wpa_supplicant(2178)$$ getpcaps 31451 32168 32182 32183 32222 2394 32223 32228 32230 32244 32245Capabilities for `31451': =ep cap_net_raw+iCapabilities for `32168': = cap_net_raw+iCapabilities for `32182': = cap_net_raw+iCapabilities for `32183': = cap_net_raw+iCapabilities for `32222': = cap_net_raw+iCapabilities for `2394': =epCapabilities for `32223': =epCapabilities for `32228': =Capabilities for `32230': =Capabilities for `32244': =Capabilities for `32245': =A process running in the context of root is kernel intern a process, whose all available PCaps are having the Effective (e) and Permitted (p) Flag. Root has the complete Effective and Permitted Set. The root runned login process 31451 has beside beside the fully equiped EP-Sets also the PCap CAP_NET_RAW with the Inheritable (i) Flag. This Inheritable Set goes unchanged over to the chris owned bash session 32168. According to the Inheritance part of the Capability Rule, this Inheritable Set goes unchanged over from 32168 -> 32182 -> 32183 to finally 32222. Because the configuration of /etc/pam.d/sshd does not populate the Inheritance Set, all the subsequence processes have also an empty Inheritance Set.top  Examples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - SUID-BIT 0 reloadedIn the process of substituting the suid-bit-0 configuration with PCaps, we just reduced the amount of privilege these former suid-0 applications are now executed with. We granted the Permitted (p) Flag - Forced Flag - so for every calling process we ensured, that the resulting process will have the needed PCaps available. Due to legacy support, we also granted the Effective (e) Flag.Now we look again at these applications and their needed PCapsping - CAP_NET_RAW (13)traceroute - CAP_NET_RAW (13)chsh - CAP_CHOWN (0), CAP_DAC_READ_SEARCH (2), CAP_FSETID (4), CAP_SETUID (7)chfn - CAP_CHOWN (0), CAP_DAC_READ_SEARCH (2), CAP_FSETID (4), CAP_SETUID (7)chage - CAP_DAC_READ_SEARCH (2)passwd - CAP_CHOWN (0), CAP_DAC_OVERRIDE (1), CAP_FOWNER (3)unix_chkpwd - CAP_DAC_OVERRIDE (1)We will change the configuration from the Permitted Set toward the Inheritable Set$$ sudo setcap 13=ei /bin/ping$ sudo setcap 13=ei /usr/bin/traceroute$ sudo setcap 0,2,4,7=ei /ust/bin/chsh$ sudo setcap 0,2,4,7=ei /usr/bin/chfn$ sudo setcap 2=ei /usr/bin/chage$ sudo setcap 0,1,3=ei /usr/bin/passwd$ sudo setcap 1=ei= /sbin/unix_chkpwd$We will grant user chris these PCaps into his Inheritable Set by changing /etc/security/capability.conf$sudo sed -i 's|.*\(chris\)|0,1,2,3,4,7,13 \1|' /etc/security/capability.confand check the configuration, that chris receives an Inheritable Set and anyone else has an empty Inheritable Set (none clause)$$ egrep -v "(#|^$)" /etc/security/capability.conf0,1,2,3,4,7,13 chrisnone *$Now we have a configuration, where luser want be able anymore to execute the former suid-bit-0 applications. He is now even less powerful than before. With his Inheritable Set and the applications having also an Inheritable Set, chris is still able to execute these former suid-bit-0 applications.top  Examples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - ConvenienceTo show what is possible, as a proof of concept, I was showing in the past, how to raise the convenience by granting several applications the PCaps to execute successful. But contrary to the former suid-0 applications, these applications where formerly not accessible by the unprivileged user. So the net effect was, that suddenly other unprivileged user might come into the position to do things, they were not allowed before.So, do your risk analysis and weight up between convenience and a possible security problem before following the examples - you have been warned.In fact the multi user system Linux is very often used as a single user system and this user also performs some administration tasks. Some applications need only one or a few privileges to execute successful. Through the usage of the technique of Inheritance Sets, we can grant the elected user and the elected applications the needed PCaps in their Inheritance Set, so we can execute these applications without the need of 'sudo' or 'su -c'.For the following applications I have detected the needed PCapseject = CAP_DAC_READ_SEARCH (2), CAP_SYS_RAWIO (17)ifconfig = CAP_NET_ADMIN (12)killall = CAP_KILL (5)modprobe = CAP_SYS_MODulE (16)ntpdate = CAP_NET_BIND (10), CAP_SYS_TIME (25)qemu = CAP_NET_ADMIN (12)route = CAP_NET_ADMIN (12)Again, we configure the needed PCaps for the applications$setcap 2,17=ei /usr/bin/ejectsetcap 12=ei /sbin/ifconfigsetcap 5=ei /bin/killallsetcap 16=ei /sbin/modprobesetcap 10,25=ei /usr/sbin/ntpdatesetcap 12=ei /usr/bin/qemusetcap 12=ei /sbin/route$We will grant user chris also these PCaps into his Inheritable Set by changing /etc/security/capability.conf$sudo sed -i 's|.*\(chris\)|0,1,2,3,4,5,7,10,12,13,16,17 \1|' /etc/security/capability.confand check the configuration, that chris receives an Inheritable Set and anyone else has an empty Inheritable Set (none clause)$$ egrep -v "(#|^$)" /etc/security/capability.conf0,1,2,3,4,5,7,10,12,13,16,17 chrisnone *$Here we reached a point, where we are able to provide users with a privilege level below than with suid-0 applications to as far as being able to do some administration task. I believe, that system user - user accounts without real persons behind them - are examples to refuse the ability to - lets say - change account data like passwords and login shells or edit the crontab or do mount and umount operations. On the other hand, a trusted user, who regularly performs administration tasks might be granted some privileges in combination with the appropriate application to perform necessary tasks, without executing them with the privilege level of root trough 'sudo' or 'su -c'.top  Examples - Types of usage of POSIX Capabilities - Different privilege levels for different user rolls - Different Administration RollsA nice example is the roll of a back-up administrator. By using the tool - for example tar - the backup process needs privileges above the level of an unprivileged user. We will grant this back-up administrator the privilege of reading root owned system files and files of other user by granting him CAP_READ_SEARCH in his Process Inheritance Set. The back-up tool tar on the other hand will also have these PCaps in his File Inheritance Set. Only a user and here our back-up administrator with the matching PCaps in his Process Inheritance Set will by executing tar populating the Process Permitted Set of this tar process with the privilege to read these files.A network roll is an other imaginable position. Granting this user and the adequate applications the needed privileges as PCaps with the Inheritable Flag allows only him to execute these applications with the necessary privileges.Further rolls might be something like a user account administrator or a reboot administrator. 


★★★★★★★★★★★★★★★

http://www.friedhoff.org/posixfilecaps.html

★★★★★★★★★★

Restricting root with per-process securebits

By Jake EdgeApril 30, 2008Linux capabilities have had a long and somewhat tortuous journey as part of the Linux kernel. Slowly—and very carefully—functionality is being added to this security feature to get it to a point where it is a viable alternative to the all-or-nothing setuid(0) model. A recently merged patchadds a per-process securebits feature that will allow capabilities-based daemons or subsystems to coexist with existing setuid utilities.Linux capabilities break up the privileged tasks normally associated with root (i.e. uid 0) into finer-grained abilities which can be individually granted or revoked for specific processes. The idea is to change the standard Unix model that root has all special privileges while all other users have none. The terminology is always a bit contentious, though, as Linux capabilities are derived from a POSIX proposal that was never adopted, but shares the name "capabilities" with an entirely different approach; this article is only concerned with capabilities of the Linux variety.There has long been interest in creating a Linux system that did not rely upon a single root account. Capabilities are seen as the way to get there, but they have suffered from a bit of a chicken-and-egg problem. With the recent work to add file-based capabilitiesand restore CAP_SETPCAP to its original meaning, a true capabilities-based system is becoming possible. In the patch, which has been merged for 2.6.26, Andrew Morgan describes the new functionality:The feature added by this patch can be leveraged to suppress the privilege associated with (set)uid-0. This suppression requires CAP_SETPCAP to initiate, and only immediately affects the 'current' process (it is inherited through fork()/exec()). This reimplementation differs significantly from the historical support for securebits which was system-wide, unwieldy and which has ultimately withered to a dead relic in the source of the modern kernel.The patch removes the global securebits variable, replacing it with an entry in struct task_struct, that can be manipulated by a process, but only for itself—and any children. Morgan envisions hybrid systems that have some utilities using capabilities to get their privileges along with some setuid(0) utilities. In that scenario, a capabilities-based utility or daemon may wish to limit what its children can do, even if they execute asetuid(0) binary. As part of the evolution, process trees can be created that cannot get root privileges.Processes which have the CAP_SETPCAP capability can change their securebits setting via the prctl() system call. There are three separate bits that govern the interaction of capabilities and setuid:SECURE_NOROOT – enabling this gives no special privileges to uid 0SECURE_NO_SETUID_FIXUP – setting this bit disables capability fixes when transitioning from or to uid 0 via setuid. This might be done for compatibility with older programs that use setuid to reduce their privileges.SECURE_KEEP_CAPS – when set, a process can retain its capabilities even when transitioning to a normal (not uid 0) user. This bit is cleared by exec().Each of these bits also has a companion *_LOCKED bit that, if set, will not allow any user program to alter the corresponding setting. As Morgan notes in the patch, a program that can set its capabilities (has CAP_SETPCAP) can drop all privileges for itself and any child process by doing: prctl(PR_SET_SECUREBITS, 0x2f); This is the equivalent of setting SECURE_NOROOT, SECURE_NO_ROOT_LOCKED, SECURE_NO_SETUID_FIXUP, SECURE_NO_SETUID_FIXUP_LOCKED, and SECURE_KEEP_CAPS_LOCKED.The memory of the sendmail-capabilities bug from 2000 makes some a bit queasy—or worse—about any patches that involve capabilities and setuid. Andrew Morton asks: "what was the bug which caused us to cripple capability inheritance back in the days of yore? (Some sendmail thing?)" That bug was caused because unprivileged users could take away the CAP_SETUID capability from setuid binaries like sendmail. When sendmail then used setuid to drop its privileges, it failed, but sendmail did not check, so it was still running with full privilege. This could be leveraged by a user to gain root privileges. It was a disconnect between capabilities and the longstanding behavior of Unix-like systems when dropping privileges.Morgan has written a detailed description of the sendmail-capabilities bug in response to Morton's questions. He makes it clear that he wants to move toward full capability support without breaking existing code:I'm basically interested in evolving the capability implementation back to the POSIX.1e model and making it whole - but most certainly *without crippling legacy superuser support in the process* .As folk get more comfortable with this full capability model. I believe we can delete more cruft from the main kernel, but even that clean up will leave a fully functional legacy model in place. I feel it should be for something like init, or one of its children to be able to run subsystems in capability-only or legacy modes.Morton seemed satisfied that his concerns had been addressed, but still wonders about the future for capabilities: "So how do we ever get to the stage where we can recommend that distributors turn these things on, and have them agree with us?" This was echoed by Ismail Dönmez, who was looking for concrete examples of how to use the per-process securebits feature. Morgan provides a pointer to some examples along with his belief that sometime soon the capabilities developers will become confident enough to recommend turning off the "experimental" flag for the SECURITY_FILE_CAPABILITIES kernel configuration. That flag governs both the file-based capabilities as well as the per-process securebits. In addition, Morgan says:More importantly I'm hopeful that in that time we'll have accumulated enough documentation and user-space experience and examples to convince others that this is, indeed, a viable feature to support in mainstream distributions.A developerWorks article on file-based capabilities by Serge Hallyn and a web page on POSIX capabilities by Chris Friedhoff were both mentioned in the thread as good references for the work being done to actually use capabilities in systems. Those pre-date the securebits work, so Dönmez was looking for use-cases for the new feature. Morgan replied that containers were one, deferring to Hallyn who has some ideas on using securebits:We tend to talk about 'system containers' versus 'application containers'. A system container would be like a vserver or openvz instance, something which looks like a separate machine. I was going to say I don't imagine per-process securebits being useful there, but actually since a system container doesn't need to do any hardware setup it actually might be a much easier start for a full SECURE_NOROOT distro than a real machine. Heck, on a real machine init and a few legacy [daemons] could run in the init namespace, while users log in and apache etc run in a SECURE_NOROOT container.But I especially like the thought of for instance postfix running in a carefully crafted application container (with its own virtual network card and limited file tree and no visibility of other processes) with SECURE_NOROOT on.Capabilities are an interesting, but complicated, security feature. For most of the ten years they have been part of the Linux kernel, they have either been broken, ignored, or both. With the latest work being done by Hallyn, Morgan, and others, capabilities are finally becoming a fully-working alternative to things like SELinux. It will be interesting to see if more user utilities will become capability-aware and whether distributions start using capabilities. Some day, root may just fade away.


============== Using GnuPG to digitally sign emails GNU Privacy Guard (GnuPG) is an open source version of the commercial Pretty Good Privacy (PGP) software for creating digital signatures. This weeks Tips and Tricks will cover the creation of a key, exporting your key to a public keyserver, and finally adding your digital signature to email. --------------------------------------------------------------------------- | Code Listing 7.1: | |Installing GnuPG | --------------------------------------------------------------------------- | | |# emerge gnupg | | | |//Create the .gnupg directory | |# mkdir $HOME/.gnupg | | | --------------------------------------------------------------------------- --------------------------------------------------------------------------- | Code Listing 7.2: | |Creating a new key | --------------------------------------------------------------------------- | | |# gpg --gen-key | |gpg (GnuPG) 1.2.1; Copyright (C) 2002 Free Software Foundation, Inc. | |This program comes with ABSOLUTELY NO WARRANTY. | |This is free software, and you are welcome to redistribute it | |under certain conditions. See the file COPYING for details. | | | |Please select what kind of key you want: | | (1) DSA and ElGamal (default) | | (2) DSA (sign only) | | (5) RSA (sign only) | |Your selection? 1 | | | |About to generate a new ELG-E keypair. | | minimum keysize is 768 bits | | default keysize is 1024 bits | | highest suggested keysize is 2048 bits | |What keysize do you want? (1024) 1024 | | | |Please specify how long the key should be valid. | | 0 = key does not expire | | <n> = key expires in n days | | <n>w = key expires in n weeks | | <n>m = key expires in n months | | <n>y = key expires in n years | |Key is valid for? (0) 0 | |Key does not expire at all | |Is this correct (y/n)? y | | | |You need a User-ID to identify your key; the software constructs the user| |id from Real Name, Comment and Email Address in this form: | | "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>" | | | |Real name: John Doe | |Email address: john.doe@example.com | |Comment: | | | |You selected this USER-ID: | | "John Doe <john.doe@example.com>" | | | |Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o | |You need a Passphrase to protect your secret key. | | | |//Make sure you pick a good password and DON'T FORGET IT | |Enter passphrase: secret | |Repeat passphrase: secret | | | |We need to generate a lot of random bytes. It is a good idea to perform | |some other action (type on the keyboard, move the mouse, utilize the | |disks) during the prime generation; this gives the random number | |generator a better chance to gain enough entropy. | | | |gpg: /home/johndoe/.gnupg/trustdb.gpg: trustdb created | |public and secret key created and signed. | |key marked as ultimately trusted. | | | |//The eight character string is your Key ID (in this case, A268D066) | |pub 1024D/A268D066 2003-01-17 John Doe <john.doe@example.com> | | Key fingerprint = D435 4979 610B 0BAB F107 64F8 FAF5 94E0 A268 D066| |sub 1024g/AB3B30AF 2003-01-17 | | | --------------------------------------------------------------------------- Now that your key has been made, it needs to be exported to a public keyserver. While this is not required, it's the easiest way for others to get your public key information and verify your information. To send your key, you'll first need to know your Key ID. --------------------------------------------------------------------------- | Code Listing 7.3: | |Finding your Key ID | --------------------------------------------------------------------------- | | |//Your Key ID is the eight character string after 1024D/ | |# gpg --list-keys | |/home/johndoe/.gnupg/pubring.gpg | |------------------------------- | |pub 1024D/A268D066 2003-01-17 John Doe <john.doe@example.com> | |sub 1024g/AB3B30AF 2003-01-17 | | | --------------------------------------------------------------------------- Now you can export your key. --------------------------------------------------------------------------- | Code Listing 7.4: | |Export your key to a public keyserver | --------------------------------------------------------------------------- | | |# gpg --send-keys --keyserver wwwkeys.pgp.net A268D066 | |gpg: success sending to `wwwkeys.pgp.net' (status=200) | | | --------------------------------------------------------------------------- Now that your key has been created and published, you can start using it to sign emails. You'll need to remember your Key ID for this step. If you don't remember it, see the above code listing (Finding your Key ID). Use the following steps to set up encryption in Evolution: * Click on Tools->Settings. * Select the Mail Accounts button and the account that will be using the key. * Click Edit and then the Security tab. Enter your Key ID in the field entitled PGP/GPG Key ID. * Click OK. Now when you compose a message, select Security->PGP Sign to add your digital signature to your email. To set up encryption in Mutt, add the following options to your $HOME/.muttrc file. --------------------------------------------------------------------------- | Code Listing 7.5: | |GPG settings in ~/.muttrc | --------------------------------------------------------------------------- | | | | |set pgp_decode_command="gpg %?p?--passphrase-fd 0? \ | | --no-verbose --batch --output - %f" | |set pgp_verify_command="gpg --no-verbose --batch --output \ | | - --verify %s %f" | |set pgp_decrypt_command="gpg --passphrase-fd 0 --no-verbose \ | | --batch --output - %f" | |set pgp_sign_command="gpg --no-verbose --batch --output \ | | - --passphrase-fd 0 --armor --detach-sign --textmode %?a?-u %a? %f" | |set pgp_clearsign_command="gpg --no-verbose --batch --output - \ | | --passphrase-fd 0 --armor --textmode --clearsign %?a?-u %a? %f" | | | |//Insert your Key ID after the --encrypt-to option prefixed by 0x | |set pgp_encrypt_only_command="gpg --batch --quiet --no-verbose \ | | --output - --encrypt --textmode --armor --always-trust \ | | --encrypt-to 0x<your key ID> -- -r %r -- %f" | |set pgp_encrypt_sign_command="gpg --passphrase-fd 0 --batch --quiet \ | | --no-verbose --textmode --output - --encrypt --sign %?a?-u %a? \ | | --armor --always-trust --encrypt-to 0x<your key ID> -- -r %r -- %f" | |set pgp_import_command="gpg --no-verbose --import -v %f" | |set pgp_export_command="gpg --no-verbose --export --armor %r" | |set pgp_verify_key_command="gpg --no-verbose --batch --fingerprint \ | | --check-sigs %r" | |set pgp_list_pubring_co
mmand="gpg --no-verbose --batch --with-colons \ | | --list-keys %r" | |set pgp_list_secring_command="gpg --no-verbose --batch --with-colons | | --list-secret-keys %r" | |set pgp_autosign=yes | |set pgp_sign_as=0x<your key ID> | |set pgp_replyencrypt=yes | |set pgp_timeout=1800 | |set pgp_good_sign="^gpg: Good signature from" | | | --------------------------------------------------------------------------- When you compose a message, press p to sign or encrypt. To only sign your email, select s. Then you can send your message and it will be signed with your digital signature. The above tips will help you get up and running with gpg, but it is not by any means a complete guide. You should also read GnuPG's excellent documentation[55] section to learn more about important concepts like key revocation, key signing and webs of trust. 55. http://www.gnupg.org/(en)/documentation/index.html ========================== 8. Moves, Adds and Changes ========================== Moves --

1 comment:


  1. http://www.iss.net/


    Locate the following registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystemsOn the Registry menu, click Save Key.In the File name box, type subsystems_key, and then click Save Key.NOTE: If you later have to restore this registry key, open Regedt32.exe, click the SubSystems key, and then click Restore on the Registry menu. Locate the file that you just saved, click it, click Open, and then click Yes.In the right pane of the Registry Editor window, double-click the Optional:REG_MULTI_SZ:Os2 Posix... line.The Multi-String Editor opens.Press the DELETE key to delete all the data in this window.Click OK.OS/2 POSIX no longer appears next to Optional: REG_MULTI_SZ in the right pane of the Registry Editor window.Quit Registry Editor.Restart the computer.NOTE: You do not have to remove the OS2 or POSIX specific system files or delete other OS2 or POSIX specific registry keys values.



    ReplyDelete