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 966549 - Sudo auditing problems when selinux is enforced
Summary: Sudo auditing problems when selinux is enforced
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.4
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: 6.4
Assignee: Miroslav Grepl
QA Contact: BaseOS QE Security Team
URL: http://www.ilsistemista.net
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-23 13:13 UTC by g.danti
Modified: 2013-08-06 07:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-06 07:06:50 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
PHP test file (107 bytes, application/x-php)
2013-05-23 13:16 UTC, g.danti 		no flags Details
Selinux policy template (2.32 KB, text/plain)
2013-05-23 13:17 UTC, g.danti 		no flags Details
Selinux binary policy (4.11 KB, application/octet-stream)
2013-05-23 13:18 UTC, g.danti 		no flags Details
Sudo debug log (5.46 KB, text/x-log)
2013-05-23 13:19 UTC, g.danti 		no flags Details
View All

Description g.danti 2013-05-23 13:13:51 UTC 
Description of problem:
I have a web application that use the exec() function to call "sudo -H -u amavis amavisd-release" (see attached test file for an example). When selinux is enforced, sudo correctly completes but also return this error:
"sudo: unable to send audit message: Permission denied"

Searching in the /var/log/audit/audit.log show no useful information (I already modified the default selinux policy to allow the execution of an external script and a sudo session from within an httpd process).

If I use selinux in permissive mode, the error message is not returned, but in the /var/log/audit/audit.log file I can not see any "denied" message.

Curiously, if I execute the command from a bash shell using the apache user (I change apache's user to launch /bin/bash for testing purpose) I can not see any error.

In the sudo debug log, I can see a message stating "May 23 14:44:16 sudo[1952] unable to send audit message: Permission denied @ linux_audit_command() ./linux_audit.c:93"

Version-Release number of selected component (if applicable):
sudo-1.8.6p3-7.el6.x86_64
selinux-policy-targeted-3.7.19-195.el6_4.5.noarch
libselinux-utils-2.0.94-5.3.el6_4.1.x86_64
libselinux-python-2.0.94-5.3.el6_4.1.x86_64
selinux-policy-3.7.19-195.el6_4.5.noarch
kernel-2.6.32-358.el6.x86_64

How reproducible:
Always (100%)

Steps to Reproduce:
1. setup sudo to don't require a tty
2. load the attached selinux custom policy
3. launch the attached php file from within apache
4. you will have a "sudo: unable to send audit message: Permission denied" error.

Actual results:
While sudo correctly completes, you have an error stating "sudo: unable to send audit message: Permission denied"

Expected results:
Sudo should execute without error. On the other side, if the selinux policy somehow deny sudo to send an audit message, this should be logged somewhere.

Additional info:
I attached four files:
1) the php test file
2) the selinux custom policy template
3) the selinux custom binary policy
4) the complete sudo debug log.
Comment 1 g.danti 2013-05-23 13:16:15 UTC 
Created attachment 752201 [details]
PHP test file
Comment 2 g.danti 2013-05-23 13:17:51 UTC 
Created attachment 752202 [details]
Selinux policy template
Comment 3 g.danti 2013-05-23 13:18:39 UTC 
Created attachment 752203 [details]
Selinux binary policy
Comment 4 g.danti 2013-05-23 13:19:28 UTC 
Created attachment 752204 [details]
Sudo debug log
Comment 6 Daniel Walsh 2013-05-23 18:20:24 UTC 
Can you turn off the dontaudit rules.

semodule -DB

logging_send_audit_msgs(YOURDOMAIN_T)

Will allow your domain to send audit messages.
Comment 7 g.danti 2013-05-24 08:28:43 UTC 
Thank you very much Daniel!
I simply ignored the don't audit facility and so I were stumbled in this problem.

After disabling the don't audit rules, I was able to find the offending messages and to grant the specific permission needed to run sudo without issues.

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