Bug 1134503

Need to really know what does it block, because I see all contexts set properly and all services looks fine. On that box I see some denials but these are all known bugs fixed in the upcoming snap (27th):

[root@ibm-x3550m3-13 ~]# ausearch -m AVC
----
time->Tue Aug 26 23:12:45 2014
type=SYSCALL msg=audit(1409087565.693:315): arch=c000003e syscall=4 success=no exit=-13 a0=7f0799c1f9b6 a1=7fff4365f630 a2=7fff4365f630 a3=7fff436614d0 items=0 ppid=1 pid=28783 auid=4294967295 uid=996 gid=995 euid=996 suid=996 fsuid=996 egid=995 sgid=995 fsgid=995 tty=(none) ses=4294967295 comm="qpidd" exe="/usr/sbin/qpidd" subj=system_u:system_r:qpidd_t:s0 key=(null)
type=AVC msg=audit(1409087565.693:315): avc:  denied  { getattr } for  pid=28783 comm="qpidd" path="/etc/passwd" dev="dm-0" ino=136689785 scontext=system_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:passwd_file_t:s0 tclass=file
----
time->Tue Aug 26 23:15:00 2014
type=SYSCALL msg=audit(1409087700.286:375): arch=c000003e syscall=49 success=no exit=-13 a0=d a1=7f5288258f30 a2=10 a3=0 items=0 ppid=29751 pid=29819 auid=4294967295 uid=52 gid=52 euid=52 suid=52 fsuid=52 egid=52 sgid=52 fsgid=52 tty=(none) ses=4294967295 comm="ruby" exe="/usr/bin/ruby" subj=system_u:system_r:passenger_t:s0 key=(null)
type=AVC msg=audit(1409087700.286:375): avc:  denied  { name_bind } for  pid=29819 comm="ruby" src=18069 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=udp_socket
----
time->Wed Aug 27 17:11:49 2014
type=SYSCALL msg=audit(1409152309.558:656): arch=c000003e syscall=4 success=no exit=-13 a0=7f38604019b6 a1=7fff6c719300 a2=7fff6c719300 a3=7fff6c71b1a0 items=0 ppid=1 pid=971 auid=4294967295 uid=996 gid=995 euid=996 suid=996 fsuid=996 egid=995 sgid=995 fsgid=995 tty=(none) ses=4294967295 comm="qpidd" exe="/usr/sbin/qpidd" subj=system_u:system_r:qpidd_t:s0 key=(null)
type=AVC msg=audit(1409152309.558:656): avc:  denied  { getattr } for  pid=971 comm="qpidd" path="/etc/passwd" dev="dm-0" ino=136203740 scontext=system_u:system_r:qpidd_t:s0 tcontext=system_u:object_r:passwd_file_t:s0 tclass=file
----
time->Wed Aug 27 17:15:02 2014
type=SYSCALL msg=audit(1409152502.399:684): arch=c000003e syscall=49 success=no exit=-13 a0=d a1=7fc09c321ab0 a2=10 a3=0 items=0 ppid=1673 pid=1724 auid=4294967295 uid=52 gid=52 euid=52 suid=52 fsuid=52 egid=52 sgid=52 fsgid=52 tty=(none) ses=4294967295 comm="ruby" exe="/usr/bin/ruby" subj=system_u:system_r:passenger_t:s0 key=(null)
type=AVC msg=audit(1409152502.399:684): avc:  denied  { name_bind } for  pid=1724 comm="ruby" src=22845 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=udp_socket

Corey, if you encounter this again in the next snap, please paste output of the following commands in this order:

  rpm -q foreman-selinux selinux-policy
  getenforce
  ps auxZ | grep RackApp
  semodule -l | grep foreman
  foreman-selinux-enable
  foreman-selinux-disable
  foreman-selinux-enable
  foreman-selinux-relabel -v
  semanage boolean -l
  semanage fcontext -l
  sepolgen-ifgen &>/dev/null && audit2allow -Ra || audit2allow -a
  ausearch -m AVC -m USER_AVC -m SELINUX_ERR | head -n 50

