Re: [meta-selinux] refpolicy update in master-next

[Joe MacDonald <Joe_MacDonald@mentor.com>]

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

[Re: [meta-selinux] refpolicy update in master-next] On 14.09.18 (Thu 15:06) Mark Hatle wrote:

> On 9/18/14, 2:57 PM, Joe MacDonald wrote:
> >Hey all,
> >
> >As we'd all discussed at different times in the past, we're well behind
> >the curve on a refpolicy update for meta-selinux.  With the 1.7 release
> >of Yocto coming up, we thought it was important to update the policy
> >sooner rather than later, so I'm starting that work now.
> >
> >It's being done in master-next and currently the only recipe that has
> >been updated is the -mls one.  Over the next few days I'll be updating
> >the others, then working through testing and trying to make sure they're
> >all sane.  It would help me out immensely if you had time to kick the
> >tires as well on your favourite policy variant.
> >
> >Depending on how long this takes, the next step is updating the
> >userspace.  Fortunately this time around, though, the current userspace
> >is still officially up to the task of managing the current policy, so a
> >full update isn't strictly required.  It'd be a really nice thing to
> >have done, though.  :-)
> >
> 
> I spoke with Joe about this work this morning, and I think
> master-next is the right place to do this.  So if you have immediate
> bug fixes, we'll try to apply them to both master and master-next.
> And then continue to use master-next to stage the policy changes (or
> anything else that requires a bit more 'soak' time) before merging.
> 
> I'd like to try to get 'master' of meta-selinux fully synced and
> working with the 'master' of Poky around the time of Poky's release
> (within a week or so of the release at least)..  then we can branch
> and let the master continue to flow with any "new" work.  (It's a
> plan, I'm not sure if it'll happen or not.)
> 
> If anyone has any concerns let me know.. otherwise I think this is the plan!

The plan proceeds!  :-)

Anyway, so I've now updated all of the policies in refpolicy/ and I'm
starting in on the testing.

Pascal:  Can you pay particular attention to refpolicy-minimum?  The
straight forward-port of it failed to install the unconfined module
(obviously kind of important to r-min) due to some failure inside
prepare_policy_store().  I started debugging it, then saw that there was
a copy in the refpolicy-minimum recipe as well as one in
refpolicy_common.inc.  Both of them need to be cleaned up, but they both
appeared to be doing the same thing in slightly different ways.  Given
that, I turfed the one from refpolicy-minimum and it looks like the
unconfined.pp is installed properly using the version from
refpolicy_common.  It wasn't clear looking at either the function or the
commit log why a duplicate version of the function was placed in
refpolicy-minimum, so please have a look to see why it was there and if
it's still needed.

Thanks.

-- 
-Joe MacDonald.
:wq

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