Bug 853453 - SELinux vs .forward script on nfs
SELinux vs .forward script on nfs
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.3
All Linux
medium Severity high
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-31 11:12 EDT by Brian Wheeler
Modified: 2013-02-21 03:28 EST (History)
3 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-166.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 03:28:27 EST
Type: Bug
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 Brian Wheeler 2012-08-31 11:12:50 EDT
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 15:08:19 EDT
3 weeks and no response?
Comment 3 Jaroslav Škarvada 2012-09-24 05:34:53 EDT
(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 05:43:06 EDT
(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 07:19:01 EDT
Just to be sure could you attach AVC msgs?

# grep nfs_t /var/log/audit/audit.log
Comment 6 Brian Wheeler 2012-09-24 08:56:24 EDT
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 09:21:46 EDT
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 09:23:56 EDT
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 09:32:03 EDT
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 10:12:57 EDT
(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 16:14:56 EDT
Brian basically this is a bug, we should allow it.
Comment 12 Brian Wheeler 2012-09-25 17:23:41 EDT
Ok, gotcha
Comment 13 Miroslav Grepl 2012-09-27 12:57:34 EDT
Dan added it to Fedora. Will backport to RHEL6.4 soon.
Comment 18 errata-xmlrpc 2013-02-21 03:28:27 EST
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.