[Buildroot] SELinux Buildroot Additions

[Buildroot] SELinux Buildroot Additions

[clshotwe at rockwellcollins.com]

I would like to get some feedback on adding SELinux support to Buildroot. 
This would involve adding several packages, modifying the .mk files for 
several packages to include SELinux support, and adding generic defconfigs 
to use as examples.  I would like to have defconfigs for QEMU targets 
(x86, ARM, PPC) along with a Pandaboard and another couple hardware 
targets.  The package selection for a functional SELinux system is a 
little complex so the example defconfigs would be nice to use as examples.

Would this be a welcomed addition to Buildroot?  I would like to submit a 
set of patches to first add the new packages, then modify existing 
packages, and then add in the example defconfigs one at a time.  Is this 
the best approach to take?

Thanks,
Clayton

Clayton Shotwell
Software Engineer 
clshotwe at rockwellcollins.com
www.rockwellcollins.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130827/997c18ef/attachment.html>

[Buildroot] SELinux Buildroot Additions

[Thomas Petazzoni]

Hello Clayton,

On Tue, 27 Aug 2013 11:20:25 -0500, clshotwe at rockwellcollins.com wrote:

> I would like to get some feedback on adding SELinux support to Buildroot. 
> This would involve adding several packages, modifying the .mk files for 
> several packages to include SELinux support, and adding generic defconfigs 
> to use as examples.  I would like to have defconfigs for QEMU targets 
> (x86, ARM, PPC) along with a Pandaboard and another couple hardware 
> targets.  The package selection for a functional SELinux system is a 
> little complex so the example defconfigs would be nice to use as examples.
> 
> Would this be a welcomed addition to Buildroot?  I would like to submit a 
> set of patches to first add the new packages, then modify existing 
> packages, and then add in the example defconfigs one at a time.  Is this 
> the best approach to take?

Having SELinux support in Buildroot would definitely be interesting,
especially if you're using it for some projects!

Adding several packages is obviously fine. I guess you've already find
the relevant documentation on how to add new packages to Buildroot.

Modifying existing .mk files of other packages to enable SELinux
support is also perfectly fine. We'll have to see if we need a global
knob to enable/disable SELinux, or if a per-package configuration is
needed, or if the fact that a given package is enabled or disabled is a
good enough indication of whether the user wants SELinux support. I
guess we'll have to discuss this once we see your patches.

The defconfig part is probably the most problematic one. Until now, our
policy about defconfigs is that they should just build the minimal set
of things for a particular hardware platform to build: toolchain,
kernel, bootloader, and minimal rootfs with Busybox. We've refrained
from including other features in our defconfigs, because the definition
of what a good configuration is for a particular platform is very
use-case and user-dependent. Someone will want Qt, someone else will
want X.org. Someone will want Busybox, someone else will want the
full-featured Bash and Coreutils. Someone will want udev, someone else
will want mdev. Someone will want Busybox init, someone else will want
systemd. How to make a good choice, without having a proliferation of
highly specific choices, is difficult.

Regarding SELinux and defconfigs, I see three options moving forward:

 *) We've been discussing some time ago the need to have some kind of
    "demos" defconfig, mainly as part of the work done by Spenser
    Gilliland on ARM OpenGL support in Buildroot. Those would be a
    separate set of defconfig, clearly identified as "this demonstrates
    some particular feature, on some particular platform, just for the
    sake of demonstrating this feature". We however haven't decided
    where to store those configurations, how to handle them compared to
    the regular defconfigs, etc.

 *) Make the SELinux configuration in menuconfig simple enough that a
    demonstration defconfig is not needed. You're mentioning that the
    configuration to get a working SELinux system is a little bit
    complex, and that's why a demo defconfig is needed. Maybe there's
    something we can do here to make this SELinux configuration so
    simple that a demo defconfig will no longer be needed?

 *) Add some details in the Buildroot manual on how to use SELinux.
    Generally speaking, the manual could contain more details on how to
    use a particular Buildroot package or feature. SELinux could be one
    of them.

Of course, none of those options are mutually exclusive!

So, I believe we can get started with the first two steps, get an
understanding of the configuration complexity, and see what is the best
course of action for the last step.

What do you think about this?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] SELinux Buildroot Additions

[clshotwe at rockwellcollins.com]

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote on 08/27/2013 
12:04:59 PM:

> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> To: clshotwe at rockwellcollins.com
> Cc: buildroot at busybox.net
> Date: 08/27/2013 12:05 PM
> Subject: Re: [Buildroot] SELinux Buildroot Additions
> 
> Hello Clayton,
> 
> On Tue, 27 Aug 2013 11:20:25 -0500, clshotwe at rockwellcollins.com wrote:
> 
> > I would like to get some feedback on adding SELinux support to 
Buildroot. 
> > This would involve adding several packages, modifying the .mk files 
for 
> > several packages to include SELinux support, and adding generic 
defconfigs 
> > to use as examples.  I would like to have defconfigs for QEMU targets 
> > (x86, ARM, PPC) along with a Pandaboard and another couple hardware 
> > targets.  The package selection for a functional SELinux system is a 
> > little complex so the example defconfigs would be nice to use as 
examples.
> > 
> > Would this be a welcomed addition to Buildroot?  I would like to 
submit a 
> > set of patches to first add the new packages, then modify existing 
> > packages, and then add in the example defconfigs one at a time.  Is 
this 
> > the best approach to take?
> 
> Having SELinux support in Buildroot would definitely be interesting,
> especially if you're using it for some projects!
> 
> Adding several packages is obviously fine. I guess you've already find
> the relevant documentation on how to add new packages to Buildroot.
> 
> Modifying existing .mk files of other packages to enable SELinux
> support is also perfectly fine. We'll have to see if we need a global
> knob to enable/disable SELinux, or if a per-package configuration is
> needed, or if the fact that a given package is enabled or disabled is a
> good enough indication of whether the user wants SELinux support. I
> guess we'll have to discuss this once we see your patches.
> 
> The defconfig part is probably the most problematic one. Until now, our
> policy about defconfigs is that they should just build the minimal set
> of things for a particular hardware platform to build: toolchain,
> kernel, bootloader, and minimal rootfs with Busybox. We've refrained
> from including other features in our defconfigs, because the definition
> of what a good configuration is for a particular platform is very
> use-case and user-dependent. Someone will want Qt, someone else will
> want X.org. Someone will want Busybox, someone else will want the
> full-featured Bash and Coreutils. Someone will want udev, someone else
> will want mdev. Someone will want Busybox init, someone else will want
> systemd. How to make a good choice, without having a proliferation of
> highly specific choices, is difficult.
> 
> Regarding SELinux and defconfigs, I see three options moving forward:
> 
>  *) We've been discussing some time ago the need to have some kind of
>     "demos" defconfig, mainly as part of the work done by Spenser
>     Gilliland on ARM OpenGL support in Buildroot. Those would be a
>     separate set of defconfig, clearly identified as "this demonstrates
>     some particular feature, on some particular platform, just for the
>     sake of demonstrating this feature". We however haven't decided
>     where to store those configurations, how to handle them compared to
>     the regular defconfigs, etc.
> 
>  *) Make the SELinux configuration in menuconfig simple enough that a
>     demonstration defconfig is not needed. You're mentioning that the
>     configuration to get a working SELinux system is a little bit
>     complex, and that's why a demo defconfig is needed. Maybe there's
>     something we can do here to make this SELinux configuration so
>     simple that a demo defconfig will no longer be needed?
> 
>  *) Add some details in the Buildroot manual on how to use SELinux.
>     Generally speaking, the manual could contain more details on how to
>     use a particular Buildroot package or feature. SELinux could be one
>     of them.
> 
> Of course, none of those options are mutually exclusive!
> 
> So, I believe we can get started with the first two steps, get an
> understanding of the configuration complexity, and see what is the best
> course of action for the last step.
> 
> What do you think about this?
> 
Thomas,

We have a multiple platforms that we will be validating this on 
including ARM, x86, and PPC. I should be able to start pushing out
patches for the packages within the week.

As for the defconfig issue, being able to pull down a reference config 
and some skeleton changes to implement a specific feature would be very 
nice to have. It may be possible to do QEMU targets for each architecture 
but I will have to look into that further. 

The single SELinux flag will be more problematic.  There are a lot of 
package dependencies that will be hard to configure without making the 
menuconfig very confusing. Also, there is a huge issue with using Busybox 
and the base SELinux Refpolicy put out by Tresys that cause applications 
to not run in the correct SELinux context.

For now, the documentation route, in the Buildroot manual, may be the best 

way to go. I'll just table this for now until I get the patches pushed 
out.

Thanks,
Clayton

Clayton Shotwell
Software Engineer
clshotwe at rockwellcollins.com
www.rockwellcollins.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130827/6c388be8/attachment.html>

[Buildroot] SELinux Buildroot Additions

[Thomas Petazzoni]

Clayton,

On Tue, 27 Aug 2013 12:46:25 -0500, clshotwe at rockwellcollins.com wrote:

> We have a multiple platforms that we will be validating this on 
> including ARM, x86, and PPC. I should be able to start pushing out
> patches for the packages within the week.

Nice!

> As for the defconfig issue, being able to pull down a reference config 
> and some skeleton changes to implement a specific feature would be very 
> nice to have. It may be possible to do QEMU targets for each architecture 
> but I will have to look into that further. 

I agree that having "demo" configurations would be useful. It's just
that it's not the purpose of the defconfigs we have today.

> The single SELinux flag will be more problematic.  There are a lot of 
> package dependencies that will be hard to configure without making the 
> menuconfig very confusing. Also, there is a huge issue with using Busybox 
> and the base SELinux Refpolicy put out by Tresys that cause applications 
> to not run in the correct SELinux context.

For other readers, the SELinux Refpolicy is apparently what is
available at http://oss.tresys.com/projects/refpolicy.

Can you expand on what is the huge issue between Busybox and the
SELinux Refpolicy? The fact that the Refpolicy doesn't include a policy
for Busybox? If so, isn't it possible to contribute a policy that would
be suitable for usage with Busybox? A quick Google search returns
http://code.google.com/p/sebusybox/.

Anyway, using Busybox on the target system is not necessarily mandatory
when using Buildroot, you can also chose to use the coreutils instead,
even though it's true that Busybox is our primary target for the base
of the system.

> For now, the documentation route, in the Buildroot manual, may be the best 
> way to go. I'll just table this for now until I get the patches pushed 
> out.

Right, sounds good!

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] SELinux Buildroot Additions

[clshotwe at rockwellcollins.com]

Thomas,

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote on 08/27/2013 
01:25:05 PM:

> Can you expand on what is the huge issue between Busybox and the
> SELinux Refpolicy? The fact that the Refpolicy doesn't include a policy
> for Busybox? If so, isn't it possible to contribute a policy that would
> be suitable for usage with Busybox? A quick Google search returns
> http://code.google.com/p/sebusybox/.

Since Busybox is one executable that runs a bunch of different commands, 
there is an issue with the SELinux type transitions happening correctly. 
Programs, including init, end up running in an incorrect context and break 
SELinux rules. A policy could probably be created to let Busybox do what 
it needs to do but then that opens up the issue of having one application 
do everything. A lot of potential security vulnerabilities can be blocked 
by having a bunch of different applications that cannot all be compromised 
at once.  It would be really easy to use busybox if it was possible to 
build separate executables for security critical applications but I don't 
think that feature is available yet.

The packages that I will be adding are all from Tresys (
http://userspace.selinuxproject.org/trac/).  I looked into the sebusybox 
stuff a while ago but it looks like no one has done any development on it 
in a while. 

Thanks,
Clayton

Clayton Shotwell
Software Engineer 
clshotwe at rockwellcollins.com
www.rockwellcollins.com 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130827/bc0f7ca6/attachment.html>

[Buildroot] SELinux Buildroot Additions

[Thomas Petazzoni]

Clayton,

On Tue, 27 Aug 2013 13:56:28 -0500, clshotwe at rockwellcollins.com wrote:

> > Can you expand on what is the huge issue between Busybox and the
> > SELinux Refpolicy? The fact that the Refpolicy doesn't include a policy
> > for Busybox? If so, isn't it possible to contribute a policy that would
> > be suitable for usage with Busybox? A quick Google search returns
> > http://code.google.com/p/sebusybox/.
> 
> Since Busybox is one executable that runs a bunch of different commands, 
> there is an issue with the SELinux type transitions happening correctly. 
> Programs, including init, end up running in an incorrect context and break 
> SELinux rules. A policy could probably be created to let Busybox do what 
> it needs to do but then that opens up the issue of having one application 
> do everything. A lot of potential security vulnerabilities can be blocked 
> by having a bunch of different applications that cannot all be compromised 
> at once.  It would be really easy to use busybox if it was possible to 
> build separate executables for security critical applications but I don't 
> think that feature is available yet.

This is actually possible, with the option CONFIG_FEATURE_INDIVIDUAL of
Busybox. It creates a libbusybox shared library, and then creates one
small (~6 KB) binary for each busybox program. This way, each program
is really separate, even though the program code is really within
libbusybox.

Wouldn't this make SELinux handling easier? If yes, then I believe we
could certainly decide to build and install Busybox this way when
SELinux support is enabled.

However, it seems like this Busybox feature installs those binary
programs in a directory called 0_lib/ in the source directory, and
"make install" keeps installing symbolic links. Well, I guess this is
probably something we can improve/fix.

> The packages that I will be adding are all from Tresys (
> http://userspace.selinuxproject.org/trac/).  I looked into the sebusybox 
> stuff a while ago but it looks like no one has done any development on it 
> in a while. 

Ok.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com