Martin, 
is it a beaker issue? 

What does

$ rpm -q --scripts |grep runcon

Hi,
I can't see the error outside of beaker.

[root@ibm-x3650m4-01-vm-12 ~]# rpm -qa --scripts | grep runcon
[root@ibm-x3650m4-01-vm-12 ~]#

I guess this is the same issue which we already fixed for Fedora 21 in bug 1077115. We just need to build the same custom selinux policy for RHEL7.1 now.

*** Bug 1150948 has been marked as a duplicate of this bug. ***

Patch to build beah policy module on RHEL7 as well: http://gerrit.beaker-project.org/3400

Test package is here: http://file.bos.redhat.com/~dcallagh/bz1149988/harness-el7/beah-0.7.6-1.git.2.5440a7e.el7eng.noarch.rpm

You can try adding this to your recipe XML as a workaround (I haven't tested this yet):
<repo name="beaker-harness-bz1149988" url="http://file.bos.redhat.com/~dcallagh/bz1149988/harness-el7/" />

However, I do see that this build of beah fails to install with selinux-policy < 3.13:

libsepol.print_missing_requirements: beah's global requirements were not met: type/attribute unconfined_service_t (No such file or directory).

That's a problem, because it means that beah would then fail to install on recipes using RHEL7 GA (and any RHEL7 nightly up until the recent selinux-policy rebase).

Miroslav, any suggestions on how we can have a policy which works on both RHEL7.0 and RHEL7.1? Here's how it looks now:

https://git.beaker-project.org/cgit/beah/tree/selinux/beah.te

A rebased selinux-policy goes into RHEL-7.1. The unconfined_service_t type was not defined before selinux-policy 3.13.

(In reply to Milos Malik from comment #7)
> A rebased selinux-policy goes into RHEL-7.1. The unconfined_service_t type
> was not defined before selinux-policy 3.13.

Right, so given that, I am trying to figure out how I can build a beah package that works (without triggering AVC denials) on both RHEL7.0 and RHEL7.1.

I guess we can just include the beah policy module in RHEL7 builds, and ignore the error from semodule -i in case the distro has selinux-policy 3.12, since the policy module is not needed in that case anyway.

How does look the beah policy module?

(In reply to Miroslav Grepl from comment #10)
> How does look the beah policy module?

The beah policy module is here:
https://git.beaker-project.org/cgit/beah/tree/selinux/beah.te
https://git.beaker-project.org/cgit/beah/tree/selinux/beah.fc

Anyway, never mind, it works fine if we just ignore the failure from semodule -i on older RHEL7 builds, so I will just go with that.

(In reply to Dan Callaghan from comment #11)
> Anyway, never mind, it works fine if we just ignore the failure from
> semodule -i on older RHEL7 builds, so I will just go with that.

Scratch that, I was testing the wrong thing. I still can't get this to work...

On RHEL-7.1-20141006.1, the beah module fails to be installed with this error:

libsepol.permission_copy_callback: Module rhts depends on permission kill in class service, not satisfied (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory).
semodule:  Failed!

Maybe that's because it's being built against selinux-policy-3.12.1-153.el7, since that's the latest version in the buildroot.

Why is selinux-policy 3.13.1 appearing in the distros, but we're still building against 3.12.1?

(In reply to Dan Callaghan from comment #12)
> (In reply to Dan Callaghan from comment #11)
> > Anyway, never mind, it works fine if we just ignore the failure from
> > semodule -i on older RHEL7 builds, so I will just go with that.
> 
> Scratch that, I was testing the wrong thing. I still can't get this to
> work...
> 
> On RHEL-7.1-20141006.1, the beah module fails to be installed with this
> error:
> 
> libsepol.permission_copy_callback: Module rhts depends on permission kill in
> class service, not satisfied (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file or
> directory).
> semodule:  Failed!
> 

This has been fixed in the latest RHEL7.1 build.

> Maybe that's because it's being built against selinux-policy-3.12.1-153.el7,
> since that's the latest version in the buildroot.
> 
> Why is selinux-policy 3.13.1 appearing in the distros, but we're still
> building against 3.12.1?

*** Bug 1152719 has been marked as a duplicate of this bug. ***

(In reply to Dan Callaghan from comment #6)
> You can try adding this to your recipe XML as a workaround (I haven't tested
> this yet):
> <repo name="beaker-harness-bz1149988"
> url="http://file.bos.redhat.com/~dcallagh/bz1149988/harness-el7/" />


The correct beah version gets installed, however, the SELinux module does not:

[root@intel-sharkbay-mb-01 ~]# rpm -ql beah | grep sel
/usr/share/selinux/packages/beah
/usr/share/selinux/packages/beah/beah.pp
[root@intel-sharkbay-mb-01 ~]# semodule -l | grep beah
[root@intel-sharkbay-mb-01 ~]# 

This was for https://beaker.engineering.redhat.com/jobs/774582


I'm trying again with a task to install the module:

<task name="/distribution/command" role="STANDALONE">
    <params>
        <param name="CMDS_TO_RUN" 
               value="semodule -i /usr/share/selinux/packages/beah/beah.pp"/>
    </params>
</task>

https://beaker.engineering.redhat.com/jobs/774605

(In reply to Jeff Bastian from comment #15)
> The correct beah version gets installed, however, the SELinux module does
> not:
> 
> [root@intel-sharkbay-mb-01 ~]# rpm -ql beah | grep sel
> /usr/share/selinux/packages/beah
> /usr/share/selinux/packages/beah/beah.pp
> [root@intel-sharkbay-mb-01 ~]# semodule -l | grep beah
> [root@intel-sharkbay-mb-01 ~]# 
> 
> This was for https://beaker.engineering.redhat.com/jobs/774582

Jeff, you hit the same error as me above. "Module rhts depends on permission kill in class service, not satisfied". You can spot it in console.log when beah is installed (semodule -i is run as a %postins scriptlet).

I see that your job used RHEL-7.1-20141014.n.0. Miroslav, are you sure the issue with "kill" is fixed? Is the fix not getting into RHEL7 nightlies somehow?

Milos,
are you still getting "kill" issue with the latest builds?

Tested on rhts.pp. semodule -i complains "depends on permission kill in class service, not satisfied":
 * 3.13.1-2.el7: yes
 * 3.13.1-4.el7: yes

Ok I see it now. It's about "service" class not about "system" class.

Hello,
could you please clarify what would be the actual fix. Are beaker tests supposed to be running as unconfined_service_t or unconfined_t (as on other RHELs)? The first is breaking some tests ATM and I would like to know whether we should file bugs against the policy or wait for this bug to be fixed.

This is currently top blocker for RHEL7.1 testing. All teams seeing AVC denials. 
More frequent status updates would be appreciated.

Milos,
we could add a transition from unconfined_services_t -> unconfined_t and have it in rhts.pp module. But it would require

chcon -t bin_t PATHO/test_script

It did not end well:
 * https://beaker.engineering.redhat.com/jobs/782980

What was wrong? Do I need to go thru all logs to find what was wrong?

I still see

type=AVC msg=audit(1414155006.546:52): avc:  denied  { transition } for  pid=12851 comm="runcon" path="/usr/bin/true" dev="dm-1" ino=134641227 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process

# chcon -t bin_t /var/lib/beah/tortilla/wrappers.d/*
# cat mypolicy.te 
module mypolicy 1.0;

require {
	type unconfined_t;
	type unconfined_service_t;
	class process transition;
}

#============= unconfined_service_t ==============

allow unconfined_service_t unconfined_t:process transition;
# make -f /usr/share/selinux/devel/Makefile 
Compiling targeted mypolicy module
/usr/bin/checkmodule:  loading policy configuration from tmp/mypolicy.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 17) to tmp/mypolicy.mod
Creating targeted mypolicy.pp policy package
rm tmp/mypolicy.mod.fc tmp/mypolicy.mod
# semodule -i mypolicy.pp
#

After these commands I don't see the AVC anymore.

Following task does the magic:

--task "! chcon -t bin_t /var/lib/beah/tortilla/wrappers.d/* ; yum -y install selinux-policy-devel ; echo -en 'policy_module(mypolicy,1.0)\nrequire {\ntype unconfined_service_t;\ntype unconfined_t;\nclass process { transition };\n}\nallow unconfined_service_t unconfined_t : process { transition };\n' > mypolicy.te ; make -f /usr/share/selinux/devel/Makefile ; semodule -i mypolicy.pp"

Tested on beaker machines where selinux-policy-3.13.1-6.el7 was installed.

(In reply to Milos Malik from comment #26)

This is, I think, basically equivalent to the beah policy module we added in bug 1077115 as mentioned in comment 6/comment 10. The beah policy module is included with beah-0.7.7-1.el7eng which is in the harness repos now.

The problem is just that we are hitting the bug of missing "permission kill in class service", which is bug 1150011. That bug is fixed in selinux-policy-3.13.1-6.el7 (I can successfully load the beah policy after installing that) but the latest RHEL7 nightlies still have 3.13.1-4.el7.

Once selinux-policy-3.13.1-6.el7 lands in RHEL7 nightlies this should be solved.

(In reply to Karel Srot from comment #20)
> could you please clarify what would be the actual fix. Are beaker tests
> supposed to be running as unconfined_service_t or unconfined_t (as on other
> RHELs)?

The expected result is tests will be running as unconfined_service_t when the distro has selinux-policy 3.13 (F21+ and RHEL7.1+).

And what about the transition from unconfined_service_t to unconfined_t? 
In some tests we need to run "runcon -t unconfined_t ..." in order to be able to pretend the execution of a "real" user. 

IMO tests should be rather running as unconfined_t, such as on a real session.

Karel,
this is what we suggest with Milos in previous comments. The point we will need to have also

# chcon -t bin_t /var/lib/beah/tortilla/wrappers.d/*

to make it working.

Sorry, my comment 29 was wrong... the expected result with the beah policy module (included in beah-0.7.7.el7eng) is tests will run as unconfined_t even though beah is started in unconfined_service_t.

Miroslav, I don't understand about

# chcon -t bin_t /var/lib/beah/tortilla/wrappers.d/*

Do we actually need that, if the beah policy module is installed?

I believe this is now fixed as of RHEL-7.1-20141028.n.0 with beah-0.7.7-1.el7eng (already live). Tests run as unconfined_t and there are no denials for runcon /usr/bin/true.

(In reply to Dan Callaghan from comment #33)
> I believe this is now fixed as of RHEL-7.1-20141028.n.0 with
> beah-0.7.7-1.el7eng (already live). Tests run as unconfined_t and there are
> no denials for runcon /usr/bin/true.

I agree.

+ echo '- eval id -Z ; ps -efZ | grep beah'
+ tee -a /mnt/testarea/tmp.iTFrxJ
- eval id -Z ; ps -efZ | grep beah
+ eval id -Z ';' ps -efZ '|' grep beah
++ id -Z
+ tee -a /mnt/testarea/tmp.iTFrxJ
system_u:unconfined_r:unconfined_t:s0
++ ps -efZ
++ grep beah
system_u:system_r:unconfined_service_t:s0 root 11623 1  0 05:46 ?      00:00:00 /usr/bin/python /usr/bin/beah-srv
system_u:system_r:unconfined_service_t:s0 root 11624 1  0 05:46 ?      00:00:00 /usr/bin/python /usr/bin/beah-beaker-backend
system_u:system_r:unconfined_service_t:s0 root 11625 1  0 05:46 ?      00:00:00 /usr/bin/python /usr/bin/beah-fwd-backend
system_u:system_r:unconfined_service_t:s0 root 11981 11623  1 05:46 ?  00:00:00 /usr/bin/python /usr/bin/beah-rhts-task
system_u:unconfined_r:unconfined_t:s0 root 12009 11981  0 05:47 ?      00:00:00 /bin/sh -x /var/lib/beah/tortilla/wrappers.d/runtest
system_u:unconfined_r:unconfined_t:s0 root 12107 12103  0 05:47 ?      00:00:00 grep beah

Closing this as fixed in beah 0.7.7 which was included with Beaker 0.18.3.

I see this problem again because policy module wasn't loaded.

Running transaction
  Installing : python-fpconst-0.7.3-12.el7.noarch                          1/10 
  Installing : SOAPpy-0.11.6-17.el7.noarch                                 2/10 
  Installing : pyserial-2.6-5.el7.noarch                                   3/10 
  Installing : rhts-python-4.65-1.el7eng.noarch                            4/10 
  Installing : python-zope-interface-4.0.5-4.el7.x86_64                    5/10 
  Installing : python-twisted-core-12.2.0-4.el7.x86_64                     6/10 
  Installing : python-twisted-web-12.1.0-4.el7.x86_64                      7/10 
  Installing : beah-0.7.8-1.el7eng.noarch                                  8/10 
libsepol.print_missing_requirements: beah's global requirements were not met: type/attribute unconfined_service_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory).
semodule:  Failed!
  Installing : rhts-test-env-4.65-1.el7eng.noarch                          9/10 
  Installing : beakerlib-1.10-1.el7.noarch                                10/10 
  Verifying  : python-twisted-web-12.1.0-4.el7.x86_64                      1/10 
  Verifying  : beah-0.7.8-1.el7eng.noarch                                  2/10 
  Verifying  : python-zope-interface-4.0.5-4.el7.x86_64                    3/10 
  Verifying  : rhts-test-env-4.65-1.el7eng.noarch                          4/10 
  Verifying  : beakerlib-1.10-1.el7.noarch                                 5/10 
  Verifying  : python-twisted-core-12.2.0-4.el7.x86_64                     6/10 
  Verifying  : rhts-python-4.65-1.el7eng.noarch                            7/10 
  Verifying  : pyserial-2.6-5.el7.noarch                                   8/10 
  Verifying  : SOAPpy-0.11.6-17.el7.noarch                                 9/10 
  Verifying  : python-fpconst-0.7.3-12.el7.noarch                         10/10


For more information see job https://beaker.engineering.redhat.com/jobs/843851

(In reply to David Spurek from comment #36)
> I see this problem again because policy module wasn't loaded.
[...]
> For more information see job
> https://beaker.engineering.redhat.com/jobs/843851

This is happening because you are using RHEL7.0 as the distro in your job, which has selinux-policy 3.12 which lacks unconfined_service_t. In that case the beah selinux policy module fails to load during installation, but that's expected, it's not needed there.

However in a later task you are upgrading to selinux-policy 3.13 which *does* define unconfined_service_t and needs the beah selinux policy module to avoid this AVC. So you are mixing and matching RHEL7.0 with RHEL7.1 selinux-policy.

I don't think there is anything Beaker can reasonably do about this. If you need the latest selinux-policy build then I suggest using the latest RHEL7.1 nightlies for you job instead of RHEL7.0 GA.

Thanks for the explanation. 

Using rhel7.1 isn't possible in all cases. Rhel7.0 is always used for errata testing and bugs verification.

But I understand that you need newer policy and without it module load fails.

(In reply to David Spurek from comment #38)

So I am open to suggestions on how I can solve that case, but I don't know of any way.

As a workaround you could add an extra task which does this, after upgrading selinux-policy to 3.13:

semodule -i /usr/share/selinux/packages/beah/beah.pp

(In reply to Dan Callaghan from comment #37)
> [...]
>
> However in a later task you are upgrading to selinux-policy 3.13 which
> *does* define unconfined_service_t and needs the beah selinux policy module
> to avoid this AVC. So you are mixing and matching RHEL7.0 with RHEL7.1
> selinux-policy.

Well, except that 3.13 is now actually 7.0.z policy, and even one that some
of our other 7.0.z tests depend on (Maybe not functionally, but to give clear,
authentic, and reassuring green result so that we can avoid AVC math and/or
hiding heisenbugs).

~

(In reply to Dan Callaghan from comment #39)
> 
> So I am open to suggestions on how I can solve that case, but I don't know
> of any way.
> 
> As a workaround you could add an extra task which does this, after upgrading
> selinux-policy to 3.13:
> 
> semodule -i /usr/share/selinux/packages/beah/beah.pp

So, let me step back a little:

  *  beah + policy <= 3.12.* ... needs 0 beah.pp
  *  beah + policy >= 3.13.* ... needs 1 beah.pp
  *  beah + future policies  ... may even need other beah.pp

so only way to upgrade upgrade policy safely is do it in one step with loading
beah.pp as well, right?

So what about having beah.pp in a separate, say, beah-selinux-policy package,
that would have requirements on particular -policy version, so that it would
always update (and load .pp and restart services) together?

(As a side note:  What would/should customer do?  Won't they face the same problem as they upgrade to 3.13?)

Here are the facts:
 * RHEL-7.0 and RHEL-7.0.z contains selinux-policy-3.12
 * RHEL-7.1 contains selinux-policy-3.13

beah.pp (which is not part of selinux-package) is needed in both RHEL-7.0.z and RHEL-7.1, but it was created to be compatible with selinux-policy-3.13, which means it fails to load on RHEL-7.0 and RHEL-7.0.z machines.

Here is my advice:
 * when installing RHEL-7.0 or RHEL-7.0.z, please use an older (which contains beah.pp compatible with selinux-policy-3.12) version of beah package
 * when installing RHEL-7.1 machine, please use the latest version of beah package
 * when upgrading machine from RHEL-7.0 to RHEL-7.1, please add a special task which upgrades selinux-policy packages, then upgrades beah packages and then restarts the beah processes (a reboot does the same work too)

Following beaker job illustrates that it is possible to get rid of the AVC mentioned in comment#0 without a reboot:

 * https://beaker.engineering.redhat.com/jobs/850831

After upgrading the selinux-policy it's necessary to restart beah* services, so they run under new contexts:

# service beah-srv restart ; sleep 5 ; service beah-fwd-backend restart ; sleep 5 ; service beah-beaker-backend restart

But you should avoid loading the beah.pp module, otherwise the beaker job finishes very quickly (all next tasks will abort).

Instead of loading the beah.pp, you should use following commands:

# yum -y install selinux-policy-devel
# echo -en 'policy_module(mypolicy,1.0)\n\nrequire {\ntype unconfined_service_t;\ntype unconfined_t;\nclass process { transition };\n}\n\nallow unconfined_service_t unconfined_t : process { transition };' > mypolicy.te
# make -f /usr/share/selinux/devel/Makefile
# semodule -i mypolicy.pp
# chcon -t bin_t /var/lib/beah/tortilla/wrappers.d/*

I thought that this bug was fixed months ago, but it somehow reappeared. The policy module is important, but the file contexts on /var/lib/beah/tortilla/wrappers.d/* are too.

Yes, the restart is needed.

(In reply to Milos Malik from comment #41)
> beah.pp (which is not part of selinux-package) is needed in both RHEL-7.0.z
> and RHEL-7.1, but it was created to be compatible with selinux-policy-3.13,
> which means it fails to load on RHEL-7.0 and RHEL-7.0.z machines.

This is not quite correct. beah.pp is not required on RHEL < 7.1. It was only added because of some policy changes related to the introduction of unconfined_service_t which happened in selinux-policy 3.13 (RHEL 7.1).

(In reply to Alois Mahdal from comment #40)
> So, let me step back a little:
> 
>   *  beah + policy <= 3.12.* ... needs 0 beah.pp
>   *  beah + policy >= 3.13.* ... needs 1 beah.pp
>   *  beah + future policies  ... may even need other beah.pp

This is correct.

> so only way to upgrade upgrade policy safely is do it in one step with
> loading beah.pp as well, right?

beah.pp doesn't need to be loaded in the very same yum transaction or anything, but it needs to be loaded before the next task begins if you want to avoid an AVC denial. I guess you would also need to restart the beah services and restorecon -r /var/lib/beah.

(In reply to Milos Malik from comment #43)
> After upgrading the selinux-policy it's necessary to restart beah* services,
> so they run under new contexts:
> 
> # service beah-srv restart ; sleep 5 ; service beah-fwd-backend restart ;
> sleep 5 ; service beah-beaker-backend restart

Yes good point, this is necessary also.

> But you should avoid loading the beah.pp module, otherwise the beaker job
> finishes very quickly (all next tasks will abort).
> 
> Instead of loading the beah.pp, you should use following commands:
> 
> # yum -y install selinux-policy-devel
> # echo -en 'policy_module(mypolicy,1.0)\n\nrequire {\ntype
> unconfined_service_t;\ntype unconfined_t;\nclass process { transition
> };\n}\n\nallow unconfined_service_t unconfined_t : process { transition };'
> > mypolicy.te
> # make -f /usr/share/selinux/devel/Makefile
> # semodule -i mypolicy.pp
> # chcon -t bin_t /var/lib/beah/tortilla/wrappers.d/*
> 
> I thought that this bug was fixed months ago, but it somehow reappeared. The
> policy module is important, but the file contexts on
> /var/lib/beah/tortilla/wrappers.d/* are too.

This custom policy should not be necessary. It looks the same as what is in beah.pp.

I guess the problem is just that, once beah.pp is loaded, it is necessary to restorecon -r /var/lib/beah as well to fix the contexts?

So in summary...

The latest beah will work correctly on RHEL7.0. (The beah.pp module will fail to load but it is not needed.)

The latest beah will work correctly on RHEL7.1.

But if you install RHEL7.0 and upgrade selinux-policy 3.12 -> 3.13 then you must also apply the following workaround to avoid the AVC in $SUBJECT:

semodule -i /usr/share/selinux/packages/beah/beah.pp
restorecon -r /var/lib/beah
service beah-srv restart
service beah-fwd-backend restart
service beah-beaker-backend restart
sleep 5 # because beah daemonizes before it's ready to serve requests

For example: https://beaker.dcallagh.beakerdevs.lab.eng.bne.redhat.com/jobs/759

To avoid the need for this workaround we would probably have to do something like Alois's suggestion comment 40: beah-selinux-policy subpackage with some Requires/Conflicts to make yum do the right thing when selinux-policy is upgraded. But I'm not really sure it's worth the effort of setting that up. Hopefully we won't ever need to have incompatible selinux policy modules within a RHEL release...

Closing this again since the current beah.pp should be working for RHEL7.1 onwards, and I assume the workaround in comment #46 is sufficient when upgrading RHEL7.0->7.1 selinux-policy.