[The following is a guest diary by Paul Bolton. An earlier version of this diary appeared on Paulsblog.]


As an infrastructure engineer (3rd line support) with a healthy interest in security I like to discover and play with the less well known features of technology. It is surprising how many people are not aware of these, even some senior administrators, yet such features can offer both strong mechanisms to improve the security of a system and strong mechanism for a more nefarious individual to compromise or otherwise abuse that system.

One of these are Linux Capabilities, which can be thought of a division of roots capabilities into discrete parts, such as the ability to open a privileged port or bypass discretionary access controls. This allows for a more fine-grained approach to security. Rather than a user or process having root privileges or not, they can have a subset.
If the process is capabilities aware, then rather than the traditional become_root and unbecome_root functions that a SUID root process may use to protect itself, it can enable/disable the specific bits it needs. For example, if you only want to open a privileged port, you dont need to enable the ability to read/write any file.
By limiting the privileges (capabilities) a process or file has to a subsetof root/superuser, we limit both accidental damage caused by a bug or usererror, and malicious damage caused by an adversary abusing the process orfile. For example, in the case of a common action for a server of opening aprivileged port, if an adversary was able to execute arbitrary code due to abuffer overrun in the process, then the only privileged action that theadversary could perform without further abuse would be to open a privilegedport. In contrast, under the traditional approach of running the process asroot, the adversary would have full administrative access. i.e. we have theopportunity for a more effective least-privileged security model via theuse of Capabilities.
Solaris has something similar - Privileges - but here Im going to concentrate on the Linux variant.

Processes and files can have a number of capability sets. These are bitmasks of the discrete capabilities. Of particular interest are:

Permitted - this is the set of capabilities that the process or file can assume
Effective - this is the set of capabilities that the process or file has
Inheritable - this is the set of capabilities that are preserved across an exec or fork e.g. that can be passed on to a sub-process.

The possible configurations are quite extensive, so reading the man page is encouraged. But let ping. On older distributions this was SUID root to allow it to open raw sockets. However, on CentOS 7.1 for example, it isnt. Instead we now use capabilities:
">-rwxr-xr-x. 1 root root 44896 Jun 23">/bin/ping = cap_net_admin,cap_net_raw+p
In addition to getcap">[[email protected] ~]# grep ^Cap /proc/$$/status
CapInh: 0000000000000000
CapPrm: 0000001fffffffff
CapEff: 0000001fffffffff
CapBnd: 0000001fffffffff

Or getpcaps">[[email protected] ~]# getpcaps $$
Capabilities for `3506: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,35,36+ep

However, as you probably noticed when we listed the ping executable, other than the colour (if use are using ls with colours set), there are no obvious signs that it is a privileged file. Indeed, the traditional find for SUID/SGID files won">[[email protected] mnt]# cp -p /bin/bash /mnt/myBash
[[email protected] mnt]# setcap all+epi /mnt/myBash
[[email protected] mnt]# getcap /mnt/myBash">[[email protected] ~]$ /mnt/myBash
[[email protected] ~]$ wc -l /etc/shadow
wc: /etc/shadow: Permission denied

That is because the processes initial inheritable set (the non-privileged user) is empty and on an exec it is and">CapInh:">CapPrm:">CapEff:">CapBnd:">[[email protected] ~]$ wc -l ">[[email protected] mnt]# setcap all+epi /mnt/mySetpriv">[[email protected] mnt]# getcap /mnt/mySetpriv">UID PID PPID C STIME TTY">root 3693 3455 0 09:17 pts/0 00:00:00 /bin/bash

Instead, let">[[email protected] ~]$ /mnt/mySetpriv --inh-caps +all /mnt/myBash">wc: /etc/shadow: Permission denied

Well that didn just limited to your imagination. e.g. short one-off commands via mySetperm will probably get missed by an admin running ps.

rtunately, one good countermeasure is that setting a filesystem as nosuid also disables files from taking on capabilities. But if an adversary is using it to maintain access, then any writable suid permitted filesystem will do.

The key is that find SUID wont work, you need to be looking for these privileged files as well.

Finally, if you are looking at assigning users restricted capabilities, you may find pam_setcap of interest.

Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Internet Storm Center Infocon Status