Bug 487221

(In reply to comment #0)
> Description of problem:
> 
> Going into the Satellite Admin link on satellite and enabling monitoring causes
> selinux denials.  The satellite after being restarted does NOT render the
> monitoring link under the satellite config to enable the monitoring scout.
> 
> 
> recreate.
> 1. install a fresh satellite
> my build = Satellite-5.3.0-RHEL5-re20090220.1-i386-embedded-oracle.iso
> 
> 2. clear selinux audit log
> 
> 3. in webui admin -> rhn sat configuration -> 
> check "enable monitoring"
> 
> 4. restart satellite

How did you restart the Satellite? In bug 487235, restart is not possible via WebUI after enabling monitoring. How was the restart done in this case?

The yp sounds like Yellow Pages, and port 111 is sunrpc. So it might be related to whatever you authentication settings are.

Could you please get the command line of the process causing the problem? Something like

  # cat /proc/10066/cmdline

and

  # ps axuw | grep 10066

Thank you.

Also, if you have Satellite in disabled or permissive SELinux mode, will monitoring link be there? Because I don't see that on my Satellite, and I do not get the rpc-related SELinux messages because I don't use Yellow Pages, so I wonder if the monitoring activation is busted, without SElinux even coming into play.

OK.. Monitoring did indeed change from the last iso to this iso.  
1. turned off selinux
2. enabled monitoring
3. can not enable monitoring scout

I guess its possible that having selinux enabled at install time may be messing this up. I'll leave this bug open as I look at the possibility.

Wes, I'd need the information about the command causing the problem (process 10066 in the above comment #3). That part is valid SELinux report which I'd like to address.

sorry had to reinstall

ap_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.512:623): avc:  denied  { node_bind } for  pid=11351 comm="gogo.pl" scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.512:624): avc:  denied  { name_bind } for  pid=11351 comm="gogo.pl" src=928 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.512:625): avc:  denied  { name_connect } for  pid=11351 comm="gogo.pl" dest=111 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.530:626): avc:  denied  { search } for  pid=11363 comm="gogo.pl" name="yp" dev=dm-0 ino=8716332 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=dir
type=AVC msg=audit(1235586299.531:627): avc:  denied  { node_bind } for  pid=11363 comm="gogo.pl" scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.532:628): avc:  denied  { name_bind } for  pid=11363 comm="gogo.pl" src=929 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.532:629): avc:  denied  { name_connect } for  pid=11363 comm="gogo.pl" dest=111 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.532:630): avc:  denied  { node_bind } for  pid=11363 comm="gogo.pl" scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.532:631): avc:  denied  { name_bind } for  pid=11363 comm="gogo.pl" src=930 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.532:632): avc:  denied  { name_connect } for  pid=11363 comm="gogo.pl" dest=111 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.551:633): avc:  denied  { search } for  pid=11363 comm="gogo.pl" name="yp" dev=dm-0 ino=8716332 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=dir
type=AVC msg=audit(1235586299.551:634): avc:  denied  { node_bind } for  pid=11363 comm="gogo.pl" scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.552:635): avc:  denied  { name_bind } for  pid=11363 comm="gogo.pl" src=931 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1235586299.552:636): avc:  denied  { name_connect } for  pid=11363 comm="gogo.pl" dest=111 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket


[root@rlx-3-18 audit]# ps -ef | grep 11363
apache   11363 11362  0 13:24 pts/0    00:00:00 /usr/bin/perl /usr/bin/gogo.pl --fname=TSDBLocalQueue --user=apache -- /usr/bin/TSDBLocalQueue.pl
apache   11364 11363  0 13:25 pts/0    00:00:00 /usr/bin/perl /usr/bin/TSDBLocalQueue.pl
root     11811  3316  0 13:26 pts/2    00:00:00 grep 11363
[root@rlx-3-18 audit]# ps -ef | grep 11351
root     11878  3316  0 13:26 pts/2    00:00:00 grep 11351
[root@rlx-3-18 audit]# ps -ef | grep 11330
nocpulse 11330 11327  0 13:24 pts/0    00:00:00 /usr/bin/perl /usr/bin/ack-processor
root     11952  3316  0 13:26 pts/2    00:00:00 grep 11330
[root@rlx-3-18 audit]# ps -ef | grep 11327
nocpulse 11327 11326  0 13:24 pts/0    00:00:00 /usr/bin/perl /usr/bin/gogo.pl --fname=AckProcessor --user=nocpulse --hbfile=/var/log/nocpulse/ack_handler.log --hbfreq=300 --hbcheck=600 -- /usr/bin/ack-processor
nocpulse 11330 11327  0 13:24 pts/0    00:00:00 /usr/bin/perl /usr/bin/ack-processor
root     12280  3316  0 13:27 pts/2    00:00:00 grep 11327

[root@rlx-3-18 audit]# cat /proc/11363/cmdline 
/usr/bin/perl/usr/bin/gogo.pl--fname=TSDBLocalQueue--user=apache--/usr/bin/TSDBLocalQueue.pl[root@rlx-3-18 audit]#

Created attachment 333199 [details]
the full audit.log and process log after enabling monitoring

the full audit.log and process log after enabling monitoring

The missing monitoring tab is tracked in bug 458355. Let's reserve this bugzilla for the AVC denials only.

Fix allowing monitoring to use NIS in Spacewalk repo, commit 249b6add2baef06d94130267c803f2453963b0b9.

Tagged as spacewalk-monitoring-selinux-0.5.6-1.

With compose Satellite-5.3.0-RHEL5-re20090327.0 available, moving ON_QA.

verified 4/20 build

This is not completely fixed.

