Lower Process Capabilities

[Gregory Maxwell]

On Wed, Jul 29, 2009 at 9:32 AM, Stephen Smalley<sds at tycho.nsa.gov> wrote:
> If you want something more akin to privilege bracketing within a
> program, then a closer analog in SELinux would be setcon(3) to switch to
> a more restricted domain.  But in general our goal is to enforce
> security goals at the system level and not depend on the correctness of
> the application to shed privilege.
[snip]

But then, of course, we depend on the correctness of the system to
deny privileges.  Considering the number of users that disable SELinux
entirely— this surely can't be counted on.

And the historic number of applications which fail to shed privilege
(to the limited extents possible) shows that depending on the
application also isn't a complete solution.

It seems to me that the approaches could be complimentary— It would be
very nice if applications could drop any SELinux controlled privileged
at runtime, either temporarily or permanently.  This would not replace
the system level protection but would supplement it by remaining
active even if the wider protection were partially disabled, by
offering finer granularity, and by giving developers a greater
opportunity to participate in the use of SELinux (perhaps resulting in
more applications being structured in SELinux friendly ways).

Capabilities are agreed to be far too coarse, and they only subset
root when we really want to subset user permissions too. SELinux
provides many nice hooks. Developers would like to right software that
remains as secure as possible even if a user has goofed up the file
permissions.  Is there no possible improvement here?