Re: capabilities patch (v 0.1)

[David Madore <david.madore@ens.fr>]

On Tue, Aug 09, 2005 at 04:28:31PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 09 Aug 2005 07:26:21 +0200, David Madore said:
> > * Second, a much more extensive change, the patch introduces a third
> > set of capabilities for every process, the "bounding" set.  Normally
> > the bounding set has every capability in it
> 
> How is this different in semantics from the existing 'permitted' capset?

The permitted sets is a set of capabilities really available to the
process (though they may be temporarily dropped by removing them from
the effective set, they are still available to take back).  In
contrast, the bounding set capabilities are not readily available to
the process; it just means that the capabilities in question *might*
be acquired by running a suid program (or setcap program if filesystem
support for capabilities ever comes to Linux).

Currently this is more or less an all-or-nothing process: since
capabilities can only be acquired by running a suid program, removing
any capability from the bounding set means the program will never be
permitted to execute a suid program any more (execve() will fail with
EPERM).  But maybe I'll reinstate the CAP_SETPCAP thing in some future
version of the patch (I'm still waiting for someone to tell me what
was wrong with CAP_SETPCAP and why it was removed), and then the
bounding set should also prohibit capabilities being given through
that interface.

The bottom line is: if you have some untrusted process, it might be
wise to remove empty its bounding set, making it incapable of
executing a suid root program and thus acquiring new capabilities.  (I
also plan to add some normally-available-to-all capabilities such as
"permission to fork()", "permission to exec()" and so on, and then it
will also be useful to remove these from a process's permitted set.)

> include/linux/capabilities.h:
> 
> typedef struct __user_cap_data_struct {
>         __u32 effective;
>         __u32 permitted;
>         __u32 inheritable;
> } __user *cap_user_data_t;
> 

And my patch adds a __u32 bounding to that structure.

-- 
     David A. Madore
    (david.madore@ens.fr,
     http://www.madore.org/~david/ )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/