meta-selinux

meta-selinux

[dpquigl]

Hello,

I'm working on OpenXT and it makes use of the meta-selinux repo hosted
by the yocto project. I'm trying to use it with a base openembedded core
and its not in sync with oe-core because its based on pokey. This made
me think of two questions. 1) Why is this not in OE core since so many
packages in core can potentially have SELinux support enabled and 2) if
its not supposed to be in core where should turning on SELinux support
in a recipe go? For example coreutils can have SELinux support enabled.
Currently this is in meta-selinux as a bbappend to the coreutils
package. This works out because its always going to be there. However
there is also a bbappend for an LXC recipe. LXC isn't in core which
means it has a dependency on a layer not in core.

Ideally I would put the recipes needed for SELinux support in core and
have a distro feature which is checked in the recipes in core for
whether or not to add --with-selinux to the build flags. Then LXC could
check a core distro feature and enable SELinux if it wants to. 

What is the right way to proceed with this?

Dave

Re: meta-selinux

[Christopher Larson]

On Wed, Feb 11, 2015 at 8:53 AM, dpquigl <dpquigl@tycho.nsa.gov> wrote:

> I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> by the yocto project. I'm trying to use it with a base openembedded core
> and its not in sync with oe-core because its based on pokey. This made
> me think of two questions. 1) Why is this not in OE core since so many
> packages in core can potentially have SELinux support enabled and 2) if
> its not supposed to be in core where should turning on SELinux support
> in a recipe go? For example coreutils can have SELinux support enabled.
> Currently this is in meta-selinux as a bbappend to the coreutils
> package. This works out because its always going to be there. However
> there is also a bbappend for an LXC recipe. LXC isn't in core which
> means it has a dependency on a layer not in core.
>

This is a bug in the layer. It's fairly trivial to construct a layer in
such a way that you can have per-layer bbappends that are only applied when
that layer exists. This is likely the approach meta-selinux should take to
address this implicit dependency upon meta-virtualization.

That said, I think most folks would be open to PACKAGECONFIGs for selinux
capability going into the main recipes, as that's not an invasive change,
nor a patch, but just a tweak in configuration.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: meta-selinux

[dpquigl]

On Wed, 2015-02-11 at 09:25 -0700, Christopher Larson wrote:
> On Wed, Feb 11, 2015 at 8:53 AM, dpquigl <dpquigl@tycho.nsa.gov> wrote:
> 
> > I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> > by the yocto project. I'm trying to use it with a base openembedded core
> > and its not in sync with oe-core because its based on pokey. This made
> > me think of two questions. 1) Why is this not in OE core since so many
> > packages in core can potentially have SELinux support enabled and 2) if
> > its not supposed to be in core where should turning on SELinux support
> > in a recipe go? For example coreutils can have SELinux support enabled.
> > Currently this is in meta-selinux as a bbappend to the coreutils
> > package. This works out because its always going to be there. However
> > there is also a bbappend for an LXC recipe. LXC isn't in core which
> > means it has a dependency on a layer not in core.
> >
> 
> This is a bug in the layer. It's fairly trivial to construct a layer in
> such a way that you can have per-layer bbappends that are only applied when
> that layer exists. This is likely the approach meta-selinux should take to
> address this implicit dependency upon meta-virtualization.

Thanks for the suggestion. I figured there was a way to do this but I'm
new enough to OE and bitbake that it wasn't immediately obvious to me
how to accomplish this. I'll look into giving it a try.

> 
> That said, I think most folks would be open to PACKAGECONFIGs for selinux
> capability going into the main recipes, as that's not an invasive change,
> nor a patch, but just a tweak in configuration.

That is good to hear. I'm going through the repo now to figure out what
is really needed to get SELinux working and what is extra. We've been
having a discussion here about the need to support certain policy
configurations on embedded SELinux systems. I'm still new enough to all
of this that I imagine it will take me a while to figure out how and
what to add PACKAGECONFIG wise to fit meta-selinux into oe-core.

Dave

Re: meta-selinux

[Philip Tricca]

On 02/11/2015 12:00 PM, dpquigl wrote:
> On Wed, 2015-02-11 at 09:25 -0700, Christopher Larson wrote:
>> On Wed, Feb 11, 2015 at 8:53 AM, dpquigl <dpquigl@tycho.nsa.gov> wrote:
>>
>>> I'm working on OpenXT and it makes use of the meta-selinux repo hosted
>>> by the yocto project. I'm trying to use it with a base openembedded core
>>> and its not in sync with oe-core because its based on pokey. This made
>>> me think of two questions. 1) Why is this not in OE core since so many
>>> packages in core can potentially have SELinux support enabled and 2) if
>>> its not supposed to be in core where should turning on SELinux support
>>> in a recipe go? For example coreutils can have SELinux support enabled.
>>> Currently this is in meta-selinux as a bbappend to the coreutils
>>> package. This works out because its always going to be there. However
>>> there is also a bbappend for an LXC recipe. LXC isn't in core which
>>> means it has a dependency on a layer not in core.
>>>
>>
>> This is a bug in the layer. It's fairly trivial to construct a layer in
>> such a way that you can have per-layer bbappends that are only applied when
>> that layer exists. This is likely the approach meta-selinux should take to
>> address this implicit dependency upon meta-virtualization.
> 
> Thanks for the suggestion. I figured there was a way to do this but I'm
> new enough to OE and bitbake that it wasn't immediately obvious to me
> how to accomplish this. I'll look into giving it a try.

I didn't know this was possible either. Will be useful to have in
meta-selinux independent of this conversation. Looks like a good example
of this method used in meta-mentor can be found here:

https://lists.yoctoproject.org/pipermail/meta-mentor/2013-May/000052.html

>> That said, I think most folks would be open to PACKAGECONFIGs for selinux
>> capability going into the main recipes, as that's not an invasive change,
>> nor a patch, but just a tweak in configuration.
> 
> That is good to hear. I'm going through the repo now to figure out what
> is really needed to get SELinux working and what is extra. We've been
> having a discussion here about the need to support certain policy
> configurations on embedded SELinux systems. I'm still new enough to all
> of this that I imagine it will take me a while to figure out how and
> what to add PACKAGECONFIG wise to fit meta-selinux into oe-core.

I'm happy to take a crack at using the per-layer bbappend method
described above in meta-selinux. When meta-selinux picked up a
dependency on 3 new layers caused by bbappends I had to update a bunch
of my build stuff even though I'm not using said layers.

Philip

Re: meta-selinux

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]

