Re: What's a policy capability?

[Stephen Smalley <sds@tycho.nsa.gov>]

On 07/22/2014 01:03 AM, dE wrote:
> On 07/21/14 18:21, Stephen Smalley wrote:
>> On 07/19/2014 04:03 AM, dE wrote:
>>> I came cross this term and couldn't find much reference to it.
>> A mechanism for telling the kernel that your policy supports some new
>> feature/capability and therefore it is safe for the kernel to enable the
>> corresponding check/logic.  Used as a way of supporting new
>> checks/features in a backward-compatible manner:  old policies will not
>> have defined the policy capability for the new feature and therefore
>> will not enable the new check/logic by default, while new policies can
>> opt into or out of the new check/logic at their discretion.
>>
>> ls /sys/fs/selinux/policy_capabilities will show the list of policy
>> capabilities known to your kernel, while cat
>> /sys/fs/selinux/policy_capabilities/<capability_name> will show whether
>> that capability was enabled (1) or disabled (0) in the currently loaded
>> policy.
>>
>> seinfo --polcap will list enabled policy capabilities in the current or
>> specified policy.
>>
>> The set of policy capabilities to be enabled in the policy is declared
>> in refpolicy/policy/policy_capabilities in the refpolicy source.
>>
>> The kernel uses the value of specific policy capabilities to decide
>> whether to enable corresponding checks/logic in security/selinux/hooks.c
>> in the kernel source; look for tests of selinux_policycap_*.
>> These variables are set upon policy load by security_load_policycaps(),
>> loaded from a bitmap read from the policy file.
> 
> Ok, thanks for clarifying.
> 
> But just curious -- these new checks may not be not be backwards
> compatible? I mean if the kernel has enabled a policy feature, but the
> loaded policy does not have any such capability, then can it cause any
> problems?

Just to add to what Chris said:  while the handle_unknown=allow
mechanism could already address the simple case of adding an entirely
new permission to the kernel in a compatible manner, it could not
address changes to the semantics of an already defined permission or
replacing an older set of permission checks with new logic.  And with
handle_unknown=allow, you could not distinguish on a per-feature basis;
it was all allowed or none allowed for unknown classes/permissions.
Thus, policy capabilities were introduced as a more general mechanism.

> Also the policy has a version, using that it's capabilities can be known
> to the kernel and it may enable disable the features based on that. So
> in this case, why is policy capability required?

We actually used the policy version that way when we first introduced
finer-grained netlink socket classes, so that older policies would still
use a single netlink socket class but newer policies could leverage the
finer-grained classes.  However, as Chris pointed out, that version is
intended to represent changes to the binary policy format, and this was
a misuse of it.  Similarly to handle_unknown, you could also only use it
to enable all or none of the newer features, not on a per-feature basis.