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.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
