In earlier times, the standard security model for GNU/Linux and Unix operating systems gave general users a minimal set of privileges, while granting full privileges to a single user account, i.e. root, that was used to administer the system and users, install software, mount and unmount filesystems, loading kernel modules, bind a process to a privileged port and run many services.
This dependence upon the root account to perform all actions requiring privilege was recognized to be somewhat dangerous in that it was all or nothing and not suited to compartmentalization of roles. Furthermore, it increased the risk of vulnerabilities within a setuid application which may only require root privileges for a very small fraction of its activity such as opening a system file or binding to a privileged port.
This risk was well understood within the open systems community. As a result, IEEE Std.1003.1e (aka POSIX.1e or POSIX.6) was a major effect started in 1995 to develop a standardized set of security interfaces for conforming systems which included access control lists (ACL), audit, separation of privilege (capabilities), mandatory access control (MAC) and information labels.
The work was terminated by IEEE’s RevCon in 1998 at draft 17 of the document due to lack of consensus (mostly because of conflicting existing practice.) While the formal standards effort failed, since then much of the draft standard has made its way in the Linux kernel including capabilities which this post explores.
First, what do we mean by Linux capabilities? It is basically an extended verion of the capabilities model described in the draft POSIX.1e standard. Readers familiar with VMS or versions of Unix which include Trusted Computing Base (TCB) will recognize it as being somewhat analogous to as privileges. These capabilities partition the set of root privlileges into a set of distinct logical privileges which may be granted or assigned to processes, users, filesystems and more. As an aside, the term capability originated in a 1966 paper by Jack Dennis and Earl Van Horn (CACM vol 9, #3, pp 143-155, March 1966.) Capabilities can be implemented in many ways including via hardware tags, cryptography, within a programming language (e.g.Java) or using protected address space. For a introduction to capability-based mechanisms go here. Linux uses protected address space and extended file attributes to implement capabilities.
A capability flag is an attribute of a capability. There are three capability flags, named permitted (p), effective