[Re: [oe] meta-selinux] On 15.02.11 (Wed 15:56) Philip Tricca wrote:

> On 02/11/2015 12:00 PM, dpquigl wrote:
> > On Wed, 2015-02-11 at 09:25 -0700, Christopher Larson wrote:
> >> On Wed, Feb 11, 2015 at 8:53 AM, dpquigl <dpquigl@tycho.nsa.gov> wrote:
> >>
> >>> I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> >>> by the yocto project. I'm trying to use it with a base openembedded core
> >>> and its not in sync with oe-core because its based on pokey. This made
> >>> me think of two questions. 1) Why is this not in OE core since so many
> >>> packages in core can potentially have SELinux support enabled and 2) if
> >>> its not supposed to be in core where should turning on SELinux support
> >>> in a recipe go? For example coreutils can have SELinux support enabled.
> >>> Currently this is in meta-selinux as a bbappend to the coreutils
> >>> package. This works out because its always going to be there. However
> >>> there is also a bbappend for an LXC recipe. LXC isn't in core which
> >>> means it has a dependency on a layer not in core.
> >>>
> >>
> >> This is a bug in the layer. It's fairly trivial to construct a layer in
> >> such a way that you can have per-layer bbappends that are only applied when
> >> that layer exists. This is likely the approach meta-selinux should take to
> >> address this implicit dependency upon meta-virtualization.
> > 
> > Thanks for the suggestion. I figured there was a way to do this but I'm
> > new enough to OE and bitbake that it wasn't immediately obvious to me
> > how to accomplish this. I'll look into giving it a try.
> 
> I didn't know this was possible either. Will be useful to have in
> meta-selinux independent of this conversation. Looks like a good example
> of this method used in meta-mentor can be found here:
> 
> https://lists.yoctoproject.org/pipermail/meta-mentor/2013-May/000052.html

I absolutely think this will be a benefit to anyone using meta-selinux.

> >> That said, I think most folks would be open to PACKAGECONFIGs for selinux
> >> capability going into the main recipes, as that's not an invasive change,
> >> nor a patch, but just a tweak in configuration.
> > 
> > That is good to hear. I'm going through the repo now to figure out what
> > is really needed to get SELinux working and what is extra. We've been
> > having a discussion here about the need to support certain policy
> > configurations on embedded SELinux systems. I'm still new enough to all
> > of this that I imagine it will take me a while to figure out how and
> > what to add PACKAGECONFIG wise to fit meta-selinux into oe-core.
> 
> I'm happy to take a crack at using the per-layer bbappend method
> described above in meta-selinux. When meta-selinux picked up a
> dependency on 3 new layers caused by bbappends I had to update a bunch
> of my build stuff even though I'm not using said layers.

If you don't mind and you've got the time, I'll be happy to merge the
patch, Philip.

-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: meta-selinux

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]

[Re: [oe] meta-selinux] On 15.02.11 (Wed 09:25) Christopher Larson wrote:

> On Wed, Feb 11, 2015 at 8:53 AM, dpquigl <dpquigl@tycho.nsa.gov> wrote:
> 
> > I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> > by the yocto project. I'm trying to use it with a base openembedded core
> > and its not in sync with oe-core because its based on pokey. This made
> > me think of two questions. 1) Why is this not in OE core since so many
> > packages in core can potentially have SELinux support enabled and 2) if
> > its not supposed to be in core where should turning on SELinux support
> > in a recipe go? For example coreutils can have SELinux support enabled.
> > Currently this is in meta-selinux as a bbappend to the coreutils
> > package. This works out because its always going to be there. However
> > there is also a bbappend for an LXC recipe. LXC isn't in core which
> > means it has a dependency on a layer not in core.
> >
> 
> This is a bug in the layer. It's fairly trivial to construct a layer in
> such a way that you can have per-layer bbappends that are only applied when
> that layer exists. This is likely the approach meta-selinux should take to
> address this implicit dependency upon meta-virtualization.

I agree.  As Philip mentioned, there's been creep in meta-selinux
dependencies that I really would prefer to avoid but I haven't gotten
around to making the dependencies optional and proposing a patch set on
the list yet.  It's something I think we need, though, particularly for
meta-selinux, but I imagine it's not the only layer that could use such
a change.

> That said, I think most folks would be open to PACKAGECONFIGs for selinux
> capability going into the main recipes, as that's not an invasive change,
> nor a patch, but just a tweak in configuration.

I know that's been the case in several places already, and in a lot of
cases I think that's probably the better place to do such things, so
that at least in theory the layer maintainers themselves are aware of
selinux issues, but I try to be a practical sort and since I don't
expect up-stream developers to be maintaining their own policy modules,
I also don't expect layer maintainers to be testing with selinux all
that often.  :-)

FWIW, though, there're plenty of examples in oe-core of SELinux
PACKAGECONFIGs and that works out pretty well for everyone, I think.

-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: meta-selinux

[Paul Eggleton]

(Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
tend to go at least)

On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> by the yocto project. I'm trying to use it with a base openembedded core
> and its not in sync with oe-core because its based on pokey. 

To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
into Poky directly, they are applied to OE-Core and then they flow into Poky 
immediately thereafter (Richard, who does the merging of patches into OE-Core, 
does the sync to Poky immediately afterwards.)

What's more likely happening I suspect is that you are on a newer 
branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
I can't speak to the maintenance schedule for meta-selinux but maybe others 
with knowledge there can chime in.

> This made me think of two questions. 1) Why is this not in OE core since so
> many packages in core can potentially have SELinux support enabled and 2) if
> its not supposed to be in core where should turning on SELinux support
> in a recipe go? For example coreutils can have SELinux support enabled.
> Currently this is in meta-selinux as a bbappend to the coreutils
> package. This works out because its always going to be there. However
> there is also a bbappend for an LXC recipe. LXC isn't in core which
> means it has a dependency on a layer not in core.
> 
> Ideally I would put the recipes needed for SELinux support in core and
> have a distro feature which is checked in the recipes in core for
> whether or not to add --with-selinux to the build flags. Then LXC could
> check a core distro feature and enable SELinux if it wants to.

We have to draw the line somewhere for what to include in OE-Core, and at the 
moment I guess we have considered SELinux to be outside its scope. Obviously 
these things get re-evaluated from time to time, and SELinux is a little bit 
painful for this because of how many recipes it has to touch. Ultimately it 
depends on how many people in the embedded space want to enable and use 
SELinux.

Thoughts from others?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [oe] meta-selinux

[Paul Eggleton]

(Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
tend to go at least)

On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> by the yocto project. I'm trying to use it with a base openembedded core
> and its not in sync with oe-core because its based on pokey. 

To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
into Poky directly, they are applied to OE-Core and then they flow into Poky 
immediately thereafter (Richard, who does the merging of patches into OE-Core, 
does the sync to Poky immediately afterwards.)

What's more likely happening I suspect is that you are on a newer 
branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
I can't speak to the maintenance schedule for meta-selinux but maybe others 
with knowledge there can chime in.

> This made me think of two questions. 1) Why is this not in OE core since so
> many packages in core can potentially have SELinux support enabled and 2) if
> its not supposed to be in core where should turning on SELinux support
> in a recipe go? For example coreutils can have SELinux support enabled.
> Currently this is in meta-selinux as a bbappend to the coreutils
> package. This works out because its always going to be there. However
> there is also a bbappend for an LXC recipe. LXC isn't in core which
> means it has a dependency on a layer not in core.
> 
> Ideally I would put the recipes needed for SELinux support in core and
> have a distro feature which is checked in the recipes in core for
> whether or not to add --with-selinux to the build flags. Then LXC could
> check a core distro feature and enable SELinux if it wants to.

We have to draw the line somewhere for what to include in OE-Core, and at the 
moment I guess we have considered SELinux to be outside its scope. Obviously 
these things get re-evaluated from time to time, and SELinux is a little bit 
painful for this because of how many recipes it has to touch. Ultimately it 
depends on how many people in the embedded space want to enable and use 
SELinux.

Thoughts from others?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: meta-selinux

[dpquigl]

On Wed, 2015-02-11 at 16:29 +0000, Paul Eggleton wrote:
> (Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
> tend to go at least)
> 
> On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> > I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> > by the yocto project. I'm trying to use it with a base openembedded core
> > and its not in sync with oe-core because its based on pokey. 
> 
> To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
> into Poky directly, they are applied to OE-Core and then they flow into Poky 
> immediately thereafter (Richard, who does the merging of patches into OE-Core, 
> does the sync to Poky immediately afterwards.)
> 
> What's more likely happening I suspect is that you are on a newer 
> branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
> I can't speak to the maintenance schedule for meta-selinux but maybe others 
> with knowledge there can chime in.


I think this makes the most sense. 3 of the problems were bbappend files
trying to append the wrong version of a recipe (although with these
changes I should move them over to a wildcard) and the last one was with
LXC. After that I encountered a typo in one of the recipes where it
wasn't able to pull the sources down. 

> 
> > This made me think of two questions. 1) Why is this not in OE core since so
> > many packages in core can potentially have SELinux support enabled and 2) if
> > its not supposed to be in core where should turning on SELinux support
> > in a recipe go? For example coreutils can have SELinux support enabled.
> > Currently this is in meta-selinux as a bbappend to the coreutils
> > package. This works out because its always going to be there. However
> > there is also a bbappend for an LXC recipe. LXC isn't in core which
> > means it has a dependency on a layer not in core.
> > 
> > Ideally I would put the recipes needed for SELinux support in core and
> > have a distro feature which is checked in the recipes in core for
> > whether or not to add --with-selinux to the build flags. Then LXC could
> > check a core distro feature and enable SELinux if it wants to.
> 
> We have to draw the line somewhere for what to include in OE-Core, and at the 
> moment I guess we have considered SELinux to be outside its scope. Obviously 
> these things get re-evaluated from time to time, and SELinux is a little bit 
> painful for this because of how many recipes it has to touch. Ultimately it 
> depends on how many people in the embedded space want to enable and use 
> SELinux.
> 
> Thoughts from others?
> 

In OpenXT we're using OE to generate images for dom0, a user interface
domain, a network driver domain, and various other service domains for
isolating tasks in the platform. In addition to that we're using
openembedded for building on various embedded research platforms. I'm
assuming yocto is using SELinux to some extent since they are
maintaining the repository for it and there are quite a few developers
using SELiunx on embedded products in Japan.


Dave

Re: [oe] meta-selinux

[dpquigl]

On Wed, 2015-02-11 at 16:29 +0000, Paul Eggleton wrote:
> (Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
> tend to go at least)
> 
> On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> > I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> > by the yocto project. I'm trying to use it with a base openembedded core
> > and its not in sync with oe-core because its based on pokey. 
> 
> To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
> into Poky directly, they are applied to OE-Core and then they flow into Poky 
> immediately thereafter (Richard, who does the merging of patches into OE-Core, 
> does the sync to Poky immediately afterwards.)
> 
> What's more likely happening I suspect is that you are on a newer 
> branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
> I can't speak to the maintenance schedule for meta-selinux but maybe others 
> with knowledge there can chime in.


I think this makes the most sense. 3 of the problems were bbappend files
trying to append the wrong version of a recipe (although with these
changes I should move them over to a wildcard) and the last one was with
LXC. After that I encountered a typo in one of the recipes where it
wasn't able to pull the sources down. 

> 
> > This made me think of two questions. 1) Why is this not in OE core since so
> > many packages in core can potentially have SELinux support enabled and 2) if
> > its not supposed to be in core where should turning on SELinux support
> > in a recipe go? For example coreutils can have SELinux support enabled.
> > Currently this is in meta-selinux as a bbappend to the coreutils
> > package. This works out because its always going to be there. However
> > there is also a bbappend for an LXC recipe. LXC isn't in core which
> > means it has a dependency on a layer not in core.
> > 
> > Ideally I would put the recipes needed for SELinux support in core and
> > have a distro feature which is checked in the recipes in core for
> > whether or not to add --with-selinux to the build flags. Then LXC could
> > check a core distro feature and enable SELinux if it wants to.
> 
> We have to draw the line somewhere for what to include in OE-Core, and at the 
> moment I guess we have considered SELinux to be outside its scope. Obviously 
> these things get re-evaluated from time to time, and SELinux is a little bit 
> painful for this because of how many recipes it has to touch. Ultimately it 
> depends on how many people in the embedded space want to enable and use 
> SELinux.
> 
> Thoughts from others?
> 

In OpenXT we're using OE to generate images for dom0, a user interface
domain, a network driver domain, and various other service domains for
isolating tasks in the platform. In addition to that we're using
openembedded for building on various embedded research platforms. I'm
assuming yocto is using SELinux to some extent since they are
maintaining the repository for it and there are quite a few developers
using SELiunx on embedded products in Japan.


Dave

Re: meta-selinux

[Philip Tricca]

