From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m9GJergI015853 for ; Thu, 16 Oct 2008 15:40:53 -0400 Received: from house.lunarmania.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m9GJer6I000323 for ; Thu, 16 Oct 2008 19:40:53 GMT Received: from 78-3-189-137.adsl.net.t-com.hr ([78.3.189.137] helo=[192.168.1.22]) by house.lunarmania.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KqYiF-0000xv-TE for selinux@tycho.nsa.gov; Thu, 16 Oct 2008 12:40:49 -0700 Message-ID: <48F798BB.6070602@rubix.com> Date: Thu, 16 Oct 2008 21:40:43 +0200 From: Andy Warner MIME-Version: 1.0 To: selinux@tycho.nsa.gov Subject: adding objects classes and permissions to policy Content-Type: multipart/alternative; boundary="------------090301020004030508050408" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. --------------090301020004030508050408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit When adding new object classes and permissions to SELinux policy is it necessary to re-create flask.h and av_permissions.h header files so that a user-space object manager can access the associated defines? If so, would someone give me some pointers as to how these are generated? Thanks, Andy --------------090301020004030508050408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
When adding new object classes and permissions to SELinux policy is it necessary to re-create flask.h and av_permissions.h header files so that a user-space object manager can access the associated defines? If so, would someone give me some pointers as to how these are generated?

Thanks,

Andy
--------------090301020004030508050408-- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: adding objects classes and permissions to policy From: Stephen Smalley To: Andy Warner Cc: selinux@tycho.nsa.gov In-Reply-To: <48F798BB.6070602@rubix.com> References: <48F798BB.6070602@rubix.com> Content-Type: text/plain Date: Thu, 16 Oct 2008 15:53:13 -0400 Message-Id: <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote: > > When adding new object classes and permissions to SELinux policy is it > necessary to re-create flask.h and av_permissions.h header files so > that a user-space object manager can access the associated defines? If > so, would someone give me some pointers as to how these are > generated? You should use the dynamic class/permission lookup facilities for any new code. man selinux_set_mapping XSELinux and SE-PostgreSQL are already using it I believe. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: adding objects classes and permissions to policy From: Stephen Smalley To: Andy Warner Cc: selinux@tycho.nsa.gov In-Reply-To: <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> References: <48F798BB.6070602@rubix.com> <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain Date: Thu, 16 Oct 2008 15:55:05 -0400 Message-Id: <1224186905.9247.141.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Thu, 2008-10-16 at 15:53 -0400, Stephen Smalley wrote: > On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote: > > > > When adding new object classes and permissions to SELinux policy is it > > necessary to re-create flask.h and av_permissions.h header files so > > that a user-space object manager can access the associated defines? If > > so, would someone give me some pointers as to how these are > > generated? > > You should use the dynamic class/permission lookup facilities for any > new code. man selinux_set_mapping > > XSELinux and SE-PostgreSQL are already using it I believe. Example usage from XSELinux: http://marc.info/?l=selinux&m=118114723416269&w=2 -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m9GK2bPn021165 for ; Thu, 16 Oct 2008 16:02:37 -0400 Received: from el-out-1112.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m9GK2bab005845 for ; Thu, 16 Oct 2008 20:02:37 GMT Received: by el-out-1112.google.com with SMTP id j27so61522elf.21 for ; Thu, 16 Oct 2008 13:02:36 -0700 (PDT) Message-ID: Date: Thu, 16 Oct 2008 15:02:36 -0500 From: "Xavier Toth" To: "Andy Warner" Subject: Re: adding objects classes and permissions to policy Cc: selinux@tycho.nsa.gov In-Reply-To: <48F798BB.6070602@rubix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <48F798BB.6070602@rubix.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Thu, Oct 16, 2008 at 2:40 PM, Andy Warner wrote: > > When adding new object classes and permissions to SELinux policy is it > necessary to re-create flask.h and av_permissions.h header files so that a > user-space object manager can access the associated defines? If so, would > someone give me some pointers as to how these are generated? > > Thanks, > > Andy > This might help: http://selinuxproject.org/page/Adding_New_Permissions Ted -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: adding objects classes and permissions to policy From: Stephen Smalley To: Xavier Toth Cc: Andy Warner , selinux@tycho.nsa.gov In-Reply-To: References: <48F798BB.6070602@rubix.com> Content-Type: text/plain Date: Thu, 16 Oct 2008 16:06:12 -0400 Message-Id: <1224187572.9247.144.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Thu, 2008-10-16 at 15:02 -0500, Xavier Toth wrote: > On Thu, Oct 16, 2008 at 2:40 PM, Andy Warner wrote: > > > > When adding new object classes and permissions to SELinux policy is it > > necessary to re-create flask.h and av_permissions.h header files so that a > > user-space object manager can access the associated defines? If so, would > > someone give me some pointers as to how these are generated? > > > > Thanks, > > > > Andy > > > This might help: > http://selinuxproject.org/page/Adding_New_Permissions Deprecated for userspace object managers, should only be followed for kernel classes/permissions. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48F85ECC.108@rubix.com> Date: Fri, 17 Oct 2008 11:45:48 +0200 From: Andy Warner MIME-Version: 1.0 To: Stephen Smalley CC: selinux@tycho.nsa.gov Subject: Re: adding objects classes and permissions to policy References: <48F798BB.6070602@rubix.com> <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> <1224186905.9247.141.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1224186905.9247.141.camel@moss-spartans.epoch.ncsc.mil> Content-Type: multipart/alternative; boundary="------------040707060809000002040308" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. --------------040707060809000002040308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephen Smalley wrote: > On Thu, 2008-10-16 at 15:53 -0400, Stephen Smalley wrote: > >> On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote: >> >>> When adding new object classes and permissions to SELinux policy is it >>> necessary to re-create flask.h and av_permissions.h header files so >>> that a user-space object manager can access the associated defines? If >>> so, would someone give me some pointers as to how these are >>> generated? >>> >> You should use the dynamic class/permission lookup facilities for any >> new code. man selinux_set_mapping >> >> XSELinux and SE-PostgreSQL are already using it I believe. >> > > I can't find any evidence that my version of libselinux contains the selinux_set_mapping function. I am using CentOS 5.1 with libselinux version 1.33.4. I have been learning RHEL 5 tends to be a bit behind the times with regards to SELinux functionality. Does libselinux 1.33.4 not have the dynamic class/permission lookup facilities? If it does not, any advice on how to add object classes / permissions to policy ? Moving to Fedora is a possibility, maybe it's worth considering as this would not be the first issue we have had with an outdated SELinux mechanism on RHEL 5 (?). We are integrating SELinux TE / MLS with our commercial DBMS, and I have learned that RHEL 5 does not have the database related object classes /permissions in the base policy where the most recent Fedora does, hence my need to add the object classes /permissions in RHEL 5. > Example usage from XSELinux: > http://marc.info/?l=selinux&m=118114723416269&w=2 > > --------------040707060809000002040308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Stephen Smalley wrote:

