Bug 575639
| Summary: | procmail cannot call/run user created script, SELinux denied execute | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Paul DeStefano <prd-fedora> | ||||||
| Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 13 | CC: | domg444, dwalsh, mgrepl, mlichvar, ovasik | ||||||
| Target Milestone: | --- | Keywords: | SELinux | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | selinux-policy-3.7.19-23.fc13 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2010-06-08 19:27:20 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: |
|
||||||||
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. 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? 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. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Daniel, Awesome! Sounds like you are on the trail of a couple elegant solutions. Thanks for the hard work. Thanks, Paul 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. Sounds good, Dominick are you going to come up with a patch for this? Created attachment 415856 [details]
differences implement home_bin_t
Something like this. Except you might want to rename:
userdom_exec_user_bin_files()
to
userdom_exec_home_bin_files()
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
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 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. Fixed in selinux-policy-3.7.19-22.fc13.noarch selinux-policy-3.7.19-22.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/selinux-policy-3.7.19-22.fc13 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 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 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. |
Description of problem: With SELinux enforcing, procmail is prevented from calling user script. How reproducible: Very. 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.