* What's a policy capability? @ 2014-07-19 8:03 dE 2014-07-21 12:51 ` Stephen Smalley 0 siblings, 1 reply; 7+ messages in thread From: dE @ 2014-07-19 8:03 UTC (permalink / raw) To: selinux [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: What's a policy capability? 2014-07-19 8:03 What's a policy capability? dE @ 2014-07-21 12:51 ` Stephen Smalley 2014-07-22 5:03 ` dE 0 siblings, 1 reply; 7+ messages in thread From: Stephen Smalley @ 2014-07-21 12:51 UTC (permalink / raw) To: dE, selinux 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: What's a policy capability? 2014-07-21 12:51 ` Stephen Smalley @ 2014-07-22 5:03 ` dE 2014-07-22 12:27 ` Christopher J. PeBenito 2014-07-22 12:45 ` Stephen Smalley 0 siblings, 2 replies; 7+ messages in thread From: dE @ 2014-07-22 5:03 UTC (permalink / raw) To: selinux 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: What's a policy capability? 2014-07-22 5:03 ` dE @ 2014-07-22 12:27 ` Christopher J. PeBenito 2014-07-23 6:42 ` dE 2014-07-22 12:45 ` Stephen Smalley 1 sibling, 1 reply; 7+ messages in thread From: Christopher J. PeBenito @ 2014-07-22 12:27 UTC (permalink / raw) To: dE, selinux 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: What's a policy capability? 2014-07-22 12:27 ` Christopher J. PeBenito @ 2014-07-23 6:42 ` dE 0 siblings, 0 replies; 7+ messages in thread From: dE @ 2014-07-23 6:42 UTC (permalink / raw) To: selinux 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: What's a policy capability? 2014-07-22 5:03 ` dE 2014-07-22 12:27 ` Christopher J. PeBenito @ 2014-07-22 12:45 ` Stephen Smalley 2014-07-23 6:06 ` dE 1 sibling, 1 reply; 7+ messages in thread From: Stephen Smalley @ 2014-07-22 12:45 UTC (permalink / raw) To: dE, selinux 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: What's a policy capability? 2014-07-22 12:45 ` Stephen Smalley @ 2014-07-23 6:06 ` dE 0 siblings, 0 replies; 7+ messages in thread From: dE @ 2014-07-23 6:06 UTC (permalink / raw) To: selinux 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-07-23 6:42 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-19 8:03 What's a policy capability? dE 2014-07-21 12:51 ` Stephen Smalley 2014-07-22 5:03 ` dE 2014-07-22 12:27 ` Christopher J. PeBenito 2014-07-23 6:42 ` dE 2014-07-22 12:45 ` Stephen Smalley 2014-07-23 6:06 ` dE
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.