On Thu, 2008-10-16 at 15:53 -0400, Stephen Smalley wrote:

On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote:

When adding new object classes and permissions to SELinux policy is it
necessary to re-create flask.h and av_permissions.h header files so
that a user-space object manager can access the associated defines? If
so, would someone give me some pointers as to how these are
generated?

You should use the dynamic class/permission lookup facilities for any
new code.  man selinux_set_mapping

XSELinux and SE-PostgreSQL are already using it I believe.

I can't find any evidence that my version of libselinux contains the selinux_set_mapping function. I am using CentOS 5.1 with libselinux version 1.33.4. I have been learning RHEL 5 tends to be a bit behind the times with regards to SELinux functionality. Does libselinux 1.33.4 not have the dynamic class/permission lookup facilities? If it does not, any advice on how to add object classes / permissions to policy ? Moving to Fedora is a possibility, maybe it's worth considering as this would not be the first issue we have had with an outdated SELinux mechanism on RHEL 5 (?). We are integrating SELinux TE / MLS with our commercial DBMS, and I have learned that RHEL 5 does not have the database related object classes /permissions in the base policy where the most recent Fedora does, hence my need to add the object classes /permissions in RHEL 5.

Example usage from XSELinux:
http://marc.info/?l=selinux&m=118114723416269&w=2

