checkmodule and MLS/MCS support

checkmodule and MLS/MCS support

[Russell Coker]

http://ramblingfoo.blogspot.com/2007/10/selinux-mlsmcs-support.html

Given that everyone who is working on SE Linux seems to be working on MCS and 
MLS systems, would it make sense to have the default checkmodule operation be 
to generate modules for MLS/MCS policy?

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: checkmodule and MLS/MCS support

[Joshua Brindle]

Russell Coker wrote:
> http://ramblingfoo.blogspot.com/2007/10/selinux-mlsmcs-support.html
>
> Given that everyone who is working on SE Linux seems to be working on MCS and 
> MLS systems, would it make sense to have the default checkmodule operation be 
> to generate modules for MLS/MCS policy?
>   

Changing defaults is a bad idea. Gentoo, for example, builds policy on 
end systems. Things would all of a sudden blow up on every policy 
installation if the default changed.


--
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: checkmodule and MLS/MCS support

[Stephen Smalley]

On Sun, 2007-10-14 at 14:52 -0400, Joshua Brindle wrote:
> Russell Coker wrote:
> > http://ramblingfoo.blogspot.com/2007/10/selinux-mlsmcs-support.html
> >
> > Given that everyone who is working on SE Linux seems to be working on MCS and 
> > MLS systems, would it make sense to have the default checkmodule operation be 
> > to generate modules for MLS/MCS policy?
> >   
> 
> Changing defaults is a bad idea. Gentoo, for example, builds policy on 
> end systems. Things would all of a sudden blow up on every policy 
> installation if the default changed.

True, but it does seem a bit unfortunate that one has to invoke it with
-M and -m for the common case.  audit2allow is another example where the
current default behaviors are no longer what we actually want as the
defaults.

I'd think that checkmodule could easily auto-detect base vs. non-base
from inspection of the source module, and could possibly auto-detect MLS
vs. non-MLS in a similar manner, even if only by using some syntactic
sugar pulled in via policy_module().

Although today that is all handled via the policy devel Makefile, right,
so the user just does a 'make -f /usr/share/selinux/devel/Makefile
foo.pp' and lets the Makefile figure out what options to enable as well
as hiding the multiple stages.

-- 
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: checkmodule and MLS/MCS support

[Christopher J. PeBenito]

On Mon, 2007-10-15 at 09:57 -0400, Stephen Smalley wrote:
> On Sun, 2007-10-14 at 14:52 -0400, Joshua Brindle wrote:
> > Russell Coker wrote:
> > > http://ramblingfoo.blogspot.com/2007/10/selinux-mlsmcs-support.html
> > >
> > > Given that everyone who is working on SE Linux seems to be working on MCS and 
> > > MLS systems, would it make sense to have the default checkmodule operation be 
> > > to generate modules for MLS/MCS policy?
> > >   
> > 
> > Changing defaults is a bad idea. Gentoo, for example, builds policy on 
> > end systems. Things would all of a sudden blow up on every policy 
> > installation if the default changed.
>
> True, but it does seem a bit unfortunate that one has to invoke it with
> -M and -m for the common case.  audit2allow is another example where the
> current default behaviors are no longer what we actually want as the
> defaults.
> 
> I'd think that checkmodule could easily auto-detect base vs. non-base
> from inspection of the source module, and could possibly auto-detect MLS
> vs. non-MLS in a similar manner, even if only by using some syntactic
> sugar pulled in via policy_module().

I think this could be problematic, if there are hand written modules
that only have TE rules (or generally speaking, non-refpolicy based
building) on a MCS/MLS system, it would be incorrectly detected as a
standard policy.

> Although today that is all handled via the policy devel Makefile, right,
> so the user just does a 'make -f /usr/share/selinux/devel/Makefile
> foo.pp' and lets the Makefile figure out what options to enable as well
> as hiding the multiple stages.

That is one of the goals of the refpolicy build infrastructure for local
policy, to build the modules with the correct settings.

I'll also echo Josh's above Gentoo comment.  By switching behavior,
we're just causing more infrastructure overhead to figure out what
compiler flags to set.  If we're willing to say that non-refpolicy
building is a tiny minority/corner case, then this results in
practically no gain, since the compiler option is already taken care of
by the refpolicy build infrastructure.

-- 
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: checkmodule and MLS/MCS support

[Russell Coker]

On Tuesday 16 October 2007 05:35, "Christopher J. PeBenito" 
<cpebenito@tresys.com> wrote:
> If we're willing to say that non-refpolicy
> building is a tiny minority/corner case, then this results in
> practically no gain, since the compiler option is already taken care of
> by the refpolicy build infrastructure.

This discussion started when I cited an example of a new SE Linux user who 
experienced great frustration due to the current mode of operation.

If we have some new users who decide that this is difficult enough that 
selinux=0 is the solution then solving the problem has some real benefits.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: checkmodule and MLS/MCS support

[Joshua Brindle]

Russell Coker wrote:
> On Tuesday 16 October 2007 05:35, "Christopher J. PeBenito" 
> <cpebenito@tresys.com> wrote:
>   
>> If we're willing to say that non-refpolicy
>> building is a tiny minority/corner case, then this results in
>> practically no gain, since the compiler option is already taken care of
>> by the refpolicy build infrastructure.
>>     
>
> This discussion started when I cited an example of a new SE Linux user who 
> experienced great frustration due to the current mode of operation.
>
> If we have some new users who decide that this is difficult enough that 
> selinux=0 is the solution then solving the problem has some real benefits.
>   

This is pretty extreme, its just a flag.


--
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: checkmodule and MLS/MCS support

[Russell Coker]

On Tuesday 16 October 2007 09:19, Joshua Brindle <method@manicmethod.com> 
wrote:
> > If we have some new users who decide that this is difficult enough that
> > selinux=0 is the solution then solving the problem has some real
> > benefits. 
>
> This is pretty extreme, its just a flag.

Yes, it is extreme, but it's what we are up against.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: checkmodule and MLS/MCS support

[Stephen Smalley]

On Tue, 2007-10-16 at 10:39 +1000, Russell Coker wrote:
> On Tuesday 16 October 2007 09:19, Joshua Brindle <method@manicmethod.com> 
> wrote:
> > > If we have some new users who decide that this is difficult enough that
> > > selinux=0 is the solution then solving the problem has some real
> > > benefits. 
> >
> > This is pretty extreme, its just a flag.
> 
> Yes, it is extreme, but it's what we are up against.

Do you have a specific suggestion on how to make checkmodule auto-detect
the right mode that wouldn't cause breakage for existing policies/users?
  
-- 
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: checkmodule and MLS/MCS support

[Karl MacMillan]

On Tue, 2007-10-16 at 08:10 -0400, Stephen Smalley wrote:
> On Tue, 2007-10-16 at 10:39 +1000, Russell Coker wrote:
> > On Tuesday 16 October 2007 09:19, Joshua Brindle <method@manicmethod.com> 
> > wrote:
> > > > If we have some new users who decide that this is difficult enough that
> > > > selinux=0 is the solution then solving the problem has some real
> > > > benefits. 
> > >
> > > This is pretty extreme, its just a flag.
> > 
> > Yes, it is extreme, but it's what we are up against.
> 
> Do you have a specific suggestion on how to make checkmodule auto-detect
> the right mode that wouldn't cause breakage for existing policies/users?
>   

What about a config file with defaults? For most systems the policy type
never changes.

Karl


--
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: checkmodule and MLS/MCS support

[Stephen Smalley]

On Tue, 2007-10-16 at 08:43 -0400, Karl MacMillan wrote:
> On Tue, 2007-10-16 at 08:10 -0400, Stephen Smalley wrote:
> > On Tue, 2007-10-16 at 10:39 +1000, Russell Coker wrote:
> > > On Tuesday 16 October 2007 09:19, Joshua Brindle <method@manicmethod.com> 
> > > wrote:
> > > > > If we have some new users who decide that this is difficult enough that
> > > > > selinux=0 is the solution then solving the problem has some real
> > > > > benefits. 
> > > >
> > > > This is pretty extreme, its just a flag.
> > > 
> > > Yes, it is extreme, but it's what we are up against.
> > 
> > Do you have a specific suggestion on how to make checkmodule auto-detect
> > the right mode that wouldn't cause breakage for existing policies/users?
> >   
> 
> What about a config file with defaults? For most systems the policy type
> never changes.

That's what the refpolicy build infrastructure uses - it installs a copy
of build.conf under /usr/share/selinux/devel/include and its Makefile
extracts information from it, checking for a -mcs or -mls component in
the TYPE value.  But if we are going to depend on that, then we might as
well just use the refpolicy Makefile in the first place and we don't
need anything in checkmodule itself.

Separate from that, there is /selinux/mls aka is_selinux_mls_enabled()
in libselinux, but that assumes one is building policy on a host with
the same kind of policy as the target host.  Dan's
top-level /usr/share/selinux/devel/Makefile actually uses that.
I don't think though that we want checkmodule to assume anything about
the build host, not even that it is running selinux at all.  checkmodule
and checkpolicy today work fine on non-selinux or selinux with
completely different policy.

So to do the above, we'd end up creating yet another config file that
duplicates what already exists in refpolicy, and we still couldn't
change the default within checkmodule since existing systems won't have
that new config file at all.  So I'm not sure what we'd buy there.
 
-- 
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: checkmodule and MLS/MCS support

[Karl MacMillan]

On Tue, 2007-10-16 at 08:51 -0400, Stephen Smalley wrote:
> On Tue, 2007-10-16 at 08:43 -0400, Karl MacMillan wrote:
> > On Tue, 2007-10-16 at 08:10 -0400, Stephen Smalley wrote:
> > > On Tue, 2007-10-16 at 10:39 +1000, Russell Coker wrote:
> > > > On Tuesday 16 October 2007 09:19, Joshua Brindle <method@manicmethod.com> 
> > > > wrote:
> > > > > > If we have some new users who decide that this is difficult enough that
> > > > > > selinux=0 is the solution then solving the problem has some real
> > > > > > benefits. 
> > > > >
> > > > > This is pretty extreme, its just a flag.
> > > > 
> > > > Yes, it is extreme, but it's what we are up against.
> > > 
> > > Do you have a specific suggestion on how to make checkmodule auto-detect
> > > the right mode that wouldn't cause breakage for existing policies/users?
> > >   
> > 
> > What about a config file with defaults? For most systems the policy type
> > never changes.
> 
> That's what the refpolicy build infrastructure uses - it installs a copy
> of build.conf under /usr/share/selinux/devel/include and its Makefile
> extracts information from it, checking for a -mcs or -mls component in
> the TYPE value.  But if we are going to depend on that, then we might as
> well just use the refpolicy Makefile in the first place and we don't
> need anything in checkmodule itself.
> 

I thought the whole issue was people running checkmodule directly. Yes
we should probably point them towards the refpolicy build, but some will
still likely use checkmodule.

Regardless, I don't think we should tie checkmodule to that config file.

> Separate from that, there is /selinux/mls aka is_selinux_mls_enabled()
> in libselinux, but that assumes one is building policy on a host with
> the same kind of policy as the target host.  Dan's
> top-level /usr/share/selinux/devel/Makefile actually uses that.
> I don't think though that we want checkmodule to assume anything about
> the build host, not even that it is running selinux at all.  checkmodule
> and checkpolicy today work fine on non-selinux or selinux with
> completely different policy.
> 

Agreed.

> So to do the above, we'd end up creating yet another config file that
> duplicates what already exists in refpolicy, and we still couldn't
> change the default within checkmodule since existing systems won't have
> that new config file at all.  So I'm not sure what we'd buy there.
>  

We'd buy the ability to omit some options if so desired (and I'm
assuming that the config file would be completely optional). I'm not
particularly concerned about this issue, but if others feel that it is
important to allow the bare checkmodule to run with fewer options this
seems like the easiest alternative. I'd rather do something dead simple
than try to guess the module type - which is both hard and very prone to
failure.

But as I said - I'm just not that concerned about this.

Karl


--
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: checkmodule and MLS/MCS support

[Russell Coker]

On Tuesday 16 October 2007 22:43, Karl MacMillan 
<kmacmillan@mentalrootkit.com> wrote:
> What about a config file with defaults? For most systems the policy type
> never changes.

Sounds fine to me.  Most distributions only support one of the two possible 
values for this option so they could supply a config file with the value they 
desire.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: checkmodule and MLS/MCS support

[Russell Coker]

On Monday 15 October 2007 04:52, Joshua Brindle <method@manicmethod.com> 
wrote:
> Russell Coker wrote:
> > http://ramblingfoo.blogspot.com/2007/10/selinux-mlsmcs-support.html
> >
> > Given that everyone who is working on SE Linux seems to be working on MCS
> > and MLS systems, would it make sense to have the default checkmodule
> > operation be to generate modules for MLS/MCS policy?
>
> Changing defaults is a bad idea. Gentoo, for example, builds policy on
> end systems. Things would all of a sudden blow up on every policy
> installation if the default changed.

No, it would only blow up systems that don't use the default if they don't 
explicitly use the correct option.

One possibility would be to have explicit options for MLS and non-MLS and the 
default be to detect what is in use on the current systems (most times you 
either produce policy for the current system or for an identical system).

Another possibility would be to have checkmodule produce a warning message if 
it was building a module that would not load on the current system.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

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