capabilities.7: Improvements after feedback from Casey Schaufler

Reported-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2016-12-15 20:32:02 +01:00
parent 8de5616fd7
commit ddb624a9e5
1 changed files with 13 additions and 7 deletions

View File

@ -752,20 +752,26 @@ since kernel 2.6.24, all three requirements are met.
When adding a new kernel feature that should be governed by a capability,
consider the following points.
.IP * 3
The goal of capabilities is divide the power of superuser into small pieces,
such that if a program that has capabilities is compromised,
its power to do damage to the system would be much less than a similar
set-user-ID-root program.
The goal of capabilities is divide the power of superuser into pieces,
such that if a program that has one or more capabilities is compromised,
its power to do damage to the system would be less than the same program
running with root privilege.
.IP *
You have the choice of either creating a new capability for your new feature,
or associating the feature with one of the existing capabilities.
Because the size of capability sets is currently limited to 64 bits,
In order to keep the set of capabilities to a manageable size,
the latter option is preferable,
unless there are compelling reasons to take the former option.
(There is also a technical limit:
the size of capability sets is currently limited to 64 bits.)
.IP *
To determine which existing capability might best be associated
with your new feature, review the list of capabilities above in order
to find a "silo" into which your new feature best fits.
One approach to take is to determine if there are other features
requiring capabilities that will always be use along with the new feature.
If the new feature is useless without these other features,
you should use the same capability as the other features.
.IP *
.IR Don't
choose
@ -783,9 +789,9 @@ match existing uses in that silo.
.IP *
If you have determined that it really is necessary to create
a new capability for your feature,
avoid making (and naming) it as a "single-use" capability.
don't make or name it as a "single-use" capability.
Thus, for example, the addition of the highly specific
.BR CAP_WAKE_ALARM
.BR CAP_PACCT
was probably a mistake.
Instead, try to identify and name your new capability as a broader
silo into which other related future use cases might fit.