--------------040707060809000002040308-- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: adding objects classes and permissions to policy From: Stephen Smalley To: Andy Warner Cc: selinux@tycho.nsa.gov, Daniel J Walsh In-Reply-To: <48F85ECC.108@rubix.com> References: <48F798BB.6070602@rubix.com> <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> <1224186905.9247.141.camel@moss-spartans.epoch.ncsc.mil> <48F85ECC.108@rubix.com> Content-Type: text/plain Date: Fri, 17 Oct 2008 08:13:33 -0400 Message-Id: <1224245613.18694.26.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Fri, 2008-10-17 at 11:45 +0200, Andy Warner wrote: > > > Stephen Smalley wrote: > > On Thu, 2008-10-16 at 15:53 -0400, Stephen Smalley wrote: > > > > > On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote: > > > > > > > When adding new object classes and permissions to SELinux policy is it > > > > necessary to re-create flask.h and av_permissions.h header files so > > > > that a user-space object manager can access the associated defines? If > > > > so, would someone give me some pointers as to how these are > > > > generated? > > > > > > > You should use the dynamic class/permission lookup facilities for any > > > new code. man selinux_set_mapping > > > > > > XSELinux and SE-PostgreSQL are already using it I believe. > > > > > > > > I can't find any evidence that my version of libselinux contains the > selinux_set_mapping function. I am using CentOS 5.1 with libselinux > version 1.33.4. I have been learning RHEL 5 tends to be a bit behind > the times with regards to SELinux functionality. Does libselinux > 1.33.4 not have the dynamic class/permission lookup facilities? If it > does not, any advice on how to add object classes / permissions to > policy ? Moving to Fedora is a possibility, maybe it's worth > considering as this would not be the first issue we have had with an > outdated SELinux mechanism on RHEL 5 (?). We are integrating SELinux > TE / MLS with our commercial DBMS, and I have learned that RHEL 5 does > not have the database related object classes /permissions in the base > policy where the most recent Fedora does, hence my need to add the > object classes /permissions in RHEL 5. To use the object class/perm discovery support, you'd need to use a modern libselinux (>= 2.0.21) and a modern kernel (>= 2.6.23). Note that regardless of whether you use object class/permission discovery support, you have to add the classes and permissions to the policy flask definitions and rebuild your policy. The object class/perm discovery support just changes how the object manager obtains the values - whether they are hardcoded into it or dynamically looked up at object manager startup. But the policy itself still needs to be taught about them. As Ted said, the old way to teach libselinux about new classes/perms is described in: http://selinuxproject.org/page/Adding_New_Permissions After updating the policy/flask files, you run make in the flask subdirectory (different Makefile than the policy build one) and it will regenerate the header files that are used by libselinux and by the kernel. Then you can install the libselinux ones into a libselinux source tree via make LIBSELINUX_D=/path/to/libselinux tolib, and then rebuild your libselinux. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48F89EBE.6020800@rubix.com> Date: Fri, 17 Oct 2008 16:18:38 +0200 From: Andy Warner MIME-Version: 1.0 To: Stephen Smalley CC: selinux@tycho.nsa.gov, Daniel J Walsh Subject: Re: adding objects classes and permissions to policy References: <48F798BB.6070602@rubix.com> <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> <1224186905.9247.141.camel@moss-spartans.epoch.ncsc.mil> <48F85ECC.108@rubix.com> <1224245613.18694.26.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1224245613.18694.26.camel@moss-spartans.epoch.ncsc.mil> Content-Type: multipart/alternative; boundary="------------080509050104040709000508" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. --------------080509050104040709000508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephen Smalley wrote: > On Fri, 2008-10-17 at 11:45 +0200, Andy Warner wrote: > >> Stephen Smalley wrote: >> >>> On Thu, 2008-10-16 at 15:53 -0400, Stephen Smalley wrote: >>> >>> >>>> On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote: >>>> >>>> >>>>> When adding new object classes and permissions to SELinux policy is it >>>>> necessary to re-create flask.h and av_permissions.h header files so >>>>> that a user-space object manager can access the associated defines? If >>>>> so, would someone give me some pointers as to how these are >>>>> generated? >>>>> >>>>> >>>> You should use the dynamic class/permission lookup facilities for any >>>> new code. man selinux_set_mapping >>>> >>>> XSELinux and SE-PostgreSQL are already using it I believe. >>>> >>>> >>> >>> >> I can't find any evidence that my version of libselinux contains the >> selinux_set_mapping function. I am using CentOS 5.1 with libselinux >> version 1.33.4. I have been learning RHEL 5 tends to be a bit behind >> the times with regards to SELinux functionality. Does libselinux >> 1.33.4 not have the dynamic class/permission lookup facilities? If it >> does not, any advice on how to add object classes / permissions to >> policy ? Moving to Fedora is a possibility, maybe it's worth >> considering as this would not be the first issue we have had with an >> outdated SELinux mechanism on RHEL 5 (?). We are integrating SELinux >> TE / MLS with our commercial DBMS, and I have learned that RHEL 5 does >> not have the database related object classes /permissions in the base >> policy where the most recent Fedora does, hence my need to add the >> object classes /permissions in RHEL 5. >> > > To use the object class/perm discovery support, you'd need to use a > modern libselinux (>= 2.0.21) and a modern kernel (>= 2.6.23). > > Note that regardless of whether you use object class/permission > discovery support, you have to add the classes and permissions to the > policy flask definitions and rebuild your policy. The object class/perm > discovery support just changes how the object manager obtains the values > - whether they are hardcoded into it or dynamically looked up at object > manager startup. But the policy itself still needs to be taught about > them. > > As Ted said, the old way to teach libselinux about new classes/perms is > described in: > http://selinuxproject.org/page/Adding_New_Permissions > > After updating the policy/flask files, you run make in the flask > subdirectory (different Makefile than the policy build one) and it will > regenerate the header files that are used by libselinux and by the > kernel. Then you can install the libselinux ones into a libselinux > source tree via make LIBSELINUX_D=/path/to/libselinux tolib, and then > rebuild your libselinux. > > When I install our product on a fresh machine in addition to the actual product and the new policy files, will I also need to install a new version of the libselinux libraries? I assume that the linux kernel needs to somehow access the new object class / permissions defines (I'm guessing there is a potential for pre-existing defines to change through my policy rebuild), would that be through the shared libselinux libraries? Kernel rebuild? (Mucking with Linux itself is way out of my area of knowledge.) --------------080509050104040709000508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Stephen Smalley wrote:

On Fri, 2008-10-17 at 11:45 +0200, Andy Warner wrote:

Stephen Smalley wrote:

On Thu, 2008-10-16 at 15:53 -0400, Stephen Smalley wrote:

On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote:

When adding new object classes and permissions to SELinux policy is it
necessary to re-create flask.h and av_permissions.h header files so
that a user-space object manager can access the associated defines? If
so, would someone give me some pointers as to how these are
generated?

You should use the dynamic class/permission lookup facilities for any
new code.  man selinux_set_mapping

XSELinux and SE-PostgreSQL are already using it I believe.

