Bug 575639 - procmail cannot call/run user created script, SELinux denied execute
Summary: procmail cannot call/run user created script, SELinux denied execute
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-03-21 21:51 UTC by Paul DeStefano
Modified: 2010-06-08 19:27 UTC (History)
5 users (show)

Fixed In Version: selinux-policy-3.7.19-23.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-06-08 19:27:20 UTC

Attachments (Terms of Use)
differences implement home_bin_t (3.79 KB, patch)
2010-05-22 13:18 UTC, Dominick Grift
no flags Details | Diff
Source RPM with bin_home_t implemented (805.40 KB, application/x-rpm)
2010-05-22 13:20 UTC, Dominick Grift
no flags Details

Description Paul DeStefano 2010-03-21 21:51:56 UTC
Description of problem:

With SELinux enforcing, procmail is prevented from calling user script.

How reproducible:

Steps to Reproduce:
1. Set up procmail to call script

## scan with clmav
# use the clamassasin script to run the scan an rewrite headers
:0 fw:
| /home/<username>/local/bin/clamassassin

2. Wait until mail is received.
3. Check audit log.
Actual results:

node=wrangler type=AVC msg=audit(1269166268.384:11915): avc: denied { execute } for pid=2401 comm="procmail" name="clamassassin" dev=dm-2 ino=1454459 scontext=system_u:system_r:procmail_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file 

node=wrangler type=SYSCALL msg=audit(1269166268.384:11915): arch=c000003e syscall=59 success=no exit=-13 a0=1f9d370 a1=1f9f010 a2=1f9ee90 a3=8 items=0 ppid=2400 pid=2401 auid=4294967295 uid=13013 gid=13013 euid=13013 suid=13013 fsuid=13013 egid=13013 sgid=8 fsgid=13013 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null) 

Expected results:
Well, procmail should be able to call this script and run clamscan on mail before delivery.  How this is supposed to work with SELinux, I don't know.

Additional info:

There are two vectors for reaching procmail: sendmail for locally generated e-mail and fetchmail, which I run as a user daemon.  I cannot tell which AVCs are being generated from which vector.  I'm getting two other AVC messages about clamscan but I cannot tease them apart from the procmail ones.  So, I'm starting with this one.

Comment 1 Daniel Walsh 2010-03-31 19:06:14 UTC
Simplest thing woiuld be to change the context on clamassassin to bin_t

# semanage fcontext -a -t bin_t '/home/[^/*/local/bin/clamassassin'
# restorecon -R -v ~/local/bin/clamassassin

Currently procmail can write to the homedir, so I really do not want have it executing content there by default.  

I have not seen this type of AVC before as I recall.

Comment 2 Paul DeStefano 2010-04-13 03:39:30 UTC
Thanks!  Okay, I think I understand.  But, if I'm going to modify the SELinux profile, I might as well install the script globally.  Then marking it bin_t makes more sense, right?  More users would be able to use it this way, at least.

I understand the principle: it's not good to be able let programs create files that it can also run.  On the other hand, this SELinux policy limits an existing feature of procmail, namely, powerful user-defined delivery rules.

It seems like this policy is intended to protect MDA delivery.  It makes sense from a system administrator's perspective.  From that point of view, the potential for running unintended scripts is too great a risk.  But, when procmail runs as a user, the risk profile is much different, already.

Is there any way to have one set of SELinux rules for MDA delivery and another set of rules for when procmail runs as a user.  That way, promail could keep it's full capabilities when run as the user?  I don't know how that would be implemented, but that's what I thought would happen.

Procmail still must abided by discretionary access controls.  If SELinux only prevented procmail from modifying permissions, that would also prevent it making any executeable files, right?  That would be a value-add for the user without limiting any long-standing capabilities.

Hmm, that gives me an idea.  Could I call my script as bash <file>?

Am I just using procmail wrong?

Comment 3 Daniel Walsh 2010-04-13 16:48:09 UTC
The real goal is to prevent a hacked application from doing things that it is not designed to do.  Perhaps forwarding spam?  Running a screen scraping password catching tool?

We can through transition change the label of a program,  we could have apps executed by procmail run in a different context.  

There is also an effort to setup labels in the homedir, that would only allow procmail to deliver mail to a particular file or directory.

Comment 4 Fedora Admin XMLRPC Client 2010-04-15 15:58:39 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Bug Zapper 2010-04-28 11:59:01 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 6 Paul DeStefano 2010-05-02 18:31:23 UTC

Awesome!  Sounds like you are on the trail of a couple elegant solutions.  Thanks for the hard work.


Comment 7 Dominick Grift 2010-05-08 11:09:29 UTC
I Guess it may be best to create a new type and give the user access to relabelto and from the type, but not give the user access to execute it.

Then allow procmail to execute and and transition or execute_no_trans. (probably best to just do execute_no_trans)

I Guess such a type would have to be customizable.

We cannot go with bin_t because confined users cannot relabelto and from it nor can they write to it, and for good reason.

This concept may or may not apply for other services as well, maybe we can consider some general purpose type for this.

Basically some bin_home_t type that confined users cannot execute (by default atleast, depending on user_execute_content boolean setting) but that the can create and/or atleast relabelto/from and write/read/append.

Comment 8 Daniel Walsh 2010-05-17 20:58:51 UTC
Sounds good,  Dominick are you going to come up with a patch for this?

Comment 9 Dominick Grift 2010-05-22 13:18:47 UTC
Created attachment 415856 [details]
differences implement home_bin_t

Something like this. Except you might want to rename: 




Comment 10 Dominick Grift 2010-05-22 13:20:53 UTC
Created attachment 415857 [details]
Source RPM with bin_home_t implemented

Want to try it out?

rpmbuild --rebuild selinux-policy-3.7.19-20.3.fc13.src.rpm

Comment 11 Dominick Grift 2010-05-24 13:39:08 UTC
I guess you may also want to add:

HOME_DIR/local/bin(/.*)? gen_context(system_u:object_r:home_bin_t,s0)

to userdomain.fc

Comment 12 Dominick Grift 2010-05-24 22:01:00 UTC
Looks like (most) of these changes were adopted in v3.7.19-21, although i could not find procmail call to the userdom_exec_user_bin_files plus i also was unable to determine whether home_bin_t was made customizable type.

But if HOME_DIR/local/bin has restored context you can simply use audit2allow to allow the access to execute home_bin_t files that procmail (and any other system service) needs.

Please close this bz if this solution works.

Another thing i noticed was that ubac_constrained() was implicitly called for home_bin_t and home_cert_t: but this is redundant since userdom_user_home_content already includes this attribute.

Comment 13 Daniel Walsh 2010-05-25 14:52:15 UTC
Fixed in selinux-policy-3.7.19-22.fc13.noarch

Comment 14 Fedora Update System 2010-05-28 12:26:59 UTC
selinux-policy-3.7.19-22.fc13 has been submitted as an update for Fedora 13.

Comment 15 Fedora Update System 2010-05-31 18:18:57 UTC
selinux-policy-3.7.19-22.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/selinux-policy-3.7.19-22.fc13

Comment 16 Fedora Update System 2010-06-02 18:10:43 UTC
selinux-policy-3.7.19-23.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/selinux-policy-3.7.19-23.fc13

Comment 17 Fedora Update System 2010-06-08 19:25:32 UTC
selinux-policy-3.7.19-23.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

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