On 02/11/2015 11:55 AM, dpquigl wrote:
> On Wed, 2015-02-11 at 16:29 +0000, Paul Eggleton wrote:
>> (Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
>> tend to go at least)
>>
>> On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
>>> I'm working on OpenXT and it makes use of the meta-selinux repo hosted
>>> by the yocto project. I'm trying to use it with a base openembedded core
>>> and its not in sync with oe-core because its based on pokey. 
>>
>> To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
>> into Poky directly, they are applied to OE-Core and then they flow into Poky 
>> immediately thereafter (Richard, who does the merging of patches into OE-Core, 
>> does the sync to Poky immediately afterwards.)
>>
>> What's more likely happening I suspect is that you are on a newer 
>> branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
>> I can't speak to the maintenance schedule for meta-selinux but maybe others 
>> with knowledge there can chime in.
> 
> 
> I think this makes the most sense. 3 of the problems were bbappend files
> trying to append the wrong version of a recipe (although with these
> changes I should move them over to a wildcard) and the last one was with
> LXC. After that I encountered a typo in one of the recipes where it
> wasn't able to pull the sources down. 

I sent out patches to fix these 4 issues to the list a week or so back.
Reviewing these things and getting them merged takes time though. AFAIK
the meta-selinux master branch hasn't built for months now mostly
because of bbappends trailing behind versions in oe-core. I've been
playing whack-a-mole on this but by the time patches get merged a new
version has changed elsewhere. I've been using wild-cards as much as
possible on account of this.

>>> This made me think of two questions. 1) Why is this not in OE core since so
>>> many packages in core can potentially have SELinux support enabled and 2) if
>>> its not supposed to be in core where should turning on SELinux support
>>> in a recipe go? For example coreutils can have SELinux support enabled.
>>> Currently this is in meta-selinux as a bbappend to the coreutils
>>> package. This works out because its always going to be there. However
>>> there is also a bbappend for an LXC recipe. LXC isn't in core which
>>> means it has a dependency on a layer not in core.
>>>
>>> Ideally I would put the recipes needed for SELinux support in core and
>>> have a distro feature which is checked in the recipes in core for
>>> whether or not to add --with-selinux to the build flags. Then LXC could
>>> check a core distro feature and enable SELinux if it wants to.
>>
>> We have to draw the line somewhere for what to include in OE-Core, and at the 
>> moment I guess we have considered SELinux to be outside its scope. Obviously 
>> these things get re-evaluated from time to time, and SELinux is a little bit 
>> painful for this because of how many recipes it has to touch. Ultimately it 
>> depends on how many people in the embedded space want to enable and use 
>> SELinux.
>>
>> Thoughts from others?

If SELinux support were to be integrated into oe-core directly this
would force similar support into other layers too no? The reach of
meta-selinux has expanded and the layers that must be pulled in to get
it to build has expanded from just oe-core to meta-virtualization (for
LXC) as well as a few layers in meta-oe.

I don't know much about the process here but these cross layer
dependencies would complicate things. I guess this would mean
integrating SELinux support as a distro feature (or whatever is
appropriate) into all of these layers directly. Not impossible but
getting buy-in from the relevant maintainers is necessary.

> In OpenXT we're using OE to generate images for dom0, a user interface
> domain, a network driver domain, and various other service domains for
> isolating tasks in the platform. In addition to that we're using
> openembedded for building on various embedded research platforms. I'm
> assuming yocto is using SELinux to some extent since they are
> maintaining the repository for it and there are quite a few developers
> using SELiunx on embedded products in Japan.

I guess I've been wondering the same thing. For OpenXT we had
implemented our own SELinux support on top of OE (we weren't OSS at the
time). Now that we are OSS we've re-based on meta-selinux but I don't
know of anyone else using this layer or at least discussing it publicly.

Philip

Re: [oe] meta-selinux

[Philip Tricca]

On 02/11/2015 11:55 AM, dpquigl wrote:
> On Wed, 2015-02-11 at 16:29 +0000, Paul Eggleton wrote:
>> (Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
>> tend to go at least)
>>
>> On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
>>> I'm working on OpenXT and it makes use of the meta-selinux repo hosted
>>> by the yocto project. I'm trying to use it with a base openembedded core
>>> and its not in sync with oe-core because its based on pokey. 
>>
>> To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
>> into Poky directly, they are applied to OE-Core and then they flow into Poky 
>> immediately thereafter (Richard, who does the merging of patches into OE-Core, 
>> does the sync to Poky immediately afterwards.)
>>
>> What's more likely happening I suspect is that you are on a newer 
>> branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
>> I can't speak to the maintenance schedule for meta-selinux but maybe others 
>> with knowledge there can chime in.
> 
> 
> I think this makes the most sense. 3 of the problems were bbappend files
> trying to append the wrong version of a recipe (although with these
> changes I should move them over to a wildcard) and the last one was with
> LXC. After that I encountered a typo in one of the recipes where it
> wasn't able to pull the sources down. 

I sent out patches to fix these 4 issues to the list a week or so back.
Reviewing these things and getting them merged takes time though. AFAIK
the meta-selinux master branch hasn't built for months now mostly
because of bbappends trailing behind versions in oe-core. I've been
playing whack-a-mole on this but by the time patches get merged a new
version has changed elsewhere. I've been using wild-cards as much as
possible on account of this.

>>> This made me think of two questions. 1) Why is this not in OE core since so
>>> many packages in core can potentially have SELinux support enabled and 2) if
>>> its not supposed to be in core where should turning on SELinux support
>>> in a recipe go? For example coreutils can have SELinux support enabled.
>>> Currently this is in meta-selinux as a bbappend to the coreutils
>>> package. This works out because its always going to be there. However
>>> there is also a bbappend for an LXC recipe. LXC isn't in core which
>>> means it has a dependency on a layer not in core.
>>>
>>> Ideally I would put the recipes needed for SELinux support in core and
>>> have a distro feature which is checked in the recipes in core for
>>> whether or not to add --with-selinux to the build flags. Then LXC could
>>> check a core distro feature and enable SELinux if it wants to.
>>
>> We have to draw the line somewhere for what to include in OE-Core, and at the 
>> moment I guess we have considered SELinux to be outside its scope. Obviously 
>> these things get re-evaluated from time to time, and SELinux is a little bit 
>> painful for this because of how many recipes it has to touch. Ultimately it 
>> depends on how many people in the embedded space want to enable and use 
>> SELinux.
>>
>> Thoughts from others?