I can't find any evidence that my version of libselinux contains the
selinux_set_mapping function. I am using CentOS 5.1 with libselinux
version 1.33.4. I have been learning RHEL 5 tends to be a bit behind
the times with regards to SELinux functionality. Does libselinux
1.33.4 not have the dynamic class/permission lookup facilities? If it
does not, any advice on how to add object classes / permissions to
policy ? Moving to Fedora is a possibility, maybe it's worth
considering as this would not be the first issue we have had with an
outdated SELinux mechanism on RHEL 5 (?). We are integrating SELinux
TE / MLS with our commercial DBMS, and I have learned that RHEL 5 does
not have the database related object classes /permissions in the base
policy where the most recent Fedora does, hence my need to add the
object classes /permissions in RHEL 5.


To use the object class/perm discovery support, you'd need to use a
modern libselinux (>= 2.0.21) and a modern kernel (>= 2.6.23).

Note that regardless of whether you use object class/permission
discovery support, you have to add the classes and permissions to the
policy flask definitions and rebuild your policy.  The object class/perm
discovery support just changes how the object manager obtains the values
- whether they are hardcoded into it or dynamically looked up at object
manager startup.  But the policy itself still needs to be taught about
them.

As Ted said, the old way to teach libselinux about new classes/perms is
described in:
http://selinuxproject.org/page/Adding_New_Permissions

After updating the policy/flask files, you run make in the flask
subdirectory (different Makefile than the policy build one) and it will
regenerate the header files that are used by libselinux and by the
kernel.  Then you can install the libselinux ones into a libselinux
source tree via make LIBSELINUX_D=/path/to/libselinux tolib, and then
rebuild your libselinux.

