Re: [PATCH 3/4] security: capabilities patch (version 0.4.4), part 3/4: introduce new capabilities

Joshua Brindle
2006-09-10T17:56:50Z

Alan Cox wrote:
> Ar Sul, 2006-09-10 am 15:42 +0200, ysgrifennodd David Madore:
>
>> Introduce six new "regular" (=on-by-default) capabilities:
>>
>> * CAP_REG_FORK, CAP_REG_OPEN, CAP_REG_EXEC allow access to the
>> fork(), open() and exec() syscalls,
>>
>
> CAP_REG_EXEC seems meaningless, I can do the same with mmap by hand for
> most types of binary execution except setuid (which is separate it
> seems)
>
> Given the capability model is accepted as inferior to things like
> SELinux policies why do we actually want to fix this anyway. It's
> unfortunate we can't discard the existing capabilities model (which has
> flaws) as well really.
>
>
To expand on this a little, some of the capabilities you are looking to
add are of very little if any use without being able to specify objects.
For example, CAP_REG_OPEN is whether the process can open any file
instead of specific ones. How many applications open no files whatsoever
in practice? Even if there are some as soon as they change and need to
open a file they'll need this capability and will be able to open any.
CAP_REG_WRITE has the same problem. For a description of why
CAP_REG_EXEC is meaningless see the digsig thread on the LSM list from
earlier this year.

Further, adding more capabilities would likely make existing LSM's (like
SELinux) deal with them. Since most LSM's already handle these
permissions on a per-object basis these will be entirely redundant and
more disruptive than useful.

Additionally since dropping capabilities is entirely discretionary and
applications would be modified to actually drop the capabilities I can't
ever see this being used in practice. It also embeds the policy into
applications spread across the filesystem instead of having a
centralized policy. Since these are non-standard capabilities any
application modified to take advantage of them could only do so on Linux.