Question concerning building policy modules

Question concerning building policy modules

[James Carter]

Why isn't the Makefile and other information needed to build a module
separately in the appropriate /usr/share/selinux/<policy name>
directory?  This seems like the logical place for that information.  The
(not very well documented) "install-headers" make target in the
refpolicy Makefile does this.

Instead, the information to build a module for Fedora is in
the /usr/share/selinux/devel directory.  This directory would seem to be
independent of the policy type, even though it is only for building
Fedora policies.  This seems confusing.  The devel directory should have
stuff that all policies need or could use.

Wouldn't it make sense that if I wanted to build a module for the
current policy, I would use the Makefile in devel which would look
at /etc/selinux/config and include the Makefile for the current policy,
but if I wanted to compile for a particular policy, I would just use the
Makefile in its /usr/share directory?

-- 
James Carter <jwcart2@tycho.nsa.gov>
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.

Re: Question concerning building policy modules

[Daniel J Walsh]

James Carter wrote:
> Why isn't the Makefile and other information needed to build a module
> separately in the appropriate /usr/share/selinux/<policy name>
> directory?  This seems like the logical place for that information.  The
> (not very well documented) "install-headers" make target in the
> refpolicy Makefile does this.
>
> Instead, the information to build a module for Fedora is in
> the /usr/share/selinux/devel directory.  This directory would seem to be
> independent of the policy type, even though it is only for building
> Fedora policies.  This seems confusing.  The devel directory should have
> stuff that all policies need or could use.
>
> Wouldn't it make sense that if I wanted to build a module for the
> current policy, I would use the Makefile in devel which would look
> at /etc/selinux/config and include the Makefile for the current policy,
> but if I wanted to compile for a particular policy, I would just use the
> Makefile in its /usr/share directory?
>
>   
This is an old argument, between strict and targeted policy.   I did not 
like the idea of building
policy modules different for each type of policy,  Since almost everyone 
is exactly the same or would not work on different policies.  This seems 
to be proven to be correct as we move to strict/targeted policy merge. 

So you add a level of complexity with very little value.  Just imagine a 
third party shipping multiple policies for the
same package depending on an infinite number of policy packages.

targeted, strict, mls, olpc, CDS-ABC.

And almost guaranteed the same policy package would work for all or the 
package will only really work on one (MLS).  So I went with the least 
common denominator and only ship one devel package.  All interfaces for 
all packages ship. 




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

Re: Question concerning building policy modules

[Stephen Smalley]

On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
> James Carter wrote:
> > Why isn't the Makefile and other information needed to build a module
> > separately in the appropriate /usr/share/selinux/<policy name>
> > directory?  This seems like the logical place for that information.  The
> > (not very well documented) "install-headers" make target in the
> > refpolicy Makefile does this.
> >
> > Instead, the information to build a module for Fedora is in
> > the /usr/share/selinux/devel directory.  This directory would seem to be
> > independent of the policy type, even though it is only for building
> > Fedora policies.  This seems confusing.  The devel directory should have
> > stuff that all policies need or could use.
> >
> > Wouldn't it make sense that if I wanted to build a module for the
> > current policy, I would use the Makefile in devel which would look
> > at /etc/selinux/config and include the Makefile for the current policy,
> > but if I wanted to compile for a particular policy, I would just use the
> > Makefile in its /usr/share directory?
> >
> >   
> This is an old argument, between strict and targeted policy.   I did not 
> like the idea of building
> policy modules different for each type of policy,  Since almost everyone 
> is exactly the same or would not work on different policies.  This seems 
> to be proven to be correct as we move to strict/targeted policy merge. 
> 
> So you add a level of complexity with very little value.  Just imagine a 
> third party shipping multiple policies for the
> same package depending on an infinite number of policy packages.
> 
> targeted, strict, mls, olpc, CDS-ABC.
> 
> And almost guaranteed the same policy package would work for all or the 
> package will only really work on one (MLS).  So I went with the least 
> common denominator and only ship one devel package.  All interfaces for 
> all packages ship. 

But does this allow people using a policy other than targeted to build
loadable modules using the /usr/share/selinux/devel/Makefile?  Or do
they have to separately install refpolicy to do that?  That's the
problem, IIUC.

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

Re: Question concerning building policy modules

[Daniel J Walsh]