If SELinux support were to be integrated into oe-core directly this
would force similar support into other layers too no? The reach of
meta-selinux has expanded and the layers that must be pulled in to get
it to build has expanded from just oe-core to meta-virtualization (for
LXC) as well as a few layers in meta-oe.

I don't know much about the process here but these cross layer
dependencies would complicate things. I guess this would mean
integrating SELinux support as a distro feature (or whatever is
appropriate) into all of these layers directly. Not impossible but
getting buy-in from the relevant maintainers is necessary.

> In OpenXT we're using OE to generate images for dom0, a user interface
> domain, a network driver domain, and various other service domains for
> isolating tasks in the platform. In addition to that we're using
> openembedded for building on various embedded research platforms. I'm
> assuming yocto is using SELinux to some extent since they are
> maintaining the repository for it and there are quite a few developers
> using SELiunx on embedded products in Japan.

I guess I've been wondering the same thing. For OpenXT we had
implemented our own SELinux support on top of OE (we weren't OSS at the
time). Now that we are OSS we've re-based on meta-selinux but I don't
know of anyone else using this layer or at least discussing it publicly.

Philip

Re: [yocto] meta-selinux

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 5631 bytes --]

[Re: [yocto] [oe] meta-selinux] On 15.02.11 (Wed 14:43) Philip Tricca wrote:

> On 02/11/2015 11:55 AM, dpquigl wrote:
> > On Wed, 2015-02-11 at 16:29 +0000, Paul Eggleton wrote:
> >> (Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
> >> tend to go at least)
> >>
> >> On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> >>> I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> >>> by the yocto project. I'm trying to use it with a base openembedded core
> >>> and its not in sync with oe-core because its based on pokey. 
> >>
> >> To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
> >> into Poky directly, they are applied to OE-Core and then they flow into Poky 
> >> immediately thereafter (Richard, who does the merging of patches into OE-Core, 
> >> does the sync to Poky immediately afterwards.)
> >>
> >> What's more likely happening I suspect is that you are on a newer 
> >> branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
> >> I can't speak to the maintenance schedule for meta-selinux but maybe others 
> >> with knowledge there can chime in.
> > 
> > 
> > I think this makes the most sense. 3 of the problems were bbappend files
> > trying to append the wrong version of a recipe (although with these
> > changes I should move them over to a wildcard) and the last one was with
> > LXC. After that I encountered a typo in one of the recipes where it
> > wasn't able to pull the sources down. 
> 
> I sent out patches to fix these 4 issues to the list a week or so back.
> Reviewing these things and getting them merged takes time though. AFAIK
> the meta-selinux master branch hasn't built for months now mostly
> because of bbappends trailing behind versions in oe-core. I've been
> playing whack-a-mole on this but by the time patches get merged a new
> version has changed elsewhere. I've been using wild-cards as much as
> possible on account of this.
> 
> >>> This made me think of two questions. 1) Why is this not in OE core since so
> >>> many packages in core can potentially have SELinux support enabled and 2) if
> >>> its not supposed to be in core where should turning on SELinux support
> >>> in a recipe go? For example coreutils can have SELinux support enabled.
> >>> Currently this is in meta-selinux as a bbappend to the coreutils
> >>> package. This works out because its always going to be there. However
> >>> there is also a bbappend for an LXC recipe. LXC isn't in core which
> >>> means it has a dependency on a layer not in core.
> >>>
> >>> Ideally I would put the recipes needed for SELinux support in core and
> >>> have a distro feature which is checked in the recipes in core for
> >>> whether or not to add --with-selinux to the build flags. Then LXC could
> >>> check a core distro feature and enable SELinux if it wants to.
> >>
> >> We have to draw the line somewhere for what to include in OE-Core, and at the 
> >> moment I guess we have considered SELinux to be outside its scope. Obviously 
> >> these things get re-evaluated from time to time, and SELinux is a little bit 
> >> painful for this because of how many recipes it has to touch. Ultimately it 
> >> depends on how many people in the embedded space want to enable and use 
> >> SELinux.
> >>
> >> Thoughts from others?
> 
> If SELinux support were to be integrated into oe-core directly this
> would force similar support into other layers too no? The reach of
> meta-selinux has expanded and the layers that must be pulled in to get
> it to build has expanded from just oe-core to meta-virtualization (for
> LXC) as well as a few layers in meta-oe.

All of these I would like to extract again, but I'm concerned we may not
be able to do this without some duplication of meta-python recipes.
Still, that's what I was hoping for.

> I don't know much about the process here but these cross layer
> dependencies would complicate things. I guess this would mean
> integrating SELinux support as a distro feature (or whatever is
> appropriate) into all of these layers directly. Not impossible but
> getting buy-in from the relevant maintainers is necessary.
> 
> > In OpenXT we're using OE to generate images for dom0, a user interface
> > domain, a network driver domain, and various other service domains for
> > isolating tasks in the platform. In addition to that we're using
> > openembedded for building on various embedded research platforms. I'm
> > assuming yocto is using SELinux to some extent since they are
> > maintaining the repository for it and there are quite a few developers
> > using SELiunx on embedded products in Japan.
> 
> I guess I've been wondering the same thing. For OpenXT we had
> implemented our own SELinux support on top of OE (we weren't OSS at the
> time). Now that we are OSS we've re-based on meta-selinux but I don't
> know of anyone else using this layer or at least discussing it publicly.

There's certainly a few other groups / companies, but I'm certain
they're all using the 1.7 branch for now, not master, and manually
updating to the latest refpolicy release (which came out days after we
branched for 1.7) in their own tree.  I'm preparing an update to the
newest refpolicy now, but we're also not far away from the next one, so
I'm almost tempted to wait it out at this point and jump right to the
201503* refpolicy.  I'd be interested to hear opinions on that from
anyone using meta-selinux and wanting to use the master branch.

-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: [oe] meta-selinux

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 5631 bytes --]

[Re: [yocto] [oe] meta-selinux] On 15.02.11 (Wed 14:43) Philip Tricca wrote:

> On 02/11/2015 11:55 AM, dpquigl wrote:
> > On Wed, 2015-02-11 at 16:29 +0000, Paul Eggleton wrote:
> >> (Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
> >> tend to go at least)
> >>
> >> On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> >>> I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> >>> by the yocto project. I'm trying to use it with a base openembedded core
> >>> and its not in sync with oe-core because its based on pokey. 
> >>
> >> To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
> >> into Poky directly, they are applied to OE-Core and then they flow into Poky 
> >> immediately thereafter (Richard, who does the merging of patches into OE-Core, 
> >> does the sync to Poky immediately afterwards.)
> >>
> >> What's more likely happening I suspect is that you are on a newer 
> >> branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
> >> I can't speak to the maintenance schedule for meta-selinux but maybe others 
> >> with knowledge there can chime in.
> > 
> > 
> > I think this makes the most sense. 3 of the problems were bbappend files
> > trying to append the wrong version of a recipe (although with these
> > changes I should move them over to a wildcard) and the last one was with
> > LXC. After that I encountered a typo in one of the recipes where it
> > wasn't able to pull the sources down. 
> 
> I sent out patches to fix these 4 issues to the list a week or so back.
> Reviewing these things and getting them merged takes time though. AFAIK
> the meta-selinux master branch hasn't built for months now mostly
> because of bbappends trailing behind versions in oe-core. I've been
> playing whack-a-mole on this but by the time patches get merged a new
> version has changed elsewhere. I've been using wild-cards as much as
> possible on account of this.
> 
> >>> This made me think of two questions. 1) Why is this not in OE core since so
> >>> many packages in core can potentially have SELinux support enabled and 2) if
> >>> its not supposed to be in core where should turning on SELinux support
> >>> in a recipe go? For example coreutils can have SELinux support enabled.
> >>> Currently this is in meta-selinux as a bbappend to the coreutils
> >>> package. This works out because its always going to be there. However
> >>> there is also a bbappend for an LXC recipe. LXC isn't in core which
> >>> means it has a dependency on a layer not in core.
> >>>
> >>> Ideally I would put the recipes needed for SELinux support in core and
> >>> have a distro feature which is checked in the recipes in core for
> >>> whether or not to add --with-selinux to the build flags. Then LXC could
> >>> check a core distro feature and enable SELinux if it wants to.
> >>
> >> We have to draw the line somewhere for what to include in OE-Core, and at the 
> >> moment I guess we have considered SELinux to be outside its scope. Obviously 
> >> these things get re-evaluated from time to time, and SELinux is a little bit 
> >> painful for this because of how many recipes it has to touch. Ultimately it 
> >> depends on how many people in the embedded space want to enable and use 
> >> SELinux.
> >>
> >> Thoughts from others?
> 
> If SELinux support were to be integrated into oe-core directly this
> would force similar support into other layers too no? The reach of
> meta-selinux has expanded and the layers that must be pulled in to get
> it to build has expanded from just oe-core to meta-virtualization (for
> LXC) as well as a few layers in meta-oe.

All of these I would like to extract again, but I'm concerned we may not
be able to do this without some duplication of meta-python recipes.
Still, that's what I was hoping for.

> I don't know much about the process here but these cross layer
> dependencies would complicate things. I guess this would mean
> integrating SELinux support as a distro feature (or whatever is
> appropriate) into all of these layers directly. Not impossible but
> getting buy-in from the relevant maintainers is necessary.
> 
> > In OpenXT we're using OE to generate images for dom0, a user interface
> > domain, a network driver domain, and various other service domains for
> > isolating tasks in the platform. In addition to that we're using
> > openembedded for building on various embedded research platforms. I'm
> > assuming yocto is using SELinux to some extent since they are
> > maintaining the repository for it and there are quite a few developers
> > using SELiunx on embedded products in Japan.
> 
> I guess I've been wondering the same thing. For OpenXT we had
> implemented our own SELinux support on top of OE (we weren't OSS at the
> time). Now that we are OSS we've re-based on meta-selinux but I don't
> know of anyone else using this layer or at least discussing it publicly.

There's certainly a few other groups / companies, but I'm certain
they're all using the 1.7 branch for now, not master, and manually
updating to the latest refpolicy release (which came out days after we
branched for 1.7) in their own tree.  I'm preparing an update to the
newest refpolicy now, but we're also not far away from the next one, so
I'm almost tempted to wait it out at this point and jump right to the
201503* refpolicy.  I'd be interested to hear opinions on that from
anyone using meta-selinux and wanting to use the master branch.

-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: meta-selinux

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 3920 bytes --]

[Re: [oe] meta-selinux] On 15.02.11 (Wed 11:55) dpquigl wrote:

> On Wed, 2015-02-11 at 16:29 +0000, Paul Eggleton wrote:
> > (Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
> > tend to go at least)
> > 
> > On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> > > I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> > > by the yocto project. I'm trying to use it with a base openembedded core
> > > and its not in sync with oe-core because its based on pokey. 
> > 
> > To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
> > into Poky directly, they are applied to OE-Core and then they flow into Poky 
> > immediately thereafter (Richard, who does the merging of patches into OE-Core, 
> > does the sync to Poky immediately afterwards.)
> > 
> > What's more likely happening I suspect is that you are on a newer 
> > branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
> > I can't speak to the maintenance schedule for meta-selinux but maybe others 
> > with knowledge there can chime in.
> 
> 
> I think this makes the most sense. 3 of the problems were bbappend files
> trying to append the wrong version of a recipe (although with these
> changes I should move them over to a wildcard) and the last one was with
> LXC. After that I encountered a typo in one of the recipes where it
> wasn't able to pull the sources down. 

I merged a set of patches just in the last couple of days that addresses
a SRC_URI issue and wildcards for bbappends that I hope resolves all of
the current crop of these.  If you update your tree now you will likely
see those go away.  If not, please let me know.

Alternatively, I'm not aware of any issues in 1.7 of that sort (though
now that I think about it, I need to check the SRC_URI one, I bet that's
there), so using the latest released Yocto with a like-named branch in
meta-selinux should always be safe.

-J.

> > > This made me think of two questions. 1) Why is this not in OE core since so
> > > many packages in core can potentially have SELinux support enabled and 2) if
> > > its not supposed to be in core where should turning on SELinux support
> > > in a recipe go? For example coreutils can have SELinux support enabled.
> > > Currently this is in meta-selinux as a bbappend to the coreutils
> > > package. This works out because its always going to be there. However
> > > there is also a bbappend for an LXC recipe. LXC isn't in core which
> > > means it has a dependency on a layer not in core.
> > > 
> > > Ideally I would put the recipes needed for SELinux support in core and
> > > have a distro feature which is checked in the recipes in core for
> > > whether or not to add --with-selinux to the build flags. Then LXC could
> > > check a core distro feature and enable SELinux if it wants to.
> > 
> > We have to draw the line somewhere for what to include in OE-Core, and at the 
> > moment I guess we have considered SELinux to be outside its scope. Obviously 
> > these things get re-evaluated from time to time, and SELinux is a little bit 
> > painful for this because of how many recipes it has to touch. Ultimately it 
> > depends on how many people in the embedded space want to enable and use 
> > SELinux.
> > 
> > Thoughts from others?
> > 
> 
> In OpenXT we're using OE to generate images for dom0, a user interface
> domain, a network driver domain, and various other service domains for
> isolating tasks in the platform. In addition to that we're using
> openembedded for building on various embedded research platforms. I'm
> assuming yocto is using SELinux to some extent since they are
> maintaining the repository for it and there are quite a few developers
> using SELiunx on embedded products in Japan.
> 
> 
> Dave
> 
> 
> 
-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: [oe] meta-selinux

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 3920 bytes --]

