Jul's page (Hungarian) : Jul's packages : imprison

Preferred patches against the linux kernel

Capabilities

Although the linux kernel has a wonderful process capability facility, it doesn't have file capabilities. This kind of capabilities matter in capability changes.

There are two major points in the kernel where a process can loose capabilities: set*id(2) and execve(2). The first one can be evaded with a linux-specific kernel call (prctl(PR_SET_KEEPCAPS, 1) which is valid until an execve call), but the latter one cannot be bypassed: all file capabilities are lowered except if the current process uid and euid has admin privileges (you can say there is no user with admin privileges, and uid 0 don't mean admin).

A rule of thumb:

pI' = pI
pP' = (fP & bound-caps) | (fI & pI)
pE' = pP' & fE

where

• I=Inheritable, P=Permitted, E=Effective
• p=process, f=file
• '=post-execve()
• bound-caps=system-wide capability mask.

In the end a process can drop admin rights (by dropping capabilities and set*id(2)-ing), but cannot call another program with the remaining capabilities, just because the lack of fP and fI. Thus, one cannot use imprison-like software.

The solution can be simple, or difficult. A difficult solution can be RSBAC, LIDS, Medusa DS9, or grsecurity.

My solution is much simpler than trimming a mandatory access control list. In the fashion of keeping capabilities in set*id(2), I made the same in execve(2): if current->keep_capabilities is set by prctl(2), process caps is copied to file caps.

When the process flow is affected?

1. process with admin rights: no. Processes with admin rights always has semaphors (ie. file caps) raised.
2. process with user rights (no process caps): no. You cannot raise your process' capabilities.
3. process with some capabilities: yes. Capabilities will be kept.