Stephen Smalley wrote:
> On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
>   
>> James Carter wrote:
>>     
>>> Why isn't the Makefile and other information needed to build a module
>>> separately in the appropriate /usr/share/selinux/<policy name>
>>> directory?  This seems like the logical place for that information.  The
>>> (not very well documented) "install-headers" make target in the
>>> refpolicy Makefile does this.
>>>
>>> Instead, the information to build a module for Fedora is in
>>> the /usr/share/selinux/devel directory.  This directory would seem to be
>>> independent of the policy type, even though it is only for building
>>> Fedora policies.  This seems confusing.  The devel directory should have
>>> stuff that all policies need or could use.
>>>
>>> Wouldn't it make sense that if I wanted to build a module for the
>>> current policy, I would use the Makefile in devel which would look
>>> at /etc/selinux/config and include the Makefile for the current policy,
>>> but if I wanted to compile for a particular policy, I would just use the
>>> Makefile in its /usr/share directory?
>>>
>>>   
>>>       
>> This is an old argument, between strict and targeted policy.   I did not 
>> like the idea of building
>> policy modules different for each type of policy,  Since almost everyone 
>> is exactly the same or would not work on different policies.  This seems 
>> to be proven to be correct as we move to strict/targeted policy merge. 
>>
>> So you add a level of complexity with very little value.  Just imagine a 
>> third party shipping multiple policies for the
>> same package depending on an infinite number of policy packages.
>>
>> targeted, strict, mls, olpc, CDS-ABC.
>>
>> And almost guaranteed the same policy package would work for all or the 
>> package will only really work on one (MLS).  So I went with the least 
>> common denominator and only ship one devel package.  All interfaces for 
>> all packages ship. 
>>     
>
> But does this allow people using a policy other than targeted to build
> loadable modules using the /usr/share/selinux/devel/Makefile?  Or do
> they have to separately install refpolicy to do that?  That's the
> problem, IIUC.
>
>   
If they can not it is a bug.  I have build policy modules on mls boxes 
in the
past.  The only thing the Makefile does is attempt to discover the 
policy on the system, and
set the flags correctly.  Then it calls into the generic refpolicy 
Makefile.  I have not tested
with specific MLS  calls.


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

Re: Question concerning building policy modules

[Christopher J. PeBenito]

On Wed, 2007-08-22 at 07:13 -0400, Stephen Smalley wrote:
> On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
> > James Carter wrote:
> > > Why isn't the Makefile and other information needed to build a module
> > > separately in the appropriate /usr/share/selinux/<policy name>
> > > directory?  This seems like the logical place for that information.  The
> > > (not very well documented) "install-headers" make target in the
> > > refpolicy Makefile does this.

Sorry, I was out of the office last week.  I'll add some docs about
setting up a policy module build via headers.

> > > Instead, the information to build a module for Fedora is in
> > > the /usr/share/selinux/devel directory.  This directory would seem to be
> > > independent of the policy type, even though it is only for building
> > > Fedora policies.  This seems confusing.  The devel directory should have
> > > stuff that all policies need or could use.
> > >
> > > Wouldn't it make sense that if I wanted to build a module for the
> > > current policy, I would use the Makefile in devel which would look
> > > at /etc/selinux/config and include the Makefile for the current policy,
> > > but if I wanted to compile for a particular policy, I would just use the
> > > Makefile in its /usr/share directory?
> > >
> > >   
> > This is an old argument, between strict and targeted policy.   I did not 
> > like the idea of building
> > policy modules different for each type of policy,  Since almost everyone 
> > is exactly the same or would not work on different policies.  This seems 
> > to be proven to be correct as we move to strict/targeted policy merge. 
> > 
> > So you add a level of complexity with very little value.  Just imagine a 
> > third party shipping multiple policies for the
> > same package depending on an infinite number of policy packages.
> > 
> > targeted, strict, mls, olpc, CDS-ABC.
> > 
> > And almost guaranteed the same policy package would work for all or the 
> > package will only really work on one (MLS).  So I went with the least 
> > common denominator and only ship one devel package.  All interfaces for 
> > all packages ship. 
> 
> But does this allow people using a policy other than targeted to build
> loadable modules using the /usr/share/selinux/devel/Makefile?  Or do
> they have to separately install refpolicy to do that?  That's the
> problem, IIUC.

It works because the headers are currently the same between the policy
types.  The only thing needed to change the behavior are the usual
build.conf settings.  Refpolicy upstream has the separate dirs
in /usr/share/selinux in case that changes, or 3rd parties want
different implementations per type.  Also it has a copy of the
build.conf so the infrastructure doesn't have to try to determine the
right settings.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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

Re: Question concerning building policy modules

[James Carter]