Final 5.3.0 build, fresh installation on RHEL5.4, s390x, NIS enabled in
nsswitch.conf, domain redhat.com, server l2.corp.redhat.com, monitoring
and monitoring scout enabled, after satellite restart:

type=AVC msg=audit(1252500859.811:144): avc:  denied  { name_connect } for  
pid=6781 comm="execute_command" dest=111 
scontext=system_u:system_r:spacewalk_monitoring_t:s0 
tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket

Reopening and punting to sat600-triage for re-evaluation.

The denial from comment #13 might have been caused by running monitoring
in between the short amount of time when authconfig changed /etc/nsswitch.conf
to use NIS/YP and when authconfig enabled allow_ypbind selinux boolean.

I'm not able to reproduce the denial after the whole thing was setup
and the satellite was restarted (as in no denials like this after that).

We got similar problems on a 5.3 installation with kerberos/ldap user authentication and the following nsswitch parameters:

passwd:     files ldap
group:      files ldap

The following AVCs are generated during gogo.pl startup:

type=AVC msg=audit(1258727442.211:5924): avc:  denied  { name_connect } for  pid=15985 comm="gogo.pl" dest=389 scontext=user_u:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:ldap_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1258727442.211:5924): arch=c000003e syscall=42 success=no exit=-13 a0=5 a1=209c3e90 a2=10 a3=0 items=0 ppid=15984 pid=15985 auid=19187 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=873 comm="gogo.pl" exe="/usr/bin/perl" subj=user_u:system_r:spacewalk_monitoring_t:s0 key=(null)
type=AVC msg=audit(1258727442.211:5925): avc:  denied  { create } for  pid=15985 comm="gogo.pl" scontext=user_u:system_r:spacewalk_monitoring_t:s0 tcontext=user_u:system_r:spacewalk_monitoring_t:s0 tclass=unix_dgram_socket
type=SYSCALL msg=audit(1258727442.211:5925): arch=c000003e syscall=41 success=no exit=-13 a0=1 a1=2 a2=0 a3=5041444c206f7420 items=0 ppid=15984 pid=15985 auid=19187 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=873 comm="gogo.pl" exe="/usr/bin/perl" subj=user_u:system_r:spacewalk_monitoring_t:s0 key=(null)
type=AVC msg=audit(1258727442.211:5926): avc:  denied  { create } for  pid=15985 comm="gogo.pl" scontext=user_u:system_r:spacewalk_monitoring_t:s0 tcontext=user_u:system_r:spacewalk_monitoring_t:s0 tclass=unix_dgram_socket
type=SYSCALL msg=audit(1258727442.211:5926): arch=c000003e syscall=41 success=no exit=-13 a0=1 a1=2 a2=0 a3=205041444c206863 items=0 ppid=15984 pid=15985 auid=19187 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=873 comm="gogo.pl" exe="/usr/bin/perl" subj=user_u:system_r:spacewalk_monitoring_t:s0 key=(null)

But in general this is not a SELinux problem, as from a gogo.pl strace:

10291 getsockname(5, {sa_family=AF_INET, sin_port=htons(47740), sin_addr=inet_addr("xx.xx.xx.xx")}, [9583941490611060752]) = 0
10291 getpeername(5, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("yy.yy.yy.yy")}, [68719476752]) = 0

the process (which calls SetID) continuously tries to query our Kerberos Server even if SELinux is set to permissive.

auth        requisite     pam_succeed_if.so uid >= 500 quiet

is configured within system-auth and the user id of nocpulse is 101 with gid 102.

In this case, noculse should not ever try to query the kerberos server.

Best Regards
Marcus

In my case monitoring was failing on selinux too.
Here policy which resolved for me the issue 



module spacewalk 1.0;

require {
        type var_run_t;
        type etc_t;
        type spacewalk_monitoring_t;
        class file { write ioctl read unlink open getattr append };
}

#============= spacewalk_monitoring_t ==============

#!!!! This avc is allowed in the current policy
allow spacewalk_monitoring_t etc_t:file unlink;
allow spacewalk_monitoring_t var_run_t:file { ioctl getattr };

#!!!! This avc is allowed in the current policy
allow spacewalk_monitoring_t var_run_t:file { read write open append };


[root@qa01repo00 tmp]# /etc/init.d/Monitoring start
Starting Monitoring ...  
	Starting InstallSoftwareConfig ...  [ OK ]
	Starting NotifEscalator ...  [ OK ]
	Starting GenerateNotifConfig ...  [ OK ]
	Starting NotifLauncher ...  [ OK ]
	Starting Notifier ...  [ OK ]
	Starting AckProcessor ...  [ OK ]
	Starting TSDBLocalQueue ...  [ OK ]
[ OK ]

Created attachment 910109 [details]
spacewalk selinux pp file

Thias is selinux policy file for spacewalk monitoring startup.

Remains reproducible on Sat5.7. Suggested policy in patch doesn't quite fix it; investigating

Some audit2allow'ing and restarting suggests the following fixes the problem:

===
module spacewalk04 1.0;

require {
        type spacewalk_monitoring_t;
        type tomcat_var_run_t;
        type tomcat_t;
        class file { lock unlink read write ioctl open getattr append };
        class process { signull };
}

#============= spacewalk_monitoring_t ==============
allow spacewalk_monitoring_t tomcat_t:process signull;
allow spacewalk_monitoring_t tomcat_var_run_t:file { read write ioctl open getattr append lock unlink };

===

Even though we have a patch, there's no plan to backport the patch to Sat 5.6 / 5.7. (Sat 5.8 is not affected.)

As this issue has been originally reported for Sat 5.3 I'm closing the BZ EOL.