On 23/11/16 17:30, Jason Zaman wrote:
On Wed, Nov 23, 2016 at 05:20:59PM +0000, Robert Sharp wrote:
On 23/11/16 16:59, Robert Sharp wrote:
On 23/11/16 15:58, Jason Zaman wrote:
Either is fine, but im probably just gonna stabilize the 2.6 userspace
in a couple weeks so that one is likely easier. and setools4 is waaay
better than 3. The important point is that you dont want to have both
policy.29 and policy.30 around. Then you get weirdness like if you
downgrade a kernel or something random it'll load in the old policy
which probably doesnt work properly, so whichever you pick, make sure
you nuke the other one. and semodule -B will rebuild the whole policy
again and load it.
OK - I will go with policy.30 and add the keywords etc. I did a couple
of local policy changes that may not be needed so will they disappear
in all of this or do I need to remove them somehow first?
Thanks for all your help,
Robert
Sorry - noticed a couple of things while preping the emerge:
1) selinux-base-policy is blocking policycoreutils so presumably I need
to add that to my accept_keywords?
2) this package has the "unconfined" use flag set but I don't use
unconfined. Does that matter?
Oh, yeah the 2.6 userland needs at minimum 2.20151208-r6. Its been long
enough, i'll stabilize the new policies right away so just wait a bit
any sync again.
unconfined useflag just builds it, if you are using strict you can turn
off unconfined and set this in make.conf:
POLICY_TYPES="strict"
then it wont even build the targetted modules at all.
Thanks Jason - you have been busy. I have just updated to 20151208-r6
and when I run semodule -B I get this message:
"libsemanage.add_user: user system_u not in password file"
Googling suggests this was a problem in Fedora (see bug
https://bugzilla.redhat.com/show_bug.cgi?id=1378204) and it was fixed a
few days ago in their selinux-policy-3.13.1-191.20.fc24. I ran sesearch
as before and it comes up with the same results as before so I assume
the semodule command did not do what it was supposed to do. Is there a
work around for this or should I go ~arch on the policy as well? If so,
is there a way to avoid listing all the policy packages in my
accept_keywords file?
Thanks again,
Robert
