Red Hat Bugzilla – Bug 497679
SElinux prevents sendmail from reading /var/run/milter-greylist/milter-greylist.sock
Last modified: 2009-11-18 07:26:14 EST
Description of problem:
Sendmail can't access /var/run/milter-greylist/milter-greylist.sock
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. yum -y install milter-greylist
2. Add rules to /etc/mail/sendmail.mc
3. service start milter-greylist ; service restart sendmail
Sendmail refuses to start, due to selinux denial of milter-greylist.sock
It should work.
# service sendmail start
Starting sendmail: 451 4.0.0 /etc/mail/sendmail.cf: line 1817: Xgreylist: local socket name /var/run/milter-greylist/milter-greylist.sock unsafe: Permission denied
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?
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
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.
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?
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)
> 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
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?
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?
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?
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.
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.
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:
I believe this to be fixed.