Bug 508119 - Selinux denials on satellite proxy 530 w/ monitoring
Selinux denials on satellite proxy 530 w/ monitoring
Status: CLOSED NOTABUG
Product: Red Hat Satellite Proxy 5
Classification: Red Hat
Component: Server (Show other bugs)
530
All Linux
low Severity medium
: ---
: ---
Assigned To: Jan Pazdziora
wes hayutin
na
:
Depends On:
Blocks: 456999 457079 463877
  Show dependency treegraph
 
Reported: 2009-06-25 13:22 EDT by wes hayutin
Modified: 2009-06-29 07:53 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-29 07:50:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description wes hayutin 2009-06-25 13:22:42 EDT
Description of problem:

6/23 build rhel 5 enforcing
RHEL 530  satellite proxy


1. setup proxy (webui)
2. setup Monitoring 
3. create probes


noticed the following selinux denials in the audit log of the satellite proxy

notice lines referring to MonitoringScout, squid, and httpd

type=AVC msg=audit(1244564581.744:376): avc:  denied  { read } for  pid=1711 comm="MonitoringScout" path=2F746D702F73682D7468642D31323434353830373931202864656C6574656429 dev=dm-0 ino=1206506 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1244564582.774:377): avc:  denied  { read } for  pid=1767 comm="squid" path=2F746D702F73682D7468642D31323434353830373931202864656C6574656429 dev=dm-0 ino=1206506 scontext=root:system_r:squid_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1244564584.969:378): avc:  denied  { read } for  pid=1787 comm="squid" path=2F746D702F73682D7468642D31323434353830373931202864656C6574656429 dev=dm-0 ino=1206506 scontext=root:system_r:squid_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1244564586.226:379): avc:  denied  { read } for  pid=1808 comm="httpd" path=2F746D702F73682D7468642D31323434353830373931202864656C6574656429 dev=dm-0 ino=1206506 scontext=root:system_r:httpd_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file
type=AVC msg=audit(1244564587.571:384): avc:  denied  { read } for  pid=1869 comm="MonitoringScout" path=2F746D702F73682D7468642D31323434353830373931202864656C6574656429 dev=dm-0 ino=1206506 scontext=root:system_r:spacewalk_monitoring_t:s0 tcontext=root:object_r:tmp_t:s0 tclass=file
Comment 1 wes hayutin 2009-06-25 13:25:27 EDT
a problem that *may* be caused by this..
running a probe via command line returns..

On the proxy
-bash-3.2$ rhn-runprobe 29
2009-06-09 14:30:06 	No items changed
2009-06-09 14:30:06 	Notification not required
2009-06-09 14:30:06 	NOTE: Running in test mode; no changes saved, nothing enqueued
2009-06-09 14:30:06 
============================================================
OK: CPU load 1-min ave 0.00; CPU load 5-min ave 0.00; CPU load 15-min ave 0.00
============================================================
-bash-3.2$ 

webui stays on awaiting update
Probe:  	Linux: Load
Monitoring Scout 	Satellite Proxy dhcp77-204.rhndev.redhat.com (1000011527)
Status: 	PENDING, Awaiting update
Last update: 	6/9/09 2:31:33 PM EDT
Comment 2 Clifford Perry 2009-06-25 13:31:06 EDT
Going to approve, the command line usage of rhn-runprobe is not normal day-to-day usage, but commonly used as a troubleshooting step as outlined within our Monitoring section of the Reference Guide. 

Lets see if we can allow this, or make a note on why adding this to the policy is a bad idea. 

Cliff
Comment 3 wes hayutin 2009-06-25 13:36:36 EDT
once I set selinux to permissive.. on the webui I see


Probe: 	Linux: Load
Monitoring Scout 	Satellite Proxy dhcp77-204.rhndev.redhat.com (1000011527)
Status: 	OK, CPU load 1-min ave 0.03; CPU load 5-min ave 0.03; CPU load 15-min ave 0.00
Last update: 	6/9/09 2:35:55 PM EDT
Comment 4 Jan Pazdziora 2009-06-25 14:35:56 EDT
Wes, Cliff, I'm confused. Is this specific to running the probe as rhn-runprobe, or do the AVC denials appear when the probe is run by the monitoring code automatically as well?

When you switch to permissive, what are the AVC denials under permissive?

Mirek, this late in the game I'm going to need your help. The path 2F746D702F73682D7468642D31323434353830373931202864656C6574656429 generally means that the (temporary) file was deleted after it was open, and only its filehandle is available. In this case, it's the same "path" and inode passed around scout, squid, and httpd. My guess is that some stdin handler is passed around, perhaps some sort of <<inline-string in shell, or even some leaked file descriptor. Do you have an idea what is going on?
Comment 5 wes hayutin 2009-06-25 15:00:02 EDT
The listed denials may or may not be related to the probe not displaying the correct status in the webui.

Here is what I do know..

With SELinux enforcing
1. running the probe via command line works
2. the webui shows awaiting update

With SELinux permissive
1. running the probe via cmd line works
2. webui has the *correct* status

The denials listed in the bug were found on the satellite proxy while I was testing this particular probe.

I can try to investigate further, maybe you can point me in a direction.  I wanted to be sure to include those denials because I do not think we have *any* bugs regarding selinux denials on a satellite proxy.

Anyway, I just wanted to report what I saw.
Thanks
Comment 6 Miroslav Suchý 2009-06-29 07:50:50 EDT
Reading your part of audit.log, it seems that it happend during last step of WebUI installer, where is run remote command "/usr/sbin/rhn-proxy restart" - so setting up probe should be not necessary.
However even if I set up probe, I have not been able to reproduce this. I have been trying hard whole this day, without any luck.
I'm closing this as NOTABUG. if you disagree and can provide deterministics reproducer, please reopen.
Comment 7 Jan Pazdziora 2009-06-29 07:53:31 EDT
Further observation: the AVCs are from June 9:

# date -d @1244564581
Tue Jun  9 18:23:01 CEST 2009

So they seem like old messages, from before the RHN-Proxy-5.3.0-RHEL5-re20090623.0 was even installed.

Note You need to log in before you can comment on or make changes to this bug.