I can see this on a RHEL 7 capsule built from Satellite-6.0.4-RHEL-7-20140829.0, however I don't believe it's an AVC, it's something else.  As such, I'm reducing the severity & blocker status as I don't believe it's affecting functionality, unless Corey observed otherwise.

It's logging from the Puppet master, probably while managing internal file permissions on startup.

Created attachment 933410 [details]
selinux commands

I have also run into this issue as of 2015-01-07. 
in /var/log/messages

Jan 10 10:50:15 sat6 puppet-master[4444]: /etc/selinux/targeted/contexts/files/file_contexts:  invalid context system_u:object_r:puppet_var_lib_t:s0
Jan 10 10:50:16 sat6 puppet-master[4444]: failed to set mode 644 on /var/log/puppet/masterhttp.log: Permission denied - /var/log/puppet/masterhttp.log
Jan 10 10:50:16 sat6 puppet-master[4444]: (/File[/var/log/puppet/masterhttp.log]/mode) change from 0644 to 0660 failed: failed to set mode 644 on /var/log/puppet/masterhttp.log: Permission denied - /var/log/puppet/masterhttp.log
Jan 10 10:50:16 sat6 puppet-master[4444]: Could not prepare for execution: Got 1 failure(s) while initializing: File[/var/log/puppet/masterhttp.log]: change from 0644 to 0660 failed: failed to set mode 644 on /var/log/puppet/masterhttp.log: Permission denied - /var/log/puppet/masterhttp.log
Jan 10 10:50:34 sat6 foreman-tasks: ............................................................................................................................executor started successfully
Jan 10 10:50:35 sat6 systemd: Started Foreman jobs daemon.

in /var/log/audit/audit.log


type=SYSCALL msg=audit(1420905388.791:1264): arch=c000003e syscall=90 success=no exit=-13 a0=2b289e0 a1=1b0 a2=7fff2a3149fc a3=7fff2a314760 items=0 ppid=4187 pid=4818 auid=4294967295 uid=52 gid=52 euid=52 suid=52 fsuid=52 egid=52 sgid=52 fsgid=52 tty=(none) ses=4294967295 comm="ruby" exe="/usr/bin/ruby" subj=system_u:system_r:passenger_t:s0 key=(null)
type=AVC msg=audit(1420905424.574:1265): avc:  denied  { setattr } for  pid=4855 comm="ruby" name="masterhttp.log" dev="dm-2" ino=247370 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:puppet_log_t:s0 tclass=file


running the above suggested commands has no effect.

Of course, setenforce 0 masks the problem.

Regards,

Paul

Note: 
if setenforce 1 is executed after katello-service restart all is good.
Everything checks in fine.
env: RHEL7 + Sat 6.0.6
RHEL7 and RHEL6 clients of all stripes :-) KVM, RHEV and Phys.

Passenger needs to be added setattr permissions.

Workaround: setenforce 0 during the installer, then go back to enforcing mode for operation as all context and permissions should already be correct.

Ran into this again after upgrade to 6.0.8...

again... setenforce 0 ... katello-service restart ... setenforce 1
now when katello-service restart is run - the error no longer occurs and clients can checkin

Paul,

we have identified a different bug that did not make it into the errata. Our upgrade RPM post scriplet does not reload the policy, so you are likely still running the old version.

Can you please do this:

semodule -l | grep foreman
foreman-selinux-enable
semodule -l | grep foreman

and retest?

We will fix this in the next errata.

I am closing the original bug as it does not affect Capsule installation to my knowledge. The "invalid context" warning is harmless.

Paul, in your case run the commands above to fix this issue. This was fixed in the latest errata (ON_QA currently).

https://bugzilla.redhat.com/show_bug.cgi?id=1193483
https://errata.devel.redhat.com/advisory/19821