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 853453 - SELinux vs .forward script on nfs
Summary: SELinux vs .forward script on nfs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.3
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-31 15:12 UTC by Brian Wheeler
Modified: 2013-02-21 08:28 UTC (History)
3 users (show)

Fixed In Version: selinux-policy-3.7.19-166.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 08:28:27 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0314 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2013-02-20 20:35:01 UTC

Description Brian Wheeler 2012-08-31 15:12:50 UTC 
Description of problem:

I've got a user who wants to run a script specified in their .forward file:

.forward (USER.USER 0664)
=============
|/home/USER/Code/forwardbuildresults.sh
=============

The script seems to be correct as well:
-rwxrwxr-x. USER USER system_u:object_r:nfs_t:s0 /home/USER/Code/forwardbuildresults.sh


but when he tries to catch the mail, this shows up in maillog:
Aug 30 11:29:49 pine postfix/local[29020]: 54A6976B: to=<USER@pine>, relay=local, delay=537, delays=537/0.02/0/0.02, dsn=4.3.0, status=deferred (temporary failure. Command output: local: fatal: execvp /home/USER/Code/forwardbuildresults.sh: Permission denied )

and this shows up in /var/log/messages:
Aug 30 11:29:53 pine setroubleshoot: SELinux is preventing /usr/libexec/postfix/local from execute access on the file forwardbuildresults.sh. For complete SELinux messages. run sealert -l a97ab991-717f-43bb-a990-1017bca686e9

sealert is pretty worthless in this case:
===============================
SELinux is preventing /usr/libexec/postfix/local from execute access on the file forwardbuildresults.sh.

*****  Plugin leaks (86.2 confidence) suggests ******************************

If you want to ignore local trying to execute access the forwardbuildresults.sh file, because you believe it should not need this access.
Then you should report this as a bug.
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/libexec/postfix/local /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests ***************************

If you believe that local should be allowed execute access on the forwardbuildresults.sh file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep local /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
==================================

since the file resides on nfs there isn't any way to reset the context type...is there a magic setting for postfix that will let this go through?

Version-Release number of selected component (if applicable):

postfix-2.6.6-2.2.el6_1.x86_64
selinux-policy-targeted-3.7.19-155.el6_3.noarch
selinux-policy-3.7.19-155.el6_3.noarch

How reproducible:

This is the only instance I've tested


Steps to Reproduce:
1. have a nfs-based home
2. set a script to be the target in .forward
3. try sending mail
  
Actual results:

script is denied execution

Expected results:

script processes email

Additional info:
Comment 2 Brian Wheeler 2012-09-21 19:08:19 UTC 
3 weeks and no response?
Comment 3 Jaroslav Škarvada 2012-09-24 09:34:53 UTC 
(In reply to comment #2)
> 3 weeks and no response?

Bugzilla is not support tool and doesn't have guaranteed response time.

If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain  it receives the proper attention and prioritization to assure a timely resolution. 

For information on how to contact the Red Hat production support team, please visit:

https://www.redhat.com/support/process/production/#howto
Comment 4 Jaroslav Škarvada 2012-09-24 09:43:06 UTC 
(In reply to comment #0)

> since the file resides on nfs there isn't any way to reset the context
> type...is there a magic setting for postfix that will let this go through?
> 
The access is blocked in kernel by SELinux, no way to bypass in postfix.

You can export the Code directory and mount it with option context (man mount) to force the context or you can use procmail (.procmailrc instead of .forward). CCing SELinux guys in case there have more info.
Comment 5 Miroslav Grepl 2012-09-24 11:19:01 UTC 
Just to be sure could you attach AVC msgs?

# grep nfs_t /var/log/audit/audit.log
Comment 6 Brian Wheeler 2012-09-24 12:56:24 UTC 
Here's the typical AVC:

type=AVC msg=audit(1348490756.116:1732984): avc:  denied  { execute } for  pid=19174 comm="local" name="forwardbuildresults.sh" dev=0:17 ino=102400013 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=file


I know bugzilla isn't a support tool, but I was just surprised that nobody responded in 3 weeks...usually I've seen faster responses.

Also, I can't really mess with the mount context without messing up other things at this point since I've used the booleans which allow nfs_t for the other services which are using data on this filesystem.
Comment 7 Miroslav Grepl 2012-09-24 13:21:46 UTC 
You can allow it using 

# grep nfs_t /var/log/audit/audit.log | audit2allow -M mypostfix
# semodule -i mypostfix.pp
Comment 8 Brian Wheeler 2012-09-24 13:23:56 UTC 
I was going to do that, but it kind of seemed like something that would have come up with other users -- and I wasn't sure if it would rate getting a boolean at some point, so I thought I'd report it.

I'll go and do it to keep my user happy.
Comment 9 Miroslav Grepl 2012-09-24 13:32:03 UTC 
Yes, we have

userdom_read_user_home_content_files(postfix_local_t)
userdom_exec_user_bin_files(postfix_local_t)

so it should be also available for NFS.
Comment 10 Brian Wheeler 2012-09-24 14:12:57 UTC 
(In reply to comment #9)
> Yes, we have
> 
> userdom_read_user_home_content_files(postfix_local_t)
> userdom_exec_user_bin_files(postfix_local_t)
> 
> so it should be also available for NFS.

I'm afraid you've lost me...
Comment 11 Daniel Walsh 2012-09-25 20:14:56 UTC 
Brian basically this is a bug, we should allow it.
Comment 12 Brian Wheeler 2012-09-25 21:23:41 UTC 
Ok, gotcha
Comment 13 Miroslav Grepl 2012-09-27 16:57:34 UTC 
Dan added it to Fedora. Will backport to RHEL6.4 soon.
Comment 18 errata-xmlrpc 2013-02-21 08:28:27 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-2013-0314.html
Note You need to log in before you can comment on or make changes to this bug.