[Re: [oe] meta-selinux] On 15.02.11 (Wed 11:55) dpquigl wrote:

> On Wed, 2015-02-11 at 16:29 +0000, Paul Eggleton wrote:
> > (Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
> > tend to go at least)
> > 
> > On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> > > I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> > > by the yocto project. I'm trying to use it with a base openembedded core
> > > and its not in sync with oe-core because its based on pokey. 
> > 
> > To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
> > into Poky directly, they are applied to OE-Core and then they flow into Poky 
> > immediately thereafter (Richard, who does the merging of patches into OE-Core, 
> > does the sync to Poky immediately afterwards.)
> > 
> > What's more likely happening I suspect is that you are on a newer 
> > branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
> > I can't speak to the maintenance schedule for meta-selinux but maybe others 
> > with knowledge there can chime in.
> 
> 
> I think this makes the most sense. 3 of the problems were bbappend files
> trying to append the wrong version of a recipe (although with these
> changes I should move them over to a wildcard) and the last one was with
> LXC. After that I encountered a typo in one of the recipes where it
> wasn't able to pull the sources down. 

I merged a set of patches just in the last couple of days that addresses
a SRC_URI issue and wildcards for bbappends that I hope resolves all of
the current crop of these.  If you update your tree now you will likely
see those go away.  If not, please let me know.

Alternatively, I'm not aware of any issues in 1.7 of that sort (though
now that I think about it, I need to check the SRC_URI one, I bet that's
there), so using the latest released Yocto with a like-named branch in
meta-selinux should always be safe.

-J.

> > > This made me think of two questions. 1) Why is this not in OE core since so
> > > many packages in core can potentially have SELinux support enabled and 2) if
> > > its not supposed to be in core where should turning on SELinux support
> > > in a recipe go? For example coreutils can have SELinux support enabled.
> > > Currently this is in meta-selinux as a bbappend to the coreutils
> > > package. This works out because its always going to be there. However
> > > there is also a bbappend for an LXC recipe. LXC isn't in core which
> > > means it has a dependency on a layer not in core.
> > > 
> > > Ideally I would put the recipes needed for SELinux support in core and
> > > have a distro feature which is checked in the recipes in core for
> > > whether or not to add --with-selinux to the build flags. Then LXC could
> > > check a core distro feature and enable SELinux if it wants to.
> > 
> > We have to draw the line somewhere for what to include in OE-Core, and at the 
> > moment I guess we have considered SELinux to be outside its scope. Obviously 
> > these things get re-evaluated from time to time, and SELinux is a little bit 
> > painful for this because of how many recipes it has to touch. Ultimately it 
> > depends on how many people in the embedded space want to enable and use 
> > SELinux.
> > 
> > Thoughts from others?
> > 
> 
> In OpenXT we're using OE to generate images for dom0, a user interface
> domain, a network driver domain, and various other service domains for
> isolating tasks in the platform. In addition to that we're using
> openembedded for building on various embedded research platforms. I'm
> assuming yocto is using SELinux to some extent since they are
> maintaining the repository for it and there are quite a few developers
> using SELiunx on embedded products in Japan.
> 
> 
> Dave
> 
> 
> 
-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: meta-selinux

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 3463 bytes --]

[Re: [oe] meta-selinux] On 15.02.11 (Wed 16:29) Paul Eggleton wrote:

> (Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
> tend to go at least)
> 
> On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> > I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> > by the yocto project. I'm trying to use it with a base openembedded core
> > and its not in sync with oe-core because its based on pokey. 
> 
> To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
> into Poky directly, they are applied to OE-Core and then they flow into Poky 
> immediately thereafter (Richard, who does the merging of patches into OE-Core, 
> does the sync to Poky immediately afterwards.)
> 
> What's more likely happening I suspect is that you are on a newer 
> branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
> I can't speak to the maintenance schedule for meta-selinux but maybe others 
> with knowledge there can chime in.

Our master tends to lag behind oe-core's master for a few reasons, but
none of them are really insurmountable.  Certainly the intent is that
meta-selinux/master will build successfully with oe-core/master at any
given time.

> > This made me think of two questions. 1) Why is this not in OE core since so
> > many packages in core can potentially have SELinux support enabled and 2) if
> > its not supposed to be in core where should turning on SELinux support
> > in a recipe go? For example coreutils can have SELinux support enabled.
> > Currently this is in meta-selinux as a bbappend to the coreutils
> > package. This works out because its always going to be there. However
> > there is also a bbappend for an LXC recipe. LXC isn't in core which
> > means it has a dependency on a layer not in core.
> > 
> > Ideally I would put the recipes needed for SELinux support in core and
> > have a distro feature which is checked in the recipes in core for
> > whether or not to add --with-selinux to the build flags. Then LXC could
> > check a core distro feature and enable SELinux if it wants to.
> 
> We have to draw the line somewhere for what to include in OE-Core, and at the 
> moment I guess we have considered SELinux to be outside its scope. Obviously 
> these things get re-evaluated from time to time, and SELinux is a little bit 
> painful for this because of how many recipes it has to touch. Ultimately it 
> depends on how many people in the embedded space want to enable and use 
> SELinux.
> 
> Thoughts from others?

I've been doing SELinux stuff for rather a long time and it's generally
been my experience that there's a set of developers / vendors that
*really* want it and know what they're doing, there's another set that
*really* want nothing to do with it and a group that say they want
SELinux support but then immediately start needing to turn stuff off
because it causes their system to behave too differently.

Taken as a simple maintenance thing, I think it's easier to have SELinux
be part of OE-Core.  Given, though, it's really not possible to divorce
much of SELinux functionality from python on the target, so then I don't
know if it really makes sense for something like that to be part of
oe-core, proper.  I would think no.

> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: [oe] meta-selinux

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 3463 bytes --]

