mirror of https://github.com/mkerrisk/man-pages
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:
parent
8de5616fd7
commit
ddb624a9e5
|
@ -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.
|
||||
|
|
Loading…
Reference in New Issue