From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id s6J83TWL003734 for ; Sat, 19 Jul 2014 04:03:29 -0400 Received: by mail-pd0-f170.google.com with SMTP id g10so6269260pdj.15 for ; Sat, 19 Jul 2014 01:03:32 -0700 (PDT) Received: from [192.168.1.2] ([59.89.20.62]) by mx.google.com with ESMTPSA id ak1sm7757487pbc.58.2014.07.19.01.03.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jul 2014 01:03:31 -0700 (PDT) Message-ID: <53CA2650.2050608@gmail.com> Date: Sat, 19 Jul 2014 13:33:28 +0530 From: dE MIME-Version: 1.0 To: selinux@tycho.nsa.gov Subject: What's a policy capability? Content-Type: multipart/alternative; boundary="------------050206000403060505010902" List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: This is a multi-part message in MIME format. --------------050206000403060505010902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I came cross this term and couldn't find much reference to it. --------------050206000403060505010902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I came cross this term and couldn't find much reference to it. --------------050206000403060505010902-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <53CD0CCB.5080300@tycho.nsa.gov> Date: Mon, 21 Jul 2014 08:51:23 -0400 From: Stephen Smalley MIME-Version: 1.0 To: dE , selinux@tycho.nsa.gov Subject: Re: What's a policy capability? References: <53CA2650.2050608@gmail.com> In-Reply-To: <53CA2650.2050608@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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/ 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id s6M53VoH005122 for ; Tue, 22 Jul 2014 01:03:31 -0400 Received: by mail-pa0-f48.google.com with SMTP id et14so11232096pad.35 for ; Mon, 21 Jul 2014 22:03:34 -0700 (PDT) Received: from [192.168.1.2] ([59.89.21.65]) by mx.google.com with ESMTPSA id jb5sm15886537pbd.73.2014.07.21.22.03.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 22:03:33 -0700 (PDT) Message-ID: <53CDF09D.4050304@gmail.com> Date: Tue, 22 Jul 2014 10:33:25 +0530 From: dE MIME-Version: 1.0 To: selinux@tycho.nsa.gov Subject: Re: What's a policy capability? References: <53CA2650.2050608@gmail.com> <53CD0CCB.5080300@tycho.nsa.gov> In-Reply-To: <53CD0CCB.5080300@tycho.nsa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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/ 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? From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id s6MCRBtr027949 for ; Tue, 22 Jul 2014 08:27:11 -0400 Message-ID: <53CE589C.4030408@tresys.com> Date: Tue, 22 Jul 2014 08:27:08 -0400 From: "Christopher J. PeBenito" MIME-Version: 1.0 To: dE , Subject: Re: What's a policy capability? References: <53CA2650.2050608@gmail.com> <53CD0CCB.5080300@tycho.nsa.gov> <53CDF09D.4050304@gmail.com> In-Reply-To: <53CDF09D.4050304@gmail.com> Content-Type: text/plain; charset="ISO-8859-1" List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <53CE5CDA.50901@tycho.nsa.gov> Date: Tue, 22 Jul 2014 08:45:14 -0400 From: Stephen Smalley MIME-Version: 1.0 To: dE , selinux@tycho.nsa.gov Subject: Re: What's a policy capability? References: <53CA2650.2050608@gmail.com> <53CD0CCB.5080300@tycho.nsa.gov> <53CDF09D.4050304@gmail.com> In-Reply-To: <53CDF09D.4050304@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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/ 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id s6N66Y1E025423 for ; Wed, 23 Jul 2014 02:06:34 -0400 Received: by mail-pa0-f51.google.com with SMTP id ey11so1049530pad.24 for ; Tue, 22 Jul 2014 23:06:21 -0700 (PDT) Received: from [192.168.1.2] ([117.201.83.48]) by mx.google.com with ESMTPSA id ce13sm1584592pdb.76.2014.07.22.23.06.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 23:06:20 -0700 (PDT) Message-ID: <53CF50D9.5000205@gmail.com> Date: Wed, 23 Jul 2014 11:36:17 +0530 From: dE MIME-Version: 1.0 To: selinux@tycho.nsa.gov Subject: Re: What's a policy capability? References: <53CA2650.2050608@gmail.com> <53CD0CCB.5080300@tycho.nsa.gov> <53CDF09D.4050304@gmail.com> <53CE5CDA.50901@tycho.nsa.gov> In-Reply-To: <53CE5CDA.50901@tycho.nsa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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/ 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id s6N6gb0d027103 for ; Wed, 23 Jul 2014 02:42:37 -0400 Received: by mail-pd0-f176.google.com with SMTP id y10so1041916pdj.7 for ; Tue, 22 Jul 2014 23:42:41 -0700 (PDT) Received: from [192.168.1.2] ([117.201.83.48]) by mx.google.com with ESMTPSA id y2sm5272448pas.45.2014.07.22.23.42.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 23:42:40 -0700 (PDT) Message-ID: <53CF595C.7060209@gmail.com> Date: Wed, 23 Jul 2014 12:12:36 +0530 From: dE MIME-Version: 1.0 To: selinux@tycho.nsa.gov Subject: Re: What's a policy capability? References: <53CA2650.2050608@gmail.com> <53CD0CCB.5080300@tycho.nsa.gov> <53CDF09D.4050304@gmail.com> <53CE589C.4030408@tresys.com> In-Reply-To: <53CE589C.4030408@tresys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: 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.