[yocto] [meta-selinux] refpolicy update in master-next

[Joe MacDonald]

Hi Pascal,

[Re: [yocto] [meta-selinux] refpolicy update in master-next] On 14.09.22 (Mon 16:29) Pascal Ouyang wrote:

> 于 14-9-20 上午5:17, Joe MacDonald 写道:
> >[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.
> 
> Hi Joe,
> 
> The original prepare_policy_store() has a naming bug for
> compressed_policy, and I have fixed it.
> A "clear compressed_policy distro feature" commit is also pushed, as
> I have mentioned to you.

Actually, I had a look at what you pushed and it wasn't quite what we
talked about, I don't think.  I said I'd thought there was still value
in having the uncompressed policy installed on the target, but that
changing the default (and obviously correcting the bug you'd mentioned
where uncompressed policies were not actually being installed regardless
of the flag) was fine.

Here's my thinking on this.

core-image-selinux contains all the tools necessary to install, create
and manage policy on a system.  Therefore you don't actually have to
have anything except the core-image-selinux system to do anything with
it.  If you need to refer back to the existing policy, though, you need
to either have an editor that uncompresses on the fly (which we don't
actually have on the system, though I imagine something like SLIDE or
SEEdit can do that, I don't know) uncompress the policy then load it
into something like semodule_unpack.  That's necessary because (last I
checked, at least, I can go double-check now that I'm thinking about it)
semodule_unpack doesn't know how to managed bzip compressed modules.
And since the compressed modules are still named '*.pp', uncompressing
them is kind of a pain, requiring a bit of shell dancing either dealing
with 'foo.pp.out' or moving the modules around before uncompressing
them.

So I do think it's worth having a switch that lets you decide whether
you think it's likely you'd want to unpack and manipulate module
components on the system.  But I'm all for the default being "no, that's
not likely".

Unrelated, please don't push to master-next right now, with my current
debug and update workflow if you hadn't told me you'd pushed a change to
master-next that hadn't been sent through the list, there's a good
chance it would've gotten lost.  There is a *lot* of churn in
master-next right now and, as always with these branches, nothing is
expected to be fast-forward for the time-being.

-J.

> 
> Thanks. :)
> 
> - Pascal
> 
> >
> >Thanks.
> >
> 
> 
> -- 
> - Pascal
-- 
-Joe MacDonald.
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20140922/09899910/attachment.pgp>