What's a policy capability?

What's a policy capability?

[dE]

[-- Attachment #1: Type: text/plain, Size: 63 bytes --]

I came cross this term and couldn't find much reference to it.

[-- Attachment #2: Type: text/html, Size: 604 bytes --]

Re: What's a policy capability?

[Stephen Smalley]

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.

Re: What's a policy capability?

[dE]

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?


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?

Re: What's a policy capability?

[Christopher J. PeBenito]

On 7/22/2014 1: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.
>>
> 
> 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?

Yes.  One example is the open permission on file classes.  When that was
added in the kernel, if you didn't have a policy that had open
permissions in it, then your system wouldn't work at all; no domain
would be allowed to open any file.  To fix that, we added the open_perms
capability, so you could specify that your policy was updated for the
open permission.

> 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?

That versions the policy database structure itself, not which object
classes or permissions are included.  For example, when default_*
statements were added, the policy structure had to be changed, so the
policy version was incremented.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Re: What's a policy capability?

[Stephen Smalley]

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.

Re: What's a policy capability?

[dE]

On 07/22/14 18:15, Stephen Smalley wrote:
> 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.
>

Thanks for clarifying everyone.

Re: What's a policy capability?

[dE]

On 07/22/14 17:57, Christopher J. PeBenito wrote:
> On 7/22/2014 1: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.
>>>
>> 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?
> Yes.  One example is the open permission on file classes.  When that was
> added in the kernel, if you didn't have a policy that had open
> permissions in it, then your system wouldn't work at all; no domain
> would be allowed to open any file.  To fix that, we added the open_perms
> capability, so you could specify that your policy was updated for the
> open permission.
>
>> 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?
> That versions the policy database structure itself, not which object
> classes or permissions are included.  For example, when default_*
> statements were added, the policy structure had to be changed, so the
> policy version was incremented.
>

I've noticed, that there're only 2 policy capabilities in Fedora 19.


That must means this polcap feature is relatively new.