Bug 497679
Summary: | SElinux prevents sendmail from reading /var/run/milter-greylist/milter-greylist.sock | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Penelope Fudd <bugzilla.redhat.com> | ||||||
Component: | selinux-policy-targeted | Assignee: | Miroslav Grepl <mgrepl> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Ben Levenson <benl> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 10 | CC: | paul, rh-bugzilla | ||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 3.5.13-59.fc10 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2009-11-18 12:26:14 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: |
|
Description
Penelope Fudd
2009-04-26 05:33:47 UTC
can you attach the AVC, please? Created attachment 341365 [details]
Audit records from sendmail being denied
reassigning to selinux-policy; btw, the 'tcontext=system_u:system_r:clamd_t:s0' looks strange as clamav is completely unrelated to 'milter-greylist' I think this is a leaked file descriptor from clamd. Paul how should we label the /var/run/milter-greylist directory? Should we just have a label for all milters? /var/run/milter.* Looks like another manifestation of Bug #485426. The default context for /var/run/milter-greylist should be fine as it runs unconfined (I don't see any policy for it) at the moment. Penelope, does the milter run OK in permissive mode? (setenforce 0; restart the service - does it work? setenforce 1 to turn enforcing mode back on) Can you post the output of: # ls -lZd / /var /var/run /var/run/milter-greylist Hi.. It works under permissive mode, and audit2allow created a local policy file that works for me. Here is the ls -lZd output: drwxr-xr-x root root system_u:object_r:root_t:s0 / drwxr-xr-x root root system_u:object_r:var_t:s0 /var drwxr-xr-x root root system_u:object_r:var_run_t:s0 /var/run drwxr-xr-x grmilter root system_u:object_r:var_run_t:s0 /var/run/milter-greylist Is there something that can list and decompile local policy files? I used to call all my policy files 'local', but then I'd end up overwriting previous policies. Now I create policy files with the date in the name, so at least I don't undo previous work, but if I need to add something, I won't remember the previous name or what was in it. Thanks! Paul, Well this is not a leak since sendmail actually needs access to the socket. So I think we need a context for /var/run/milter* that sendmail can communicate with sock_files in these directories. Perhaps allowing it to connecto initrc_t since we do not know where these milters are coming from and they probably will not have context? Penelope, Nothing right now. although there have been examples running around. I find it best to just create a directory for the new policy and leave the fc, te files in it. Please send me any things that you believe should be added to the base policy package. (In reply to comment #6) > Hi.. > > It works under permissive mode, and audit2allow created a local policy file > that works for me. Here is the ls -lZd output: > > drwxr-xr-x root root system_u:object_r:root_t:s0 / > drwxr-xr-x root root system_u:object_r:var_t:s0 /var > drwxr-xr-x root root system_u:object_r:var_run_t:s0 /var/run > drwxr-xr-x grmilter root system_u:object_r:var_run_t:s0 > /var/run/milter-greylist OK so it's definitely an SELinux issue rather than the DAC permissions. I think the clamd_t one may be a leaked file descriptor and the sendmail_t one is the problem. Can you try removing your local policy module and trying this instead as an experiment: # chcon -R -t spamass_milter_data_t /var/run/milter-greylist If it doesn't work, a "restorecon -R /var/run/milter-greylist" should get things back where they were. (In reply to comment #7) > Is there something that can list and decompile local policy files? I used to > call all my policy files 'local', but then I'd end up overwriting previous > policies. Now I create policy files with the date in the name, so at least I > don't undo previous work, but if I need to add something, I won't remember the > previous name or what was in it. I tend to put local rules in a "localmisc" module but I never use audit2allow to overwrite it. Instead, I just paste any new rules into the file in addition to any existing ones, and merge together any "requires" sections into a single one at the start. I also try to comment each rule to say why it was was added, and periodically clean up (remove) rules that have been added to the main selinux-policy package as a result of bug reports. (In reply to comment #4) > Paul how should we label the /var/run/milter-greylist directory? > > Should we just have a label for all milters? > /var/run/milter.* Perhaps a generic unconfined milter domain to run any milter in that doesn't have specific policy, and allow sendmail access to that domain's socket files? Otherwise it'd need letting sendmail have access to var_run_t sockets, which is probably much more than it needs. How do you remove it? And I think I called it milter-greylist-2009-04-24, but the date could be different or it could be greylist-milter or greylist. I didn't save the .te file; can I get a list of what I can remove? Thanks. Ok, I found it in /etc/selinux/targeted/modules/active/modules/miltergreylist20090425.pp , do I just delete it and reboot, or is there something else that needs to be done? Thanks. To see what modules are active: # semodule -l To remove your module: # semodule -r miltergreylist20090425 If you no longer have the .te file you'll need to regenerate it using audit2allow if you want to load the module back again. Created attachment 341934 [details]
SELinux policy module for milter greylist
I've installed milter-greylist on my machine and written this policy for it. It's now working for me with no denials.
If you want to try this policy, stop the milter-greylist service, install the module, then fix the file contexts:
# restorecon -rv $(rpm -ql milter-greylist)
Then restart the service.
This policy should be easy to merge into the existing milter policy module.
For now I am just going to add these to milter.te,fc Fixed in selinux-policy-3.6.12-26.fc11.noarch Woops should not have closed this since it is F10 Fixed in selinux-policy-3.5.13-59.fc10 Penelope, please let me know if the updated selinux-policy package fixes the issue for you (it seems fine for me). If it's OK, I'll then try to get the fix into the upstream reference policy too. Where do I find selinux-policy-3.5.13-59.fc10 ? Additionally, as greylist-milter seems to die randomly, I attempted to put a greylist-milter respawn script into /etc/event.d, but it seems to have selinux issues there. There is a greylist-milter-upstart rpm in Fedora 11, but I bet it won't work in Fedora 10 due to selinux not being set up for it. I miss the days when you could make a change and it would just *work*. Selinux doesn't appear to have improved things, only complicated things. (In reply to comment #18) > Where do I find selinux-policy-3.5.13-59.fc10 ? # yum --enablerepo=updates-testing update selinux-policy-targeted The updated policy has now been pushed to the stable updates repository, so a simple "yum update" should work. Penelope, does the milter work for you now without your local policy module? It's been 3 months now since the last comment from the reporter (Penelope). I believe the problem is fixed and the bug can be closed. Hi.. Sorry for the delay. SElinux has become a 'single point of failure', causing problems on all of the machines I administer. It's a great concept (I tried out the anonymous-root shell server protected by SElinux), but if it's continually breaking on new packages, it's more trouble than it's worth. I bet RHEL is reaping the rewards for Fedora's pain, though. setenforce 0 Thanks This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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 I believe this to be fixed. |