Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 628872

Summary: init script searches cwd which can cause SELinux denials
Product: Red Hat Enterprise Linux 6 Reporter: Milos Malik <mmalik>
Component: piranhaAssignee: Ryan O'Hara <rohara>
Status: CLOSED ERRATA QA Contact: Cluster QE <mspqa-list>
Severity: low Docs Contact:
Priority: low    
Version: 6.2CC: cluster-maint, djansa, dwalsh, jkortus, rohara, ssaha
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: piranha-0.8.5-9.el6 Doc Type: Bug Fix
Doc Text:
Previously, the piranha-gui init script searched for programs in the current working directory. As a consequence, SELinux Access Vector Cache (AVC) denials could be generated when starting the piranha-gui service in unusual locations without the "service" utility. The init script has been modified to avoid this problem. Now, SELinux denials are no longer logged.
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-06 17:57:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Workaround / fix none

Description Milos Malik 2010-08-31 09:09:37 UTC
Description of problem:
Some administrators don't use "service" command when managing a service. They
still do it this way:
/etc/init.d/SERVICE start
/etc/init.d/SERVICE restart
/etc/init.d/SERVICE stop
This procedure can cause SELinux denials when an administrator issues the
command in unusual location (usual location is for example / or /root ,
selinux-policy is aware of usual locations and SELinux denials are
dontaudited). I would like to ask to fix the init script in such a way that it
does not search for programs in current working directory.

Version-Release number of selected component (if applicable):
piranha-0.8.5-7.el6.i686
selinux-policy-3.7.19-42.el6.noarch
selinux-policy-doc-3.7.19-42.el6.noarch
selinux-policy-minimum-3.7.19-42.el6.noarch
selinux-policy-mls-3.7.19-42.el6.noarch
selinux-policy-targeted-3.7.19-42.el6.noarch

How reproducible:
always

Steps to Reproduce:
# cd /var/log/audit
# /etc/init.d/piranha-gui start
Starting piranha-gui:                                      [  OK  ]
# /etc/init.d/piranha-gui stop
Shutting down piranha-gui:                                 [  OK  ]
# ausearch -m avc -ts recent
----
time->Tue Aug 31 10:47:27 2010
type=SYSCALL msg=audit(1283244447.370:184): arch=40000003 syscall=195 success=yes exit=0 a0=9abef28 a1=bfcdd270 a2=6fdff4 a3=0 items=0 ppid=4517 pid=4518 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="piranha_gui" exe="/bin/bash" subj=unconfined_u:system_r:piranha_web_t:s0 key=(null)
type=AVC msg=audit(1283244447.370:184): avc:  denied  { getattr } for  pid=4518 comm="piranha_gui" path="/var/log/audit" dev=dm-0 ino=9973 scontext=unconfined_u:system_r:piranha_web_t:s0 tcontext=system_u:object_r:auditd_log_t:s0 tclass=dir
----
time->Tue Aug 31 10:47:27 2010
type=SYSCALL msg=audit(1283244447.377:185): arch=40000003 syscall=195 success=yes exit=0 a0=80e95f3 a1=bfcdd210 a2=6fdff4 a3=bfcdd210 items=0 ppid=4517 pid=4518 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="piranha_gui" exe="/bin/bash" subj=unconfined_u:system_r:piranha_web_t:s0 key=(null)
type=AVC msg=audit(1283244447.377:185): avc:  denied  { search } for  pid=4518 comm="piranha_gui" name="audit" dev=dm-0 ino=9973 scontext=unconfined_u:system_r:piranha_web_t:s0 tcontext=system_u:object_r:auditd_log_t:s0 tclass=dir
----

Actual results:
2 AVCs appear

Expected results:
no AVC appears

Additional info:

Comment 1 Marek Grac 2011-01-26 16:41:58 UTC
@Milos:

As we spoke together. I was not able to reproduce this AVC on every run but only in some of them. Setting needinfo just for tracking purposes.

Comment 5 Lon Hohberger 2011-08-04 18:58:55 UTC
Reproducer:

