Debian SE Linux status

Debian SE Linux status

[Russell Coker]

http://etbe.coker.com.au/2008/03/28/debian-se-linux-status/

Those of you who don't read Planet SE Linux but who are interested in Debian 
may want to read the above.

-- 
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: Debian SE Linux status

[Stephen Smalley]

On Fri, 2008-03-28 at 11:06 +1100, Russell Coker wrote:
> http://etbe.coker.com.au/2008/03/28/debian-se-linux-status/
> 
> Those of you who don't read Planet SE Linux but who are interested in Debian 
> may want to read the above.

Regarding the mismatch in policy version between your domU vs. dom0, you
should be able to build older policy versions via the config setting
in /etc/selinux/semanage.conf (modular build) or via the OUTPUT_POLICY=
setting in build.conf, overridable on the make command line (monolithic
build).

Or you could install newer selinux core userland in your dom0 such that
it can read and downgrade the latest policy to the one supported by your
kernel (libselinux policy load logic will convert a newer policy to an
older one at load time for you).

Agree that converting between non-MLS and MLS/MCS is very painful at
present.  Part of that we can fix (inappropriate dependencies in
semanage/seobject.py that should be querying the policy store via
libsemanage/libsepol rather than checking the running policy), and part
we cannot (still won't be able to switch the kind of policy at policy
reload in the kernel).  I'd actually prefer that we just always enable
the MLS engine and field for simplification, presenting the same
experience to all users, and ensuring that we are all testing the same
code paths.  I don't know how others feel about that though - I know
that Gentoo has historically not enabled MCS/MLS, and that upstream
refpolicy still defaults to not enabling it (standard).

I'm not sure why MLS support significantly increases policy build time
though.

-- 
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: Debian SE Linux status

[Joshua Brindle]

Stephen Smalley wrote:
> On Fri, 2008-03-28 at 11:06 +1100, Russell Coker wrote:
>   
>> http://etbe.coker.com.au/2008/03/28/debian-se-linux-status/
>>
>> Those of you who don't read Planet SE Linux but who are interested in Debian 
>> may want to read the above.
>>     
>
> Regarding the mismatch in policy version between your domU vs. dom0, you
> should be able to build older policy versions via the config setting
> in /etc/selinux/semanage.conf (modular build) or via the OUTPUT_POLICY=
> setting in build.conf, overridable on the make command line (monolithic
> build).
>
> Or you could install newer selinux core userland in your dom0 such that
> it can read and downgrade the latest policy to the one supported by your
> kernel (libselinux policy load logic will convert a newer policy to an
> older one at load time for you).
>
> Agree that converting between non-MLS and MLS/MCS is very painful at
> present.  Part of that we can fix (inappropriate dependencies in
> semanage/seobject.py that should be querying the policy store via
> libsemanage/libsepol rather than checking the running policy), and part
> we cannot (still won't be able to switch the kind of policy at policy
> reload in the kernel).  I'd actually prefer that we just always enable
> the MLS engine and field for simplification, presenting the same
> experience to all users, and ensuring that we are all testing the same
> code paths.  I don't know how others feel about that though - I know
> that Gentoo has historically not enabled MCS/MLS, and that upstream
> refpolicy still defaults to not enabling it (standard).
>
> I'm not sure why MLS support significantly increases policy build time
> though.
>   

Also note that the default (and only) policy on Ubuntu is non-mls.



--
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: Debian SE Linux status

[Stephen Smalley]

On Fri, 2008-03-28 at 08:56 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Fri, 2008-03-28 at 11:06 +1100, Russell Coker wrote:
> >   
> >> http://etbe.coker.com.au/2008/03/28/debian-se-linux-status/
> >>
> >> Those of you who don't read Planet SE Linux but who are interested in Debian 
> >> may want to read the above.
> >>     
> >
> > Regarding the mismatch in policy version between your domU vs. dom0, you
> > should be able to build older policy versions via the config setting
> > in /etc/selinux/semanage.conf (modular build) or via the OUTPUT_POLICY=
> > setting in build.conf, overridable on the make command line (monolithic
> > build).
> >
> > Or you could install newer selinux core userland in your dom0 such that
> > it can read and downgrade the latest policy to the one supported by your
> > kernel (libselinux policy load logic will convert a newer policy to an
> > older one at load time for you).
> >
> > Agree that converting between non-MLS and MLS/MCS is very painful at
> > present.  Part of that we can fix (inappropriate dependencies in
> > semanage/seobject.py that should be querying the policy store via
> > libsemanage/libsepol rather than checking the running policy), and part
> > we cannot (still won't be able to switch the kind of policy at policy
> > reload in the kernel).  I'd actually prefer that we just always enable
> > the MLS engine and field for simplification, presenting the same
> > experience to all users, and ensuring that we are all testing the same
> > code paths.  I don't know how others feel about that though - I know
> > that Gentoo has historically not enabled MCS/MLS, and that upstream
> > refpolicy still defaults to not enabling it (standard).
> >
> > I'm not sure why MLS support significantly increases policy build time
> > though.
> >   
> 
> Also note that the default (and only) policy on Ubuntu is non-mls.

Why?

I think we set ourselves up for application and user confusion and
incompatibility by having different context formats in the different
distributions that support SELinux.  And it definitely creates a
maintenance burden - having to test both cases always.  Which apparently
we aren't doing a good job of, as semanage user -a will presently always
fail on a non-MCS/MLS system.

-- 
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: Debian SE Linux status

[James Carter]

On Fri, 2008-03-28 at 08:59 -0400, Stephen Smalley wrote:
> On Fri, 2008-03-28 at 08:56 -0400, Joshua Brindle wrote:
> > Stephen Smalley wrote:
> > > On Fri, 2008-03-28 at 11:06 +1100, Russell Coker wrote:
> > >   
> > >> http://etbe.coker.com.au/2008/03/28/debian-se-linux-status/
> > >>
> > >> Those of you who don't read Planet SE Linux but who are interested in Debian 
> > >> may want to read the above.
> > >>     
> > >
> > > Regarding the mismatch in policy version between your domU vs. dom0, you
> > > should be able to build older policy versions via the config setting
> > > in /etc/selinux/semanage.conf (modular build) or via the OUTPUT_POLICY=
> > > setting in build.conf, overridable on the make command line (monolithic
> > > build).
> > >
> > > Or you could install newer selinux core userland in your dom0 such that
> > > it can read and downgrade the latest policy to the one supported by your
> > > kernel (libselinux policy load logic will convert a newer policy to an
> > > older one at load time for you).
> > >
> > > Agree that converting between non-MLS and MLS/MCS is very painful at
> > > present.  Part of that we can fix (inappropriate dependencies in
> > > semanage/seobject.py that should be querying the policy store via
> > > libsemanage/libsepol rather than checking the running policy), and part
> > > we cannot (still won't be able to switch the kind of policy at policy
> > > reload in the kernel).  I'd actually prefer that we just always enable
> > > the MLS engine and field for simplification, presenting the same
> > > experience to all users, and ensuring that we are all testing the same
> > > code paths.  

I thought that MLS just added additional code paths.  Are there code
paths that are only taken for non-MLS policies?

> I don't know how others feel about that though - I know
> > > that Gentoo has historically not enabled MCS/MLS, and that upstream
> > > refpolicy still defaults to not enabling it (standard).
> > >
> > > I'm not sure why MLS support significantly increases policy build time
> > > though.
> > >   

Isn't that an argument for keeping non-MLS support? ;)

What is the difference in overhead between an MLS and a non-MLS system?
Would there be a noticeable difference in resources used by a non-MLS
system and one that had a single level of s0 and no categories?  (Can
you actually define only one level and no categories?)

> > 
> > Also note that the default (and only) policy on Ubuntu is non-mls.
> 
> Why?
> 
> I think we set ourselves up for application and user confusion and
> incompatibility by having different context formats in the different
> distributions that support SELinux.  And it definitely creates a
> maintenance burden - having to test both cases always.  Which apparently
> we aren't doing a good job of, as semanage user -a will presently always
> fail on a non-MCS/MLS system.
> 

I don't think that we should address deficiencies in the tool-chain by
reducing flexibility.

-- 
James Carter <jwcart2@epoch.ncsc.mil>
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: Debian SE Linux status

[Stephen Smalley]

On Fri, 2008-03-28 at 09:36 -0400, James Carter wrote:
> On Fri, 2008-03-28 at 08:59 -0400, Stephen Smalley wrote:
> > On Fri, 2008-03-28 at 08:56 -0400, Joshua Brindle wrote:
> > > Stephen Smalley wrote:
> > > > On Fri, 2008-03-28 at 11:06 +1100, Russell Coker wrote:
> > > >   
> > > >> http://etbe.coker.com.au/2008/03/28/debian-se-linux-status/
> > > >>
> > > >> Those of you who don't read Planet SE Linux but who are interested in Debian 
> > > >> may want to read the above.
> > > >>     
> > > >
> > > > Regarding the mismatch in policy version between your domU vs. dom0, you
> > > > should be able to build older policy versions via the config setting
> > > > in /etc/selinux/semanage.conf (modular build) or via the OUTPUT_POLICY=
> > > > setting in build.conf, overridable on the make command line (monolithic
> > > > build).
> > > >
> > > > Or you could install newer selinux core userland in your dom0 such that
> > > > it can read and downgrade the latest policy to the one supported by your
> > > > kernel (libselinux policy load logic will convert a newer policy to an
> > > > older one at load time for you).
> > > >
> > > > Agree that converting between non-MLS and MLS/MCS is very painful at
> > > > present.  Part of that we can fix (inappropriate dependencies in
> > > > semanage/seobject.py that should be querying the policy store via
> > > > libsemanage/libsepol rather than checking the running policy), and part
> > > > we cannot (still won't be able to switch the kind of policy at policy
> > > > reload in the kernel).  I'd actually prefer that we just always enable
> > > > the MLS engine and field for simplification, presenting the same
> > > > experience to all users, and ensuring that we are all testing the same
> > > > code paths.  
> 
> I thought that MLS just added additional code paths.  Are there code
> paths that are only taken for non-MLS policies?
> 
> > I don't know how others feel about that though - I know
> > > > that Gentoo has historically not enabled MCS/MLS, and that upstream
> > > > refpolicy still defaults to not enabling it (standard).
> > > >
> > > > I'm not sure why MLS support significantly increases policy build time
> > > > though.
> > > >   
> 
> Isn't that an argument for keeping non-MLS support? ;)

I don't believe that it actually does significantly increase policy
build time (or if it does, that would be a bug).  Possibly Russell just
means that building both MLS and non-MLS takes longer, or that the mls
modules.conf includes more modules, or something along those lines?

> What is the difference in overhead between an MLS and a non-MLS system?
> Would there be a noticeable difference in resources used by a non-MLS
> system and one that had a single level of s0 and no categories?  (Can
> you actually define only one level and no categories?)

If you don't define any actual MLS constraints in policy, then it
shouldn't impose any real runtime overhead (and even when you do, that's
all masked by the AVC, of course).  Yes, you should be able to define
just one level and no categories, although I doubt that defining
categories significantly expands the policy (just because they are
defined doesn't mean you have to use them in contexts).

With the mainstreaming of the MLS support and turning it from a
compile-time option into a runtime load option, there isn't any real
difference in the in-core context structures even when you have MLS
disabled.  So you aren't saving anything there.

> > > Also note that the default (and only) policy on Ubuntu is non-mls.
> > 
> > Why?
> > 
> > I think we set ourselves up for application and user confusion and
> > incompatibility by having different context formats in the different
> > distributions that support SELinux.  And it definitely creates a
> > maintenance burden - having to test both cases always.  Which apparently
> > we aren't doing a good job of, as semanage user -a will presently always
> > fail on a non-MCS/MLS system.
> > 
> 
> I don't think that we should address deficiencies in the tool-chain by
> reducing flexibility.

No - it isn't just deficiencies in the tool chain.  It increases our
maintenance burden to have multiple options and code paths to exercise,
and it is user- and application visible since it affects the context
format.

-- 
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: Debian SE Linux status

[James Carter]

On Fri, 2008-03-28 at 09:51 -0400, Stephen Smalley wrote:
> On Fri, 2008-03-28 at 09:36 -0400, James Carter wrote:
> > On Fri, 2008-03-28 at 08:59 -0400, Stephen Smalley wrote:
> > > On Fri, 2008-03-28 at 08:56 -0400, Joshua Brindle wrote:
> > > > Stephen Smalley wrote:
> > > > > On Fri, 2008-03-28 at 11:06 +1100, Russell Coker wrote:
> > > > >   
> > > > >> http://etbe.coker.com.au/2008/03/28/debian-se-linux-status/
> > > > >>
> > > > >> Those of you who don't read Planet SE Linux but who are interested in Debian 
> > > > >> may want to read the above.
> > > > >>     
> > > > >
> > > > > Regarding the mismatch in policy version between your domU vs. dom0, you
> > > > > should be able to build older policy versions via the config setting
> > > > > in /etc/selinux/semanage.conf (modular build) or via the OUTPUT_POLICY=
> > > > > setting in build.conf, overridable on the make command line (monolithic
> > > > > build).
> > > > >
> > > > > Or you could install newer selinux core userland in your dom0 such that
> > > > > it can read and downgrade the latest policy to the one supported by your
> > > > > kernel (libselinux policy load logic will convert a newer policy to an
> > > > > older one at load time for you).
> > > > >
> > > > > Agree that converting between non-MLS and MLS/MCS is very painful at
> > > > > present.  Part of that we can fix (inappropriate dependencies in
> > > > > semanage/seobject.py that should be querying the policy store via
> > > > > libsemanage/libsepol rather than checking the running policy), and part
> > > > > we cannot (still won't be able to switch the kind of policy at policy
> > > > > reload in the kernel).  I'd actually prefer that we just always enable
> > > > > the MLS engine and field for simplification, presenting the same
> > > > > experience to all users, and ensuring that we are all testing the same
> > > > > code paths.  
> > 
> > I thought that MLS just added additional code paths.  Are there code
> > paths that are only taken for non-MLS policies?
> > 
> > > I don't know how others feel about that though - I know
> > > > > that Gentoo has historically not enabled MCS/MLS, and that upstream
> > > > > refpolicy still defaults to not enabling it (standard).
> > > > >
> > > > > I'm not sure why MLS support significantly increases policy build time
> > > > > though.
> > > > >   
> > 
> > Isn't that an argument for keeping non-MLS support? ;)
> 
> I don't believe that it actually does significantly increase policy
> build time (or if it does, that would be a bug).  Possibly Russell just
> means that building both MLS and non-MLS takes longer, or that the mls
> modules.conf includes more modules, or something along those lines?
> 
> > What is the difference in overhead between an MLS and a non-MLS system?
> > Would there be a noticeable difference in resources used by a non-MLS
> > system and one that had a single level of s0 and no categories?  (Can
> > you actually define only one level and no categories?)
> 
> If you don't define any actual MLS constraints in policy, then it
> shouldn't impose any real runtime overhead (and even when you do, that's
> all masked by the AVC, of course).  Yes, you should be able to define
> just one level and no categories, although I doubt that defining
> categories significantly expands the policy (just because they are
> defined doesn't mean you have to use them in contexts).

You can't.

m4 -D enable_mls -D distro_redhat -D mls_num_sens=1 -D mls_num_cats=0 -D
mcs_num_cats=256 -D hide_broken_symptoms -D self_contained_policy
policy/flask/security_classes policy/flask/initial_sids
policy/flask/access_vectors policy/support/file_patterns.spt
policy/support/ipc_patterns.spt policy/support/loadable_module.spt
policy/support/misc_macros.spt policy/support/misc_patterns.spt
policy/support/mls_mcs_macros.spt policy/support/obj_perm_sets.spt
policy/mls policy/mcs > tmp/pre_te_files.conf
m4: memory exhausted
make: *** [tmp/pre_te_files.conf] Error 1

But I see your point.  There isn't going to be any appreciable overhead
in defining additional levels and categories that aren't used.  And
there is really no gain in running a non-MLS system as compared to an
MLS system that is running everything at the same level and which
doesn't have any MLS constraints.

> 
> With the mainstreaming of the MLS support and turning it from a
> compile-time option into a runtime load option, there isn't any real
> difference in the in-core context structures even when you have MLS
> disabled.  So you aren't saving anything there.
> 
> > > > Also note that the default (and only) policy on Ubuntu is non-mls.
> > > 
> > > Why?
> > > 
> > > I think we set ourselves up for application and user confusion and
> > > incompatibility by having different context formats in the different
> > > distributions that support SELinux.  And it definitely creates a
> > > maintenance burden - having to test both cases always.  Which apparently
> > > we aren't doing a good job of, as semanage user -a will presently always
> > > fail on a non-MCS/MLS system.
> > > 
> > 
> > I don't think that we should address deficiencies in the tool-chain by
> > reducing flexibility.
> 
> No - it isn't just deficiencies in the tool chain.  It increases our
> maintenance burden to have multiple options and code paths to exercise,
> and it is user- and application visible since it affects the context
> format.
> 

What about the differences between monolithic policy and modular policy?
Isn't that a maintenance burden as well?  A monolithic policy can't be
managed with semange, so that is a user visible difference as well.

-- 
James Carter <jwcart2@epoch.ncsc.mil>
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: Debian SE Linux status

[Stephen Smalley]

On Fri, 2008-03-28 at 10:32 -0400, James Carter wrote:
> On Fri, 2008-03-28 at 09:51 -0400, Stephen Smalley wrote:
> > On Fri, 2008-03-28 at 09:36 -0400, James Carter wrote:
> > > On Fri, 2008-03-28 at 08:59 -0400, Stephen Smalley wrote:
> > > > On Fri, 2008-03-28 at 08:56 -0400, Joshua Brindle wrote:
> > > > > Stephen Smalley wrote:
> > > > > > On Fri, 2008-03-28 at 11:06 +1100, Russell Coker wrote:
> > > > > >   
> > > > > >> http://etbe.coker.com.au/2008/03/28/debian-se-linux-status/
> > > > > >>
> > > > > >> Those of you who don't read Planet SE Linux but who are interested in Debian 
> > > > > >> may want to read the above.
> > > > > >>     
> > > > > >
> > > > > > Regarding the mismatch in policy version between your domU vs. dom0, you
> > > > > > should be able to build older policy versions via the config setting
> > > > > > in /etc/selinux/semanage.conf (modular build) or via the OUTPUT_POLICY=
> > > > > > setting in build.conf, overridable on the make command line (monolithic
> > > > > > build).
> > > > > >
> > > > > > Or you could install newer selinux core userland in your dom0 such that
> > > > > > it can read and downgrade the latest policy to the one supported by your
> > > > > > kernel (libselinux policy load logic will convert a newer policy to an
> > > > > > older one at load time for you).
> > > > > >
> > > > > > Agree that converting between non-MLS and MLS/MCS is very painful at
> > > > > > present.  Part of that we can fix (inappropriate dependencies in
> > > > > > semanage/seobject.py that should be querying the policy store via
> > > > > > libsemanage/libsepol rather than checking the running policy), and part
> > > > > > we cannot (still won't be able to switch the kind of policy at policy
> > > > > > reload in the kernel).  I'd actually prefer that we just always enable
> > > > > > the MLS engine and field for simplification, presenting the same
> > > > > > experience to all users, and ensuring that we are all testing the same
> > > > > > code paths.  
> > > 
> > > I thought that MLS just added additional code paths.  Are there code
> > > paths that are only taken for non-MLS policies?
> > > 
> > > > I don't know how others feel about that though - I know
> > > > > > that Gentoo has historically not enabled MCS/MLS, and that upstream
> > > > > > refpolicy still defaults to not enabling it (standard).
> > > > > >
> > > > > > I'm not sure why MLS support significantly increases policy build time
> > > > > > though.
> > > > > >   
> > > 
> > > Isn't that an argument for keeping non-MLS support? ;)
> > 
> > I don't believe that it actually does significantly increase policy
> > build time (or if it does, that would be a bug).  Possibly Russell just
> > means that building both MLS and non-MLS takes longer, or that the mls
> > modules.conf includes more modules, or something along those lines?
> > 
> > > What is the difference in overhead between an MLS and a non-MLS system?
> > > Would there be a noticeable difference in resources used by a non-MLS
> > > system and one that had a single level of s0 and no categories?  (Can
> > > you actually define only one level and no categories?)
> > 
> > If you don't define any actual MLS constraints in policy, then it
> > shouldn't impose any real runtime overhead (and even when you do, that's
> > all masked by the AVC, of course).  Yes, you should be able to define
> > just one level and no categories, although I doubt that defining
> > categories significantly expands the policy (just because they are
> > defined doesn't mean you have to use them in contexts).
> 
> You can't.
> 
> m4 -D enable_mls -D distro_redhat -D mls_num_sens=1 -D mls_num_cats=0 -D
> mcs_num_cats=256 -D hide_broken_symptoms -D self_contained_policy
> policy/flask/security_classes policy/flask/initial_sids
> policy/flask/access_vectors policy/support/file_patterns.spt
> policy/support/ipc_patterns.spt policy/support/loadable_module.spt
> policy/support/misc_macros.spt policy/support/misc_patterns.spt
> policy/support/mls_mcs_macros.spt policy/support/obj_perm_sets.spt
> policy/mls policy/mcs > tmp/pre_te_files.conf
> m4: memory exhausted
> make: *** [tmp/pre_te_files.conf] Error 1

Ok - I only glanced at the checkpolicy grammar, which allows no
categories to be defined.  But I suppose that refpolicy build
infrastructure and likely even the libsepol and kernel code will be
unhappy with zero categories presently.

> But I see your point.  There isn't going to be any appreciable overhead
> in defining additional levels and categories that aren't used.  And
> there is really no gain in running a non-MLS system as compared to an
> MLS system that is running everything at the same level and which
> doesn't have any MLS constraints.

Yes, that's the point.

> > 
> > With the mainstreaming of the MLS support and turning it from a
> > compile-time option into a runtime load option, there isn't any real
> > difference in the in-core context structures even when you have MLS
> > disabled.  So you aren't saving anything there.
> > 
> > > > > Also note that the default (and only) policy on Ubuntu is non-mls.
> > > > 
> > > > Why?
> > > > 
> > > > I think we set ourselves up for application and user confusion and
> > > > incompatibility by having different context formats in the different
> > > > distributions that support SELinux.  And it definitely creates a
> > > > maintenance burden - having to test both cases always.  Which apparently
> > > > we aren't doing a good job of, as semanage user -a will presently always
> > > > fail on a non-MCS/MLS system.
> > > > 
> > > 
> > > I don't think that we should address deficiencies in the tool-chain by
> > > reducing flexibility.
> > 
> > No - it isn't just deficiencies in the tool chain.  It increases our
> > maintenance burden to have multiple options and code paths to exercise,
> > and it is user- and application visible since it affects the context
> > format.
> > 
> 
> What about the differences between monolithic policy and modular policy?
> Isn't that a maintenance burden as well?  A monolithic policy can't be
> managed with semange, so that is a user visible difference as well.

That was a technology transition for SELinux, one that all the
distributions went through.  All the distributions now use modular,
managed policy by default, and monolithic policy support remains for
legacy systems (e.g. RHEL4) and possibly for embedded systems since
modular, managed policy presently has a real cost to it (unlike the MLS
support).

Similarly, MLS has gone from a compile-time only, universally disabled
option to a load-time, enabled-by-default option in the majority of
SELinux systems today.

So possibly the maintenance burden argument doesn't hold up, since we'd
need to retain such support anyway for legacy systems - although we
could at least deprecate it and eventually drop it from the trunk,
leaving it only in some legacy stable branch.  But the common user
experience argument seems valid to me.

-- 
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: Debian SE Linux status

[Russell Coker]

On Saturday 29 March 2008 00:51, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > Isn't that an argument for keeping non-MLS support? ;)
>
> I don't believe that it actually does significantly increase policy
> build time (or if it does, that would be a bug).  Possibly Russell just
> means that building both MLS and non-MLS takes longer, or that the mls
> modules.conf includes more modules, or something along those lines?

Yes.  Currently I have it building three policy packages, strict, targeted, 
and mls.  This takes 50% longer than just strict and targeted.  But if we go 
to a single policy for strict/targeted and a policy for mls then we would 
have the same build times as before.

-- 
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: Debian SE Linux status

[Joshua Brindle]

Russell Coker wrote:
> On Saturday 29 March 2008 00:51, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>   
>>> Isn't that an argument for keeping non-MLS support? ;)
>>>       
>> I don't believe that it actually does significantly increase policy
>> build time (or if it does, that would be a bug).  Possibly Russell just
>> means that building both MLS and non-MLS takes longer, or that the mls
>> modules.conf includes more modules, or something along those lines?
>>     
>
> Yes.  Currently I have it building three policy packages, strict, targeted, 
> and mls.  This takes 50% longer than just strict and targeted.  But if we go 
> to a single policy for strict/targeted and a policy for mls then we would 
> have the same build times as before

Strict and targeted don't mean anything anymore. If you want targeted 
behavior you insert the unconfined module into the standard policy.



--
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: Debian SE Linux status

[Russell Coker]

On Saturday 29 March 2008 02:19, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> That was a technology transition for SELinux, one that all the
> distributions went through.  All the distributions now use modular,
> managed policy by default, and monolithic policy support remains for
> legacy systems (e.g. RHEL4) and possibly for embedded systems since
> modular, managed policy presently has a real cost to it (unlike the MLS
> support).

Nowadays it seems that a very common case of development for embedded systems 
(probably the most common case) is to use some sort of bigger system to do 
the development and then deploy on the small system.  An example of this is 
the Familiar developers who built iPaQ machines with hard drives...

Given the use of such a bigger system, which could even have a different CPU - 
AFAIK there are no CPU specific requirements in the policy build (or if they 
are then it's a bug) you could have a modular managed policy development 
process that results in copying the policy.N file to the destination machine.

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