Bug 497679 - SElinux prevents sendmail from reading /var/run/milter-greylist/milter-greylist.sock
SElinux prevents sendmail from reading /var/run/milter-greylist/milter-greyli...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-26 01:33 EDT by Penelope Fudd
Modified: 2009-11-18 07:26 EST (History)
2 users (show)

See Also:
Fixed In Version: 3.5.13-59.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 07:26:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Audit records from sendmail being denied (782 bytes, text/plain)
2009-04-26 13:40 EDT, Penelope Fudd
no flags Details
SELinux policy module for milter greylist (836 bytes, application/octet-stream)
2009-04-30 10:32 EDT, Paul Howarth
no flags Details

  None (edit)
Description Penelope Fudd 2009-04-26 01:33:47 EDT
Description of problem:
Sendmail can't access /var/run/milter-greylist/milter-greylist.sock

Version-Release number of selected component (if applicable):
milter-greylist-4.1.1-2.fc10.i386

How reproducible:
Always

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
  
Actual results:
Sendmail refuses to start, due to selinux denial of milter-greylist.sock

Expected results:
It should work.

Additional info:
# 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
Comment 1 Enrico Scholz 2009-04-26 06:50:38 EDT
can you attach the AVC, please?
Comment 2 Penelope Fudd 2009-04-26 13:40:49 EDT
Created attachment 341365 [details]
Audit records from sendmail being denied
Comment 3 Enrico Scholz 2009-04-26 18:13:36 EDT
reassigning to selinux-policy; btw, the 'tcontext=system_u:system_r:clamd_t:s0' looks strange as clamav is completely unrelated to 'milter-greylist'
Comment 4 Daniel Walsh 2009-04-27 10:01:46 EDT
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.*
Comment 5 Paul Howarth 2009-04-28 16:01:58 EDT
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
Comment 6 Penelope Fudd 2009-04-28 16:06:12 EDT
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
Comment 7 Penelope Fudd 2009-04-28 16:11:47 EDT
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!
Comment 8 Daniel Walsh 2009-04-28 16:17:25 EDT
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.
Comment 9 Paul Howarth 2009-04-28 16:24:35 EDT
(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.
Comment 10 Penelope Fudd 2009-04-28 16:34:04 EDT
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.
Comment 11 Penelope Fudd 2009-04-28 16:48:51 EDT
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.
Comment 12 Paul Howarth 2009-04-29 04:08:29 EDT
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.
Comment 13 Paul Howarth 2009-04-30 10:32:38 EDT
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.
Comment 14 Daniel Walsh 2009-04-30 17:50:41 EDT
For now I am just going to add these to milter.te,fc

Fixed in selinux-policy-3.6.12-26.fc11.noarch
Comment 15 Daniel Walsh 2009-04-30 17:51:53 EDT
Woops should  not have closed this since it is F10
Comment 16 Miroslav Grepl 2009-05-07 08:54:14 EDT
Fixed in selinux-policy-3.5.13-59.fc10
Comment 17 Paul Howarth 2009-05-07 09:51:50 EDT
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.
Comment 18 Penelope Fudd 2009-05-17 02:36:55 EDT
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.
Comment 19 Paul Howarth 2009-05-17 02:56:17 EDT
(In reply to comment #18)
> Where do I find selinux-policy-3.5.13-59.fc10 ?

# yum --enablerepo=updates-testing update selinux-policy-targeted
Comment 20 Paul Howarth 2009-05-20 05:46:26 EDT
The updated policy has now been pushed to the stable updates repository, so a simple "yum update" should work.
Comment 21 Paul Howarth 2009-05-27 11:30:52 EDT
Penelope, does the milter work for you now without your local policy module?
Comment 22 Paul Howarth 2009-08-20 05:18:38 EDT
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.
Comment 23 Penelope Fudd 2009-08-20 12:01:41 EDT
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
Comment 24 Bug Zapper 2009-11-18 06:51:26 EST
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
Comment 25 Paul Howarth 2009-11-18 07:26:14 EST
I believe this to be fixed.

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