# cd /var/log/audit
# /etc/init.d/piranha-gui start

Comment 6 Lon Hohberger 2011-08-04 18:59:34 UTC
Note, Ryan and I were unable to reproduce if using the 'service' script instead.  The piranha_gui application is just a wrapper around httpd.

Comment 7 Ryan O'Hara 2011-08-04 19:09:55 UTC
Also note that changing the context of /usr/sbin/piranha_gui causes even more problems (name_bind failures):

chcon system_u:object_r:bin_t:s0 /usr/sbin/piranha_gui

/etc/init.d/piranha-gui start

type=AVC msg=audit(1312484886.287:81910): avc:  denied  { name_bind } for  pid=12434 comm="httpd" src=3636 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:piranha_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1312484886.287:81910): arch=c000003e syscall=49 success=no exit=-13 a0=4 a1=7fd074a5f848 a2=1c a3=7fffbdaf0c90 items=0 ppid=12433 pid=12434 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=7690 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1312484886.287:81911): avc:  denied  { name_bind } for  pid=12434 comm="httpd" src=3636 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:piranha_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1312484886.287:81911): arch=c000003e syscall=49 success=no exit=-13 a0=3 a1=7fd074a5f788 a2=10 a3=7fffbdaf0efc items=0 ppid=12433 pid=12434 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=7690 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

This was just a test to see if it was as simple as changing the context. Seems like something needs changed in the selinux policy.

Comment 8 Daniel Walsh 2011-08-04 20:38:23 UTC
If you want apache to be able to bind to port 3636, you will need to add custom policy using audit2allow 


grep 3636 /var/log/audit/audit.log | audit2allow -M myhttp
semodule -i myhttp

Comment 9 Miroslav Grepl 2011-08-04 20:40:49 UTC
Why are you changing the label on  /usr/sbin/piranha_gui? 

Of course then it won't work because the transition won't happen to piranha_web_t.

Comment 10 Ryan O'Hara 2011-08-05 19:33:34 UTC
The real problem is not name_bind. Sorry for the confusion. Ignore comment #7. I only changed the context of /usr/sbin/piranha_gui as a test to see what would happen. That bit of information is worthless.

Please refer to comment #1, which has the audit log for the actual problem.

Comment 11 Lon Hohberger 2011-08-05 20:48:01 UTC
I have a workaround in the initscript which addresses the issue, although I believe it to be suboptimal:

[root@snap ~]# service piranha-gui start
Starting piranha-gui: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.122.20 for ServerName
                                                           [  OK  ]
[root@snap ~]# service piranha-gui stop
Shutting down piranha-gui:                                 [  OK  ]
[root@snap ~]# /etc/init.d/piranha-gui start
Starting piranha-gui: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.122.20 for ServerName
                                                           [  OK  ]
[root@snap ~]# /etc/init.d/piranha-gui stop
Shutting down piranha-gui:                                 [  OK  ]
[root@snap ~]# cd /var/log/audit
[root@snap audit]# /etc/init.d/piranha-gui start
Starting piranha-gui: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.122.20 for ServerName
                                                           [  OK  ]
[root@snap audit]# getenforce
Enforcing
[root@snap audit]# service piranha-gui status
httpd (pid 26050 26048) is running...

Comment 12 Lon Hohberger 2011-08-05 20:58:09 UTC
Created attachment 516956 [details]
Workaround / fix

There is no reason for this patch to go upstream; upstream uses a symlink, not a script wrapper around httpd.  As such, this fix not only does not apply to upstream, but it does not resolve any known issues there, either.

Comment 17 Eliska Slobodova 2011-10-25 09:50:24 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, the piranha-gui init script searched for programs in the current working directory. As a consequence, SELinux Access Vector Cache (AVC) denials could be generated when starting the piranha-gui service in unusual locations without the "service" utility. The init script has been modified to avoid this problem. Now, SELinux denials are no longer logged.

Comment 18 errata-xmlrpc 2011-12-06 17:57:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1716.html