On Wed, 2007-08-22 at 12:57 +0000, Christopher J. PeBenito wrote:
> On Wed, 2007-08-22 at 07:13 -0400, Stephen Smalley wrote:
> > On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
> > > James Carter wrote:
> > > > Why isn't the Makefile and other information needed to build a module
> > > > separately in the appropriate /usr/share/selinux/<policy name>
> > > > directory?  This seems like the logical place for that information.  The
> > > > (not very well documented) "install-headers" make target in the
> > > > refpolicy Makefile does this.
> 
> Sorry, I was out of the office last week.  I'll add some docs about
> setting up a policy module build via headers.
> 
> > > > Instead, the information to build a module for Fedora is in
> > > > the /usr/share/selinux/devel directory.  This directory would seem to be
> > > > independent of the policy type, even though it is only for building
> > > > Fedora policies.  This seems confusing.  The devel directory should have
> > > > stuff that all policies need or could use.
> > > >
> > > > Wouldn't it make sense that if I wanted to build a module for the
> > > > current policy, I would use the Makefile in devel which would look
> > > > at /etc/selinux/config and include the Makefile for the current policy,
> > > > but if I wanted to compile for a particular policy, I would just use the
> > > > Makefile in its /usr/share directory?
> > > >
> > > >   
> > > This is an old argument, between strict and targeted policy.   I did not 
> > > like the idea of building
> > > policy modules different for each type of policy,  Since almost everyone 
> > > is exactly the same or would not work on different policies.  This seems 
> > > to be proven to be correct as we move to strict/targeted policy merge. 
> > > 
> > > So you add a level of complexity with very little value.  Just imagine a 
> > > third party shipping multiple policies for the
> > > same package depending on an infinite number of policy packages.
> > > 
> > > targeted, strict, mls, olpc, CDS-ABC.
> > > 
> > > And almost guaranteed the same policy package would work for all or the 
> > > package will only really work on one (MLS).  So I went with the least 
> > > common denominator and only ship one devel package.  All interfaces for 
> > > all packages ship. 
> > 
> > But does this allow people using a policy other than targeted to build
> > loadable modules using the /usr/share/selinux/devel/Makefile?  Or do
> > they have to separately install refpolicy to do that?  That's the
> > problem, IIUC.
> 
> It works because the headers are currently the same between the policy
> types.  
Which is not always the case.

> The only thing needed to change the behavior are the usual
> build.conf settings.  Refpolicy upstream has the separate dirs
> in /usr/share/selinux in case that changes, or 3rd parties want
> different implementations per type.  Also it has a copy of the
> build.conf so the infrastructure doesn't have to try to determine the
> right settings.
> 
-- 
James Carter <jwcart2@tycho.nsa.gov>
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.

Re: Question concerning building policy modules

[Christopher J. PeBenito]

On Wed, 2007-08-22 at 11:57 -0400, James Carter wrote:
> On Wed, 2007-08-22 at 12:57 +0000, Christopher J. PeBenito wrote:
> > On Wed, 2007-08-22 at 07:13 -0400, Stephen Smalley wrote:
> > > On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
> > > > James Carter wrote:
> > > > > Instead, the information to build a module for Fedora is in
> > > > > the /usr/share/selinux/devel directory.  This directory would seem to be
> > > > > independent of the policy type, even though it is only for building
> > > > > Fedora policies.  This seems confusing.  The devel directory should have
> > > > > stuff that all policies need or could use.
> > > > >
> > > > > Wouldn't it make sense that if I wanted to build a module for the
> > > > > current policy, I would use the Makefile in devel which would look
> > > > > at /etc/selinux/config and include the Makefile for the current policy,
> > > > > but if I wanted to compile for a particular policy, I would just use the
> > > > > Makefile in its /usr/share directory?
> > > > >
> > > > >   
> > > > This is an old argument, between strict and targeted policy.   I did not 
> > > > like the idea of building
> > > > policy modules different for each type of policy,  Since almost everyone 
> > > > is exactly the same or would not work on different policies.  This seems 
> > > > to be proven to be correct as we move to strict/targeted policy merge. 
> > > > 
> > > > So you add a level of complexity with very little value.  Just imagine a 
> > > > third party shipping multiple policies for the
> > > > same package depending on an infinite number of policy packages.
> > > > 
> > > > targeted, strict, mls, olpc, CDS-ABC.
> > > > 
> > > > And almost guaranteed the same policy package would work for all or the 
> > > > package will only really work on one (MLS).  So I went with the least 
> > > > common denominator and only ship one devel package.  All interfaces for 
> > > > all packages ship. 
> > > 
> > > But does this allow people using a policy other than targeted to build
> > > loadable modules using the /usr/share/selinux/devel/Makefile?  Or do
> > > they have to separately install refpolicy to do that?  That's the
> > > problem, IIUC.
> > 
> > It works because the headers are currently the same between the policy
> > types.  
> Which is not always the case.

Yes, which is why the upstream still has the separate sets.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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

Re: Question concerning building policy modules

[James Carter]