When I install our product on a fresh machine in addition to the actual product and the new policy files, will I also need to install a new version of the libselinux libraries? I assume that the linux kernel needs to somehow access the new object class / permissions defines (I'm guessing there is a potential for pre-existing defines to change through my policy rebuild), would that be through the shared libselinux libraries? Kernel rebuild? (Mucking with Linux itself is way out of my area of knowledge.)

--------------080509050104040709000508-- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: adding objects classes and permissions to policy From: Stephen Smalley To: Andy Warner Cc: selinux@tycho.nsa.gov, Daniel J Walsh In-Reply-To: <48F89EBE.6020800@rubix.com> References: <48F798BB.6070602@rubix.com> <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> <1224186905.9247.141.camel@moss-spartans.epoch.ncsc.mil> <48F85ECC.108@rubix.com> <1224245613.18694.26.camel@moss-spartans.epoch.ncsc.mil> <48F89EBE.6020800@rubix.com> Content-Type: text/plain Date: Fri, 17 Oct 2008 10:23:55 -0400 Message-Id: <1224253435.19562.23.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Fri, 2008-10-17 at 16:18 +0200, Andy Warner wrote: > > > Stephen Smalley wrote: > > On Fri, 2008-10-17 at 11:45 +0200, Andy Warner wrote: > > > > > Stephen Smalley wrote: > > > > > > > On Thu, 2008-10-16 at 15:53 -0400, Stephen Smalley wrote: > > > > > > > > > > > > > On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote: > > > > > > > > > > > > > > > > When adding new object classes and permissions to SELinux policy is it > > > > > > necessary to re-create flask.h and av_permissions.h header files so > > > > > > that a user-space object manager can access the associated defines? If > > > > > > so, would someone give me some pointers as to how these are > > > > > > generated? > > > > > > > > > > > > > > > > > You should use the dynamic class/permission lookup facilities for any > > > > > new code. man selinux_set_mapping > > > > > > > > > > XSELinux and SE-PostgreSQL are already using it I believe. > > > > > > > > > > > > > I can't find any evidence that my version of libselinux contains the > > > selinux_set_mapping function. I am using CentOS 5.1 with libselinux > > > version 1.33.4. I have been learning RHEL 5 tends to be a bit behind > > > the times with regards to SELinux functionality. Does libselinux > > > 1.33.4 not have the dynamic class/permission lookup facilities? If it > > > does not, any advice on how to add object classes / permissions to > > > policy ? Moving to Fedora is a possibility, maybe it's worth > > > considering as this would not be the first issue we have had with an > > > outdated SELinux mechanism on RHEL 5 (?). We are integrating SELinux > > > TE / MLS with our commercial DBMS, and I have learned that RHEL 5 does > > > not have the database related object classes /permissions in the base > > > policy where the most recent Fedora does, hence my need to add the > > > object classes /permissions in RHEL 5. > > > > > > > To use the object class/perm discovery support, you'd need to use a > > modern libselinux (>= 2.0.21) and a modern kernel (>= 2.6.23). > > > > Note that regardless of whether you use object class/permission > > discovery support, you have to add the classes and permissions to the > > policy flask definitions and rebuild your policy. The object class/perm > > discovery support just changes how the object manager obtains the values > > - whether they are hardcoded into it or dynamically looked up at object > > manager startup. But the policy itself still needs to be taught about > > them. > > > > As Ted said, the old way to teach libselinux about new classes/perms is > > described in: > > http://selinuxproject.org/page/Adding_New_Permissions > > > > After updating the policy/flask files, you run make in the flask > > subdirectory (different Makefile than the policy build one) and it will > > regenerate the header files that are used by libselinux and by the > > kernel. Then you can install the libselinux ones into a libselinux > > source tree via make LIBSELINUX_D=/path/to/libselinux tolib, and then > > rebuild your libselinux. > > > > > When I install our product on a fresh machine in addition to the > actual product and the new policy files, will I also need to install a > new version of the libselinux libraries? Yes (when using the old way). > I assume that the linux kernel needs to somehow access the new object > class / permissions defines (I'm guessing there is a potential for > pre-existing defines to change through my policy rebuild), would that > be through the shared libselinux libraries? Kernel rebuild? (Mucking > with Linux itself is way out of my area of knowledge.) No, the kernel doesn't need userspace object class/perm definitions, because it never references them itself. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48F8ABBC.9060808@rubix.com> Date: Fri, 17 Oct 2008 17:14:05 +0200 From: Andy Warner MIME-Version: 1.0 To: Stephen Smalley CC: selinux@tycho.nsa.gov, Daniel J Walsh Subject: Re: adding objects classes and permissions to policy References: <48F798BB.6070602@rubix.com> <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> <1224186905.9247.141.camel@moss-spartans.epoch.ncsc.mil> <48F85ECC.108@rubix.com> <1224245613.18694.26.camel@moss-spartans.epoch.ncsc.mil> <48F89EBE.6020800@rubix.com> <1224253435.19562.23.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1224253435.19562.23.camel@moss-spartans.epoch.ncsc.mil> Content-Type: multipart/alternative; boundary="------------080701060703020102050302" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. --------------080701060703020102050302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephen Smalley wrote: > On Fri, 2008-10-17 at 16:18 +0200, Andy Warner wrote: > >> Stephen Smalley wrote: >> >>> On Fri, 2008-10-17 at 11:45 +0200, Andy Warner wrote: >>> >>> >>>> Stephen Smalley wrote: >>>> >>>> >>>>> On Thu, 2008-10-16 at 15:53 -0400, Stephen Smalley wrote: >>>>> >>>>> >>>>> >>>>>> On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote: >>>>>> >>>>>> >>>>>> >>>>>>> When adding new object classes and permissions to SELinux policy is it >>>>>>> necessary to re-create flask.h and av_permissions.h header files so >>>>>>> that a user-space object manager can access the associated defines? If >>>>>>> so, would someone give me some pointers as to how these are >>>>>>> generated? >>>>>>> >>>>>>> >>>>>>> >>>>>> You should use the dynamic class/permission lookup facilities for any >>>>>> new code. man selinux_set_mapping >>>>>> >>>>>> XSELinux and SE-PostgreSQL are already using it I believe. >>>>>> >>>>>> >>>>>> >>>> I can't find any evidence that my version of libselinux contains the >>>> selinux_set_mapping function. I am using CentOS 5.1 with libselinux >>>> version 1.33.4. I have been learning RHEL 5 tends to be a bit behind >>>> the times with regards to SELinux functionality. Does libselinux >>>> 1.33.4 not have the dynamic class/permission lookup facilities? If it >>>> does not, any advice on how to add object classes / permissions to >>>> policy ? Moving to Fedora is a possibility, maybe it's worth >>>> considering as this would not be the first issue we have had with an >>>> outdated SELinux mechanism on RHEL 5 (?). We are integrating SELinux >>>> TE / MLS with our commercial DBMS, and I have learned that RHEL 5 does >>>> not have the database related object classes /permissions in the base >>>> policy where the most recent Fedora does, hence my need to add the >>>> object classes /permissions in RHEL 5. >>>> >>>> >>> To use the object class/perm discovery support, you'd need to use a >>> modern libselinux (>= 2.0.21) and a modern kernel (>= 2.6.23). >>> >>> Note that regardless of whether you use object class/permission >>> discovery support, you have to add the classes and permissions to the >>> policy flask definitions and rebuild your policy. The object class/perm >>> discovery support just changes how the object manager obtains the values >>> - whether they are hardcoded into it or dynamically looked up at object >>> manager startup. But the policy itself still needs to be taught about >>> them. >>> >>> As Ted said, the old way to teach libselinux about new classes/perms is >>> described in: >>> http://selinuxproject.org/page/Adding_New_Permissions >>> >>> After updating the policy/flask files, you run make in the flask >>> subdirectory (different Makefile than the policy build one) and it will >>> regenerate the header files that are used by libselinux and by the >>> kernel. Then you can install the libselinux ones into a libselinux >>> source tree via make LIBSELINUX_D=/path/to/libselinux tolib, and then >>> rebuild your libselinux. >>> >>> >>> >> When I install our product on a fresh machine in addition to the >> actual product and the new policy files, will I also need to install a >> new version of the libselinux libraries? >> > > Yes (when using the old way). > > >> I assume that the linux kernel needs to somehow access the new object >> class / permissions defines (I'm guessing there is a potential for >> pre-existing defines to change through my policy rebuild), would that >> be through the shared libselinux libraries? Kernel rebuild? (Mucking >> with Linux itself is way out of my area of knowledge.) >> > > No, the kernel doesn't need userspace object class/perm definitions, > because it never references them itself. > My concern was not that the kernel would need to access my userspace object class/perm definitions but that through creating a new flask.h I would change the definitions of pre-existing object classes. For instance, my current flask.h has: #define SECCLASS_FILE 6 If after I generated a new flask.h this somehow changed to: #define SECCLASS_FILE 7 I would think this could cause an issue with the kernel if it uses the SECCLASS_FILE define in code built with the original flask.h. Is this possible or are the pre-existing kernel object class defines guarenteed to be consistent accross policy builds which have new object class definitions? --------------080701060703020102050302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Stephen Smalley wrote:

On Fri, 2008-10-17 at 16:18 +0200, Andy Warner wrote:

Stephen Smalley wrote:

On Fri, 2008-10-17 at 11:45 +0200, Andy Warner wrote:

Stephen Smalley wrote:

On Thu, 2008-10-16 at 15:53 -0400, Stephen Smalley wrote:

On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote:

When adding new object classes and permissions to SELinux policy is it
necessary to re-create flask.h and av_permissions.h header files so
that a user-space object manager can access the associated defines? If
so, would someone give me some pointers as to how these are
generated?

You should use the dynamic class/permission lookup facilities for any
new code.  man selinux_set_mapping

XSELinux and SE-PostgreSQL are already using it I believe.

I can't find any evidence that my version of libselinux contains the
selinux_set_mapping function. I am using CentOS 5.1 with libselinux
version 1.33.4. I have been learning RHEL 5 tends to be a bit behind
the times with regards to SELinux functionality. Does libselinux
1.33.4 not have the dynamic class/permission lookup facilities? If it
does not, any advice on how to add object classes / permissions to
policy ? Moving to Fedora is a possibility, maybe it's worth
considering as this would not be the first issue we have had with an
outdated SELinux mechanism on RHEL 5 (?). We are integrating SELinux
TE / MLS with our commercial DBMS, and I have learned that RHEL 5 does
not have the database related object classes /permissions in the base
policy where the most recent Fedora does, hence my need to add the
object classes /permissions in RHEL 5.

To use the object class/perm discovery support, you'd need to use a
modern libselinux (>= 2.0.21) and a modern kernel (>= 2.6.23).

Note that regardless of whether you use object class/permission
discovery support, you have to add the classes and permissions to the
policy flask definitions and rebuild your policy.  The object class/perm
discovery support just changes how the object manager obtains the values
- whether they are hardcoded into it or dynamically looked up at object
manager startup.  But the policy itself still needs to be taught about
them.

As Ted said, the old way to teach libselinux about new classes/perms is
described in:
http://selinuxproject.org/page/Adding_New_Permissions

After updating the policy/flask files, you run make in the flask
subdirectory (different Makefile than the policy build one) and it will
regenerate the header files that are used by libselinux and by the
kernel.  Then you can install the libselinux ones into a libselinux
source tree via make LIBSELINUX_D=/path/to/libselinux tolib, and then
rebuild your libselinux.

When I install our product on a fresh machine in addition to the
actual product and the new policy files, will I also need to install a
new version of the libselinux libraries?


Yes (when using the old way).

 I assume that the linux kernel needs to somehow access the new object
class / permissions defines (I'm guessing there is a potential for
pre-existing defines to change through my policy rebuild), would that
be through the shared libselinux libraries? Kernel rebuild? (Mucking
with Linux itself is way out of my area of knowledge.)


No, the kernel doesn't need userspace object class/perm definitions,
because it never references them itself.

My concern was not that the kernel would need to access my userspace object class/perm definitions but that through creating a new flask.h I would change the definitions of pre-existing object classes. For instance, my current flask.h has:

#define SECCLASS_FILE 6

If after I generated a new flask.h this somehow changed to:

#define SECCLASS_FILE 7

I would think this could cause an issue with the kernel if it uses the SECCLASS_FILE define in code built with the original flask.h. Is this possible or are the pre-existing kernel object class defines guarenteed to be consistent accross policy builds which have new object class definitions?

--------------080701060703020102050302-- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: adding objects classes and permissions to policy From: Stephen Smalley To: Andy Warner Cc: selinux@tycho.nsa.gov, Daniel J Walsh In-Reply-To: <48F8ABBC.9060808@rubix.com> References: <48F798BB.6070602@rubix.com> <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> <1224186905.9247.141.camel@moss-spartans.epoch.ncsc.mil> <48F85ECC.108@rubix.com> <1224245613.18694.26.camel@moss-spartans.epoch.ncsc.mil> <48F89EBE.6020800@rubix.com> <1224253435.19562.23.camel@moss-spartans.epoch.ncsc.mil> <48F8ABBC.9060808@rubix.com> Content-Type: text/plain Date: Fri, 17 Oct 2008 11:15:22 -0400 Message-Id: <1224256522.19562.54.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Fri, 2008-10-17 at 17:14 +0200, Andy Warner wrote: > > > Stephen Smalley wrote: > > On Fri, 2008-10-17 at 16:18 +0200, Andy Warner wrote: > > > > > Stephen Smalley wrote: > > > > > > > On Fri, 2008-10-17 at 11:45 +0200, Andy Warner wrote: > > > > > > > > > > > > > Stephen Smalley wrote: > > > > > > > > > > > > > > > > On Thu, 2008-10-16 at 15:53 -0400, Stephen Smalley wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 2008-10-16 at 21:40 +0200, Andy Warner wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > When adding new object classes and permissions to SELinux policy is it > > > > > > > > necessary to re-create flask.h and av_permissions.h header files so > > > > > > > > that a user-space object manager can access the associated defines? If > > > > > > > > so, would someone give me some pointers as to how these are > > > > > > > > generated? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You should use the dynamic class/permission lookup facilities for any > > > > > > > new code. man selinux_set_mapping > > > > > > > > > > > > > > XSELinux and SE-PostgreSQL are already using it I believe. > > > > > > > > > > > > > > > > > > > > > > > > > > I can't find any evidence that my version of libselinux contains the > > > > > selinux_set_mapping function. I am using CentOS 5.1 with libselinux > > > > > version 1.33.4. I have been learning RHEL 5 tends to be a bit behind > > > > > the times with regards to SELinux functionality. Does libselinux > > > > > 1.33.4 not have the dynamic class/permission lookup facilities? If it > > > > > does not, any advice on how to add object classes / permissions to > > > > > policy ? Moving to Fedora is a possibility, maybe it's worth > > > > > considering as this would not be the first issue we have had with an > > > > > outdated SELinux mechanism on RHEL 5 (?). We are integrating SELinux > > > > > TE / MLS with our commercial DBMS, and I have learned that RHEL 5 does > > > > > not have the database related object classes /permissions in the base > > > > > policy where the most recent Fedora does, hence my need to add the > > > > > object classes /permissions in RHEL 5. > > > > > > > > > > > > > > To use the object class/perm discovery support, you'd need to use a > > > > modern libselinux (>= 2.0.21) and a modern kernel (>= 2.6.23). > > > > > > > > Note that regardless of whether you use object class/permission > > > > discovery support, you have to add the classes and permissions to the > > > > policy flask definitions and rebuild your policy. The object class/perm > > > > discovery support just changes how the object manager obtains the values > > > > - whether they are hardcoded into it or dynamically looked up at object > > > > manager startup. But the policy itself still needs to be taught about > > > > them. > > > > > > > > As Ted said, the old way to teach libselinux about new classes/perms is > > > > described in: > > > > http://selinuxproject.org/page/Adding_New_Permissions > > > > > > > > After updating the policy/flask files, you run make in the flask > > > > subdirectory (different Makefile than the policy build one) and it will > > > > regenerate the header files that are used by libselinux and by the > > > > kernel. Then you can install the libselinux ones into a libselinux > > > > source tree via make LIBSELINUX_D=/path/to/libselinux tolib, and then > > > > rebuild your libselinux. > > > > > > > > > > > > > > > When I install our product on a fresh machine in addition to the > > > actual product and the new policy files, will I also need to install a > > > new version of the libselinux libraries? > > > > > > > Yes (when using the old way). > > > > > > > I assume that the linux kernel needs to somehow access the new object > > > class / permissions defines (I'm guessing there is a potential for > > > pre-existing defines to change through my policy rebuild), would that > > > be through the shared libselinux libraries? Kernel rebuild? (Mucking > > > with Linux itself is way out of my area of knowledge.) > > > > > > > No, the kernel doesn't need userspace object class/perm definitions, > > because it never references them itself. > > > My concern was not that the kernel would need to access my userspace > object class/perm definitions but that through creating a new flask.h > I would change the definitions of pre-existing object classes. For > instance, my current flask.h has: > > #define SECCLASS_FILE 6 > > If after I generated a new flask.h this somehow changed to: > > #define SECCLASS_FILE 7 > > I would think this could cause an issue with the kernel if it uses the > SECCLASS_FILE define in code built with the original flask.h. Is this > possible or are the pre-existing kernel object class defines > guarenteed to be consistent accross policy builds which have new > object class definitions? You have to add new classes to the end of security_classes. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zombie2.ncsc.mil (zombie2.ncsc.mil [144.51.88.133]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m9HFu1Gu000590 for ; Fri, 17 Oct 2008 11:56:01 -0400 Received: from flower.research.telcordia.com (jazzdrum.ncsc.mil [144.51.5.7]) by zombie2.ncsc.mil (8.12.10/8.12.10) with ESMTP id m9HFsfpC009542 for ; Fri, 17 Oct 2008 15:54:41 GMT Received: from [127.0.0.1] (ar12-209.research.telcordia.com [192.4.12.209]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id m9HFuE94023168 for ; Fri, 17 Oct 2008 11:56:14 -0400 (EDT) Message-ID: <48F8B58C.9040609@research.telcordia.com> Date: Fri, 17 Oct 2008 11:55:56 -0400 From: Sanjai Narain MIME-Version: 1.0 CC: selinux@tycho.nsa.gov Subject: Protecting against inadvertent file copy References: <48F798BB.6070602@rubix.com> <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> <1224186905.9247.141.camel@moss-spartans.epoch.ncsc.mil> <48F85ECC.108@rubix.com> <1224245613.18694.26.camel@moss-spartans.epoch.ncsc.mil> <48F89EBE.6020800@rubix.com> <1224253435.19562.23.camel@moss-spartans.epoch.ncsc.mil> <48F8ABBC.9060808@rubix.com> <1224256522.19562.54.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1224256522.19562.54.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Hello: I am just getting started with SELinux, and would very much appreciate an answer to the following question: Suppose there is a directory ftp_dir. If one wants to allow ftp of one's file to the outside world, one places it in ftp_dir. Suppose there is also a directory private_dir. One wants to prevent copying of any file in that directory into ftp_dir. In particular, one wants to say "do not allow cp from private_dir to ftp_dir". How would one go about expressing this in SELinux? Thanks. -- Sanjai -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: Protecting against inadvertent file copy From: Stephen Smalley To: Sanjai Narain Cc: selinux@tycho.nsa.gov In-Reply-To: <48F8B58C.9040609@research.telcordia.com> References: <48F798BB.6070602@rubix.com> <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> <1224186905.9247.141.camel@moss-spartans.epoch.ncsc.mil> <48F85ECC.108@rubix.com> <1224245613.18694.26.camel@moss-spartans.epoch.ncsc.mil> <48F89EBE.6020800@rubix.com> <1224253435.19562.23.camel@moss-spartans.epoch.ncsc.mil> <48F8ABBC.9060808@rubix.com> <1224256522.19562.54.camel@moss-spartans.epoch.ncsc.mil> <48F8B58C.9040609@research.telcordia.com> Content-Type: text/plain Date: Fri, 17 Oct 2008 13:14:55 -0400 Message-Id: <1224263695.19562.89.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Fri, 2008-10-17 at 11:55 -0400, Sanjai Narain wrote: > Hello: I am just getting started with SELinux, and would very much > appreciate an answer to the following question: > > Suppose there is a directory ftp_dir. If one wants to allow ftp of one's > file to the outside world, one places it in ftp_dir. Suppose there is > also a directory private_dir. One wants to prevent copying of any file > in that directory into ftp_dir. In particular, one wants to say "do not > allow cp from private_dir to ftp_dir". How would one go about expressing > this in SELinux? By labeling the two directories with two different types, and defining the roles/domains such that no domain can both read from private_dir and write to ftp_dir. If you want to be strict about it, you'd further have to ensure that there is no path by which information from private_dir can eventually flow to ftp_dir, e.g. by copying it first into some shared directory and then from there to ftp_dir. apol will show information flow paths among types. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zombie2.ncsc.mil (zombie2.ncsc.mil [144.51.88.133]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m9HJDTNF007363 for ; Fri, 17 Oct 2008 15:13:29 -0400 Received: from flower.research.telcordia.com (jazzdrum.ncsc.mil [144.51.5.7]) by zombie2.ncsc.mil (8.12.10/8.12.10) with ESMTP id m9HJC9DM025118 for ; Fri, 17 Oct 2008 19:12:09 GMT Received: from [127.0.0.1] (ar12-209.research.telcordia.com [192.4.12.209]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id m9HJDgSG026993 for ; Fri, 17 Oct 2008 15:13:43 -0400 (EDT) Message-ID: <48F8E3D4.50800@research.telcordia.com> Date: Fri, 17 Oct 2008 15:13:24 -0400 From: Sanjai Narain MIME-Version: 1.0 CC: selinux@tycho.nsa.gov Subject: Re: Protecting against inadvertent file copy References: <48F798BB.6070602@rubix.com> <1224186793.9247.139.camel@moss-spartans.epoch.ncsc.mil> <1224186905.9247.141.camel@moss-spartans.epoch.ncsc.mil> <48F85ECC.108@rubix.com> <1224245613.18694.26.camel@moss-spartans.epoch.ncsc.mil> <48F89EBE.6020800@rubix.com> <1224253435.19562.23.camel@moss-spartans.epoch.ncsc.mil> <48F8ABBC.9060808@rubix.com> <1224256522.19562.54.camel@moss-spartans.epoch.ncsc.mil> <48F8B58C.9040609@research.telcordia.com> <1224263695.19562.89.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1224263695.19562.89.camel@moss-spartans.epoch.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Hi Steve: Thanks very much! Best regards. -- Sanjai Stephen Smalley wrote: > On Fri, 2008-10-17 at 11:55 -0400, Sanjai Narain wrote: > >> Hello: I am just getting started with SELinux, and would very much >> appreciate an answer to the following question: >> >> Suppose there is a directory ftp_dir. If one wants to allow ftp of one's >> file to the outside world, one places it in ftp_dir. Suppose there is >> also a directory private_dir. One wants to prevent copying of any file >> in that directory into ftp_dir. In particular, one wants to say "do not >> allow cp from private_dir to ftp_dir". How would one go about expressing >> this in SELinux? >> > > By labeling the two directories with two different types, and defining > the roles/domains such that no domain can both read from private_dir and > write to ftp_dir. If you want to be strict about it, you'd further have > to ensure that there is no path by which information from private_dir > can eventually flow to ftp_dir, e.g. by copying it first into some > shared directory and then from there to ftp_dir. apol will show > information flow paths among types. > > -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.