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