On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
> James Carter wrote:
> > Why isn't the Makefile and other information needed to build a module
> > separately in the appropriate /usr/share/selinux/<policy name>
> > directory?  This seems like the logical place for that information.  The
> > (not very well documented) "install-headers" make target in the
> > refpolicy Makefile does this.
> >
> > Instead, the information to build a module for Fedora is in
> > the /usr/share/selinux/devel directory.  This directory would seem to be
> > independent of the policy type, even though it is only for building
> > Fedora policies.  This seems confusing.  The devel directory should have
> > stuff that all policies need or could use.
> >
> > Wouldn't it make sense that if I wanted to build a module for the
> > current policy, I would use the Makefile in devel which would look
> > at /etc/selinux/config and include the Makefile for the current policy,
> > but if I wanted to compile for a particular policy, I would just use the
> > Makefile in its /usr/share directory?
> >
> >   
> This is an old argument, between strict and targeted policy.   I did not 
> like the idea of building
> policy modules different for each type of policy,  Since almost everyone 
> is exactly the same or would not work on different policies.  This seems 
> to be proven to be correct as we move to strict/targeted policy merge. 
> 
> So you add a level of complexity with very little value.  
I don't think my scheme is very complex and it is certainly less
confusing.  I will, however, concede that it does cause difficulties to
the poor person trying to package Fedora policy.  I suppose that
selinux-policy-devel would have to create strict/include,
targeted/include, and mls/include.

> Just imagine a 
> third party shipping multiple policies for the
> same package depending on an infinite number of policy packages.
> 
> targeted, strict, mls, olpc, CDS-ABC.
> 
> And almost guaranteed the same policy package would work for all or the 
> package will only really work on one (MLS).  So I went with the least 
> common denominator and only ship one devel package.  
Which is certainly easier.

This patch would at least make it possible to use the devel/Makefile
with refpolicy.  How about a compromise?

--- Makefile.old	2007-08-22 06:06:48.000000000 -0400
+++ Makefile	2007-08-22 07:51:27.000000000 -0400
@@ -16,9 +16,20 @@
 ifeq ($(NAME), mls)
 	NAME = strict
 	MCSFLAG = -mls
+	TYPE ?= $(NAME)${MCSFLAG}
+	HEADERDIR = $(SHAREDIR)/devel/include
 endif
 
-TYPE ?= $(NAME)${MCSFLAG}
-HEADERDIR := $(SHAREDIR)/devel/include
+ifeq ($(NAME), strict)
+	TYPE ?= $(NAME)${MCSFLAG}
+	HEADERDIR = $(SHAREDIR)/devel/include
+endif
+
+ifeq ($(NAME), targeted)
+	TYPE ?= $(NAME)${MCSFLAG}
+	HEADERDIR = $(SHAREDIR)/devel/include
+endif
+
+HEADERDIR ?= $(SHAREDIR)/$(NAME)/include
 include $(HEADERDIR)/Makefile
 

-- 
James Carter <jwcart2@tycho.nsa.gov>
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.

Re: Question concerning building policy modules

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Carter wrote:
> On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
>> James Carter wrote:
>>> Why isn't the Makefile and other information needed to build a module
>>> separately in the appropriate /usr/share/selinux/<policy name>
>>> directory?  This seems like the logical place for that information.  The
>>> (not very well documented) "install-headers" make target in the
>>> refpolicy Makefile does this.
>>>
>>> Instead, the information to build a module for Fedora is in
>>> the /usr/share/selinux/devel directory.  This directory would seem to be
>>> independent of the policy type, even though it is only for building
>>> Fedora policies.  This seems confusing.  The devel directory should have
>>> stuff that all policies need or could use.
>>>
>>> Wouldn't it make sense that if I wanted to build a module for the
>>> current policy, I would use the Makefile in devel which would look
>>> at /etc/selinux/config and include the Makefile for the current policy,
>>> but if I wanted to compile for a particular policy, I would just use the
>>> Makefile in its /usr/share directory?
>>>
>>>   
>> This is an old argument, between strict and targeted policy.   I did not 
>> like the idea of building
>> policy modules different for each type of policy,  Since almost everyone 
>> is exactly the same or would not work on different policies.  This seems 
>> to be proven to be correct as we move to strict/targeted policy merge. 
>>
>> So you add a level of complexity with very little value.  
> I don't think my scheme is very complex and it is certainly less
> confusing.  I will, however, concede that it does cause difficulties to
> the poor person trying to package Fedora policy.  I suppose that
> selinux-policy-devel would have to create strict/include,
> targeted/include, and mls/include.
> 
>> Just imagine a 
>> third party shipping multiple policies for the
>> same package depending on an infinite number of policy packages.
>>
>> targeted, strict, mls, olpc, CDS-ABC.
>>
>> And almost guaranteed the same policy package would work for all or the 
>> package will only really work on one (MLS).  So I went with the least 
>> common denominator and only ship one devel package.  
> Which is certainly easier.
> 
> This patch would at least make it possible to use the devel/Makefile
> with refpolicy.  How about a compromise?
> 
> --- Makefile.old	2007-08-22 06:06:48.000000000 -0400
> +++ Makefile	2007-08-22 07:51:27.000000000 -0400
> @@ -16,9 +16,20 @@
>  ifeq ($(NAME), mls)
>  	NAME = strict
>  	MCSFLAG = -mls
> +	TYPE ?= $(NAME)${MCSFLAG}
> +	HEADERDIR = $(SHAREDIR)/devel/include
>  endif
>  
> -TYPE ?= $(NAME)${MCSFLAG}
> -HEADERDIR := $(SHAREDIR)/devel/include
> +ifeq ($(NAME), strict)
> +	TYPE ?= $(NAME)${MCSFLAG}
> +	HEADERDIR = $(SHAREDIR)/devel/include
> +endif
> +
> +ifeq ($(NAME), targeted)
> +	TYPE ?= $(NAME)${MCSFLAG}
> +	HEADERDIR = $(SHAREDIR)/devel/include
> +endif
> +
> +HEADERDIR ?= $(SHAREDIR)/$(NAME)/include
>  include $(HEADERDIR)/Makefile
>  
> 
You want this change in F-7 and RHEL5?  This file has changed with the
merging of strict/targeted
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGzGT6rlYvE4MpobMRAsbdAJ0dvcs88uTp66brdQkdBMZHeyBvWQCfX1Cv
9XqoxwuEGqhQni3J9fs1Uzo=
=fgH+
-----END PGP SIGNATURE-----

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

Re: Question concerning building policy modules

[James Carter]

On Wed, 2007-08-22 at 12:31 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> James Carter wrote:
> > On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
> >> James Carter wrote:
> >>> Why isn't the Makefile and other information needed to build a module
> >>> separately in the appropriate /usr/share/selinux/<policy name>
> >>> directory?  This seems like the logical place for that information.  The
> >>> (not very well documented) "install-headers" make target in the
> >>> refpolicy Makefile does this.
> >>>
> >>> Instead, the information to build a module for Fedora is in
> >>> the /usr/share/selinux/devel directory.  This directory would seem to be
> >>> independent of the policy type, even though it is only for building
> >>> Fedora policies.  This seems confusing.  The devel directory should have
> >>> stuff that all policies need or could use.
> >>>
> >>> Wouldn't it make sense that if I wanted to build a module for the
> >>> current policy, I would use the Makefile in devel which would look
> >>> at /etc/selinux/config and include the Makefile for the current policy,
> >>> but if I wanted to compile for a particular policy, I would just use the
> >>> Makefile in its /usr/share directory?
> >>>
> >>>   
> >> This is an old argument, between strict and targeted policy.   I did not 
> >> like the idea of building
> >> policy modules different for each type of policy,  Since almost everyone 
> >> is exactly the same or would not work on different policies.  This seems 
> >> to be proven to be correct as we move to strict/targeted policy merge. 
> >>
> >> So you add a level of complexity with very little value.  
> > I don't think my scheme is very complex and it is certainly less
> > confusing.  I will, however, concede that it does cause difficulties to
> > the poor person trying to package Fedora policy.  I suppose that
> > selinux-policy-devel would have to create strict/include,
> > targeted/include, and mls/include.
> > 
> >> Just imagine a 
> >> third party shipping multiple policies for the
> >> same package depending on an infinite number of policy packages.
> >>
> >> targeted, strict, mls, olpc, CDS-ABC.
> >>
> >> And almost guaranteed the same policy package would work for all or the 
> >> package will only really work on one (MLS).  So I went with the least 
> >> common denominator and only ship one devel package.  
> > Which is certainly easier.
> > 
> > This patch would at least make it possible to use the devel/Makefile
> > with refpolicy.  How about a compromise?
> > 
> > --- Makefile.old	2007-08-22 06:06:48.000000000 -0400
> > +++ Makefile	2007-08-22 07:51:27.000000000 -0400
> > @@ -16,9 +16,20 @@
> >  ifeq ($(NAME), mls)
> >  	NAME = strict
> >  	MCSFLAG = -mls
> > +	TYPE ?= $(NAME)${MCSFLAG}
> > +	HEADERDIR = $(SHAREDIR)/devel/include
> >  endif
> >  
> > -TYPE ?= $(NAME)${MCSFLAG}
> > -HEADERDIR := $(SHAREDIR)/devel/include
> > +ifeq ($(NAME), strict)
> > +	TYPE ?= $(NAME)${MCSFLAG}
> > +	HEADERDIR = $(SHAREDIR)/devel/include
> > +endif
> > +
> > +ifeq ($(NAME), targeted)
> > +	TYPE ?= $(NAME)${MCSFLAG}
> > +	HEADERDIR = $(SHAREDIR)/devel/include
> > +endif
> > +
> > +HEADERDIR ?= $(SHAREDIR)/$(NAME)/include
> >  include $(HEADERDIR)/Makefile
> >  
> > 
> You want this change in F-7 and RHEL5?  This file has changed with the
> merging of strict/targeted

Sorry.  I am usually running refpolicy, which is probably why I have
problems.  Things work until refpolicy is not in sync with the policy
headers.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFGzGT6rlYvE4MpobMRAsbdAJ0dvcs88uTp66brdQkdBMZHeyBvWQCfX1Cv
> 9XqoxwuEGqhQni3J9fs1Uzo=
> =fgH+
> -----END PGP SIGNATURE-----
-- 
James Carter <jwcart2@tycho.nsa.gov>
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.

Re: Question concerning building policy modules

[James Carter]

On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
> James Carter wrote:
> > Why isn't the Makefile and other information needed to build a module
> > separately in the appropriate /usr/share/selinux/<policy name>
> > directory?  This seems like the logical place for that information.  The
> > (not very well documented) "install-headers" make target in the
> > refpolicy Makefile does this.
> >
> > Instead, the information to build a module for Fedora is in
> > the /usr/share/selinux/devel directory.  This directory would seem to be
> > independent of the policy type, even though it is only for building
> > Fedora policies.  This seems confusing.  The devel directory should have
> > stuff that all policies need or could use.
> >
> > Wouldn't it make sense that if I wanted to build a module for the
> > current policy, I would use the Makefile in devel which would look
> > at /etc/selinux/config and include the Makefile for the current policy,
> > but if I wanted to compile for a particular policy, I would just use the
> > Makefile in its /usr/share directory?
> >
> >   
> This is an old argument, between strict and targeted policy.   I did not 
> like the idea of building
> policy modules different for each type of policy,  Since almost everyone 
> is exactly the same or would not work on different policies.  This seems 
> to be proven to be correct as we move to strict/targeted policy merge. 
> 
> So you add a level of complexity with very little value.  Just imagine a 
> third party shipping multiple policies for the
> same package depending on an infinite number of policy packages.
> 
> targeted, strict, mls, olpc, CDS-ABC.
> 
> And almost guaranteed the same policy package would work for all or the 
> package will only really work on one (MLS).  So I went with the least 
> common denominator and only ship one devel package.  All interfaces for 
> all packages ship. 

On a different note, what is the policy going to be called when the
difference between strict and targeted is only whether a certain module
is loaded or not?  Will there only be one policy package?  Or maybe
there will be policy-mcs and policy-mls packages?


-- 
James Carter <jwcart2@tycho.nsa.gov>
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.

Re: Question concerning building policy modules

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Carter wrote:
> On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
>> James Carter wrote:
>>> Why isn't the Makefile and other information needed to build a module
>>> separately in the appropriate /usr/share/selinux/<policy name>
>>> directory?  This seems like the logical place for that information.  The
>>> (not very well documented) "install-headers" make target in the
>>> refpolicy Makefile does this.
>>>
>>> Instead, the information to build a module for Fedora is in
>>> the /usr/share/selinux/devel directory.  This directory would seem to be
>>> independent of the policy type, even though it is only for building
>>> Fedora policies.  This seems confusing.  The devel directory should have
>>> stuff that all policies need or could use.
>>>
>>> Wouldn't it make sense that if I wanted to build a module for the
>>> current policy, I would use the Makefile in devel which would look
>>> at /etc/selinux/config and include the Makefile for the current policy,
>>> but if I wanted to compile for a particular policy, I would just use the
>>> Makefile in its /usr/share directory?
>>>
>>>   
>> This is an old argument, between strict and targeted policy.   I did not 
>> like the idea of building
>> policy modules different for each type of policy,  Since almost everyone 
>> is exactly the same or would not work on different policies.  This seems 
>> to be proven to be correct as we move to strict/targeted policy merge. 
>>
>> So you add a level of complexity with very little value.  Just imagine a 
>> third party shipping multiple policies for the
>> same package depending on an infinite number of policy packages.
>>
>> targeted, strict, mls, olpc, CDS-ABC.
>>
>> And almost guaranteed the same policy package would work for all or the 
>> package will only really work on one (MLS).  So I went with the least 
>> common denominator and only ship one devel package.  All interfaces for 
>> all packages ship. 
> 
> On a different note, what is the policy going to be called when the
> difference between strict and targeted is only whether a certain module
> is loaded or not?  Will there only be one policy package?  Or maybe
> there will be policy-mcs and policy-mls packages?
> 
> 
We will be shipping just targeted policy and allow you to define any
types of users you want.  Removing the unconfined.pp file will remove
all of the unconfined domains.  As an alternative, you can change the
__default__ to a confined user type and then not allow users to login as
unconfined users.  (I find this much more interesting.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGzGjTrlYvE4MpobMRAkheAJ42YAU7SKF5ccxjdUhzabuVUMxLCQCghnTh
KvV/O9iy3+weMs9qKGQptqk=
=h0GG
-----END PGP SIGNATURE-----

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

Re: Question concerning building policy modules

[James Carter]

On Wed, 2007-08-22 at 12:48 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> James Carter wrote:
> > On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
> >> James Carter wrote:
> >>> Why isn't the Makefile and other information needed to build a module
> >>> separately in the appropriate /usr/share/selinux/<policy name>
> >>> directory?  This seems like the logical place for that information.  The
> >>> (not very well documented) "install-headers" make target in the
> >>> refpolicy Makefile does this.
> >>>
> >>> Instead, the information to build a module for Fedora is in
> >>> the /usr/share/selinux/devel directory.  This directory would seem to be
> >>> independent of the policy type, even though it is only for building
> >>> Fedora policies.  This seems confusing.  The devel directory should have
> >>> stuff that all policies need or could use.
> >>>
> >>> Wouldn't it make sense that if I wanted to build a module for the
> >>> current policy, I would use the Makefile in devel which would look
> >>> at /etc/selinux/config and include the Makefile for the current policy,
> >>> but if I wanted to compile for a particular policy, I would just use the
> >>> Makefile in its /usr/share directory?
> >>>
> >>>   
> >> This is an old argument, between strict and targeted policy.   I did not 
> >> like the idea of building
> >> policy modules different for each type of policy,  Since almost everyone 
> >> is exactly the same or would not work on different policies.  This seems 
> >> to be proven to be correct as we move to strict/targeted policy merge. 
> >>
> >> So you add a level of complexity with very little value.  Just imagine a 
> >> third party shipping multiple policies for the
> >> same package depending on an infinite number of policy packages.
> >>
> >> targeted, strict, mls, olpc, CDS-ABC.
> >>
> >> And almost guaranteed the same policy package would work for all or the 
> >> package will only really work on one (MLS).  So I went with the least 
> >> common denominator and only ship one devel package.  All interfaces for 
> >> all packages ship. 
> > 
> > On a different note, what is the policy going to be called when the
> > difference between strict and targeted is only whether a certain module
> > is loaded or not?  Will there only be one policy package?  Or maybe
> > there will be policy-mcs and policy-mls packages?
> > 
> > 
> We will be shipping just targeted policy and allow you to define any
> types of users you want.
 
Steve tells me that the name "targeted" is not going away, since
libselinux uses that name as the default policy name.

> Removing the unconfined.pp file will remove
> all of the unconfined domains.  As an alternative, you can change the
> __default__ to a confined user type and then not allow users to login as
> unconfined users.  (I find this much more interesting.)

It is.  
Is it working now?  I was under the impression that there were still some issues to be worked out.

-- 
James Carter <jwcart2@tycho.nsa.gov>
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.

Re: Question concerning building policy modules

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Carter wrote:
> On Wed, 2007-08-22 at 12:48 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> James Carter wrote:
>>> On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote:
>>>> James Carter wrote:
>>>>> Why isn't the Makefile and other information needed to build a module
>>>>> separately in the appropriate /usr/share/selinux/<policy name>
>>>>> directory?  This seems like the logical place for that information.  The
>>>>> (not very well documented) "install-headers" make target in the
>>>>> refpolicy Makefile does this.
>>>>>
>>>>> Instead, the information to build a module for Fedora is in
>>>>> the /usr/share/selinux/devel directory.  This directory would seem to be
>>>>> independent of the policy type, even though it is only for building
>>>>> Fedora policies.  This seems confusing.  The devel directory should have
>>>>> stuff that all policies need or could use.
>>>>>
>>>>> Wouldn't it make sense that if I wanted to build a module for the
>>>>> current policy, I would use the Makefile in devel which would look
>>>>> at /etc/selinux/config and include the Makefile for the current policy,
>>>>> but if I wanted to compile for a particular policy, I would just use the
>>>>> Makefile in its /usr/share directory?
>>>>>
>>>>>   
>>>> This is an old argument, between strict and targeted policy.   I did not 
>>>> like the idea of building
>>>> policy modules different for each type of policy,  Since almost everyone 
>>>> is exactly the same or would not work on different policies.  This seems 
>>>> to be proven to be correct as we move to strict/targeted policy merge. 
>>>>
>>>> So you add a level of complexity with very little value.  Just imagine a 
>>>> third party shipping multiple policies for the
>>>> same package depending on an infinite number of policy packages.
>>>>
>>>> targeted, strict, mls, olpc, CDS-ABC.
>>>>
>>>> And almost guaranteed the same policy package would work for all or the 
>>>> package will only really work on one (MLS).  So I went with the least 
>>>> common denominator and only ship one devel package.  All interfaces for 
>>>> all packages ship. 
>>> On a different note, what is the policy going to be called when the
>>> difference between strict and targeted is only whether a certain module
>>> is loaded or not?  Will there only be one policy package?  Or maybe
>>> there will be policy-mcs and policy-mls packages?
>>>
>>>
>> We will be shipping just targeted policy and allow you to define any
>> types of users you want.
>  
> Steve tells me that the name "targeted" is not going away, since
> libselinux uses that name as the default policy name.
> 
>> Removing the unconfined.pp file will remove
>> all of the unconfined domains.  As an alternative, you can change the
>> __default__ to a confined user type and then not allow users to login as
>> unconfined users.  (I find this much more interesting.)
> 
> It is.  
> Is it working now?  I was under the impression that there were still some issues to be worked out.
> 

I don't know what you mean by is is working now?  Rawhide-F8/Test1
policy has my version of the strict/targeted merge.  It supports

login user types of unconfined_t, sysadm_t, staff_t, user_t as well as
guest_t (terminal only, least priv user), and xguest_t (Xwindows Least
Priv user, with Firefox transition)

As well as super user types logadm_t, webadm_t, auditadm_t.

I have not tried to remove the unconfined.pp to see what happens.  I
have removed a lot of unconfined domains in this version of policy.
(gdm, xdm, ldconfig, modutils, sshd) are all confined now.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGzIIyrlYvE4MpobMRAoyCAJ0QNoCi/izOsnqxQ1iesJcHwZc1jACfSd6B
EHwfeh+hdyThXIL+d1asnx8=
=HwSZ
-----END PGP SIGNATURE-----

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

Re: Question concerning building policy modules

[Christopher J. PeBenito]

On Wed, 2007-08-22 at 14:36 -0400, Daniel J Walsh wrote:
> James Carter wrote:
> > On Wed, 2007-08-22 at 12:48 -0400, Daniel J Walsh wrote:
> >> James Carter wrote:
> >>> On a different note, what is the policy going to be called when the
> >>> difference between strict and targeted is only whether a certain module
> >>> is loaded or not?  Will there only be one policy package?  Or maybe
> >>> there will be policy-mcs and policy-mls packages?
> >>>
> >>>
> >> We will be shipping just targeted policy and allow you to define any
> >> types of users you want.
> >  
> > Steve tells me that the name "targeted" is not going away, since
> > libselinux uses that name as the default policy name.
> > 
> >> Removing the unconfined.pp file will remove
> >> all of the unconfined domains.  As an alternative, you can change the
> >> __default__ to a confined user type and then not allow users to login as
> >> unconfined users.  (I find this much more interesting.)
> > 
> > It is.  
> > Is it working now?  I was under the impression that there were still some issues to be worked out.

I'd say its early beta quality.  I worked around the current set of
toolchain bugs/limitations, which should get fixed by policyrep.  The
issue that I hit with genhomedircon emitting entries with invalid
contexts was fixed in policycoreutils 1.34.8.

> I don't know what you mean by is is working now?  Rawhide-F8/Test1
> policy has my version of the strict/targeted merge.  It supports

Note that its a superset of what is in the refpolicy branch.

> login user types of unconfined_t, sysadm_t, staff_t, user_t as well as
> guest_t (terminal only, least priv user), and xguest_t (Xwindows Least
> Priv user, with Firefox transition)
> 
> As well as super user types logadm_t, webadm_t, auditadm_t.
> 
> I have not tried to remove the unconfined.pp to see what happens.  I
> have removed a lot of unconfined domains in this version of policy.
> (gdm, xdm, ldconfig, modutils, sshd) are all confined now.

I did a diff against the strict policy in trunk and only found one issue
which I've fixed.  The only issue I can see is if you're using ricci, as
in trunk its unconfined even in strict, and in the merged policy its
only unconfined in targeted.  Dan, can you review ricci_modcluster_t?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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