[Re: [oe] meta-selinux] On 15.02.11 (Wed 16:29) Paul Eggleton wrote:

> (Adding yocto@yoctoproject.org to CC since that is where meta-selinux patches 
> tend to go at least)
> 
> On Wednesday 11 February 2015 10:53:03 dpquigl wrote:
> > I'm working on OpenXT and it makes use of the meta-selinux repo hosted
> > by the yocto project. I'm trying to use it with a base openembedded core
> > and its not in sync with oe-core because its based on pokey. 
> 
> To be clear, poky and OE-Core are in lock-step. No patch to core recipes goes 
> into Poky directly, they are applied to OE-Core and then they flow into Poky 
> immediately thereafter (Richard, who does the merging of patches into OE-Core, 
> does the sync to Poky immediately afterwards.)
> 
> What's more likely happening I suspect is that you are on a newer 
> branch/revision of OE-Core/Poky than the meta-selinux maintainers have tested. 
> I can't speak to the maintenance schedule for meta-selinux but maybe others 
> with knowledge there can chime in.

Our master tends to lag behind oe-core's master for a few reasons, but
none of them are really insurmountable.  Certainly the intent is that
meta-selinux/master will build successfully with oe-core/master at any
given time.

> > This made me think of two questions. 1) Why is this not in OE core since so
> > many packages in core can potentially have SELinux support enabled and 2) if
> > its not supposed to be in core where should turning on SELinux support
> > in a recipe go? For example coreutils can have SELinux support enabled.
> > Currently this is in meta-selinux as a bbappend to the coreutils
> > package. This works out because its always going to be there. However
> > there is also a bbappend for an LXC recipe. LXC isn't in core which
> > means it has a dependency on a layer not in core.
> > 
> > Ideally I would put the recipes needed for SELinux support in core and
> > have a distro feature which is checked in the recipes in core for
> > whether or not to add --with-selinux to the build flags. Then LXC could
> > check a core distro feature and enable SELinux if it wants to.
> 
> We have to draw the line somewhere for what to include in OE-Core, and at the 
> moment I guess we have considered SELinux to be outside its scope. Obviously 
> these things get re-evaluated from time to time, and SELinux is a little bit 
> painful for this because of how many recipes it has to touch. Ultimately it 
> depends on how many people in the embedded space want to enable and use 
> SELinux.
> 
> Thoughts from others?

I've been doing SELinux stuff for rather a long time and it's generally
been my experience that there's a set of developers / vendors that
*really* want it and know what they're doing, there's another set that
*really* want nothing to do with it and a group that say they want
SELinux support but then immediately start needing to turn stuff off
because it causes their system to behave too differently.

Taken as a simple maintenance thing, I think it's easier to have SELinux
be part of OE-Core.  Given, though, it's really not possible to divorce
much of SELinux functionality from python on the target, so then I don't
know if it really makes sense for something like that to be part of
oe-core, proper.  I would think no.

> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: meta-selinux

[Burton, Ross]

On 11 February 2015 at 21:39, Joe MacDonald <Joe_MacDonald@mentor.com>
wrote:

> > What's more likely happening I suspect is that you are on a newer
> > branch/revision of OE-Core/Poky than the meta-selinux maintainers have
> tested.
> > I can't speak to the maintenance schedule for meta-selinux but maybe
> others
> > with knowledge there can chime in.
>
> Our master tends to lag behind oe-core's master for a few reasons, but
> none of them are really insurmountable.  Certainly the intent is that
> meta-selinux/master will build successfully with oe-core/master at any
> given time.


The yocto-autobuilder software is in git and I heartily recommend it (or
similar, if you've a buildbot allergy) for anyone maintaining layers.  Just
the simple act of running a build every night to verify that the layer
works with the latest master branch (and stable branches for bonus points)
means that problems like stale bbappends are rapidly found and resolved.
For even more bonus points, also do builds against master-next if that
branch exists so you can get notification of changes that are in review.

Ross

Re: [oe] meta-selinux

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

On 11 February 2015 at 21:39, Joe MacDonald <Joe_MacDonald@mentor.com>
wrote:

> > What's more likely happening I suspect is that you are on a newer
> > branch/revision of OE-Core/Poky than the meta-selinux maintainers have
> tested.
> > I can't speak to the maintenance schedule for meta-selinux but maybe
> others
> > with knowledge there can chime in.
>
> Our master tends to lag behind oe-core's master for a few reasons, but
> none of them are really insurmountable.  Certainly the intent is that
> meta-selinux/master will build successfully with oe-core/master at any
> given time.


The yocto-autobuilder software is in git and I heartily recommend it (or
similar, if you've a buildbot allergy) for anyone maintaining layers.  Just
the simple act of running a build every night to verify that the layer
works with the latest master branch (and stable branches for bonus points)
means that problems like stale bbappends are rapidly found and resolved.
For even more bonus points, also do builds against master-next if that
branch exists so you can get notification of changes that are in review.

Ross

[-- Attachment #2: Type: text/html, Size: 1543 bytes --]

Re: [oe] meta-selinux

[Maxin John]

Hi Ross,

On Thu, Feb 12, 2015 at 12:19 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 11 February 2015 at 21:39, Joe MacDonald <Joe_MacDonald@mentor.com>
> wrote:
>>
>> > What's more likely happening I suspect is that you are on a newer
>> > branch/revision of OE-Core/Poky than the meta-selinux maintainers have
>> > tested.
>> > I can't speak to the maintenance schedule for meta-selinux but maybe
>> > others
>> > with knowledge there can chime in.
>>
>> Our master tends to lag behind oe-core's master for a few reasons, but
>> none of them are really insurmountable.  Certainly the intent is that
>> meta-selinux/master will build successfully with oe-core/master at any
>> given time.
>
>
> The yocto-autobuilder software is in git and I heartily recommend it (or
> similar, if you've a buildbot allergy) for anyone maintaining layers.  Just
> the simple act of running a build every night to verify that the layer works
> with the latest master branch (and stable branches for bonus points) means
> that problems like stale bbappends are rapidly found and resolved.  For even
> more bonus points, also do builds against master-next if that branch exists
> so you can get notification of changes that are in review.

While I don't have anything against the autobuilder, the images built with
meta-selinux like "core-image-selinux" had a "labeling" phase which requires
it to boot - twice
Once for labeling and later for booting like any other normal image.

Do anyone care to share a way around this "difficulty" in automatically testing
selinux or am I wrong here ?

> Ross

Best Regards,
Maxin