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.
_______________________________________________
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.
