Bug 215722 - SELinux postfix denials
SELinux postfix denials
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: postfix (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-15 08:13 EST by Mark Knoop
Modified: 2012-04-02 05:29 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-04 08:42:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
grep postfix /var/log/messages (9.47 KB, text/plain)
2006-11-15 08:13 EST, Mark Knoop
no flags Details
grep postfix /var/log/audit/audit.log (157.32 KB, text/plain)
2007-01-16 16:01 EST, Matěj Cepl
no flags Details
Record of IRC chat about this bug on #postfix (5.36 KB, text/plain)
2007-05-04 18:31 EDT, Matěj Cepl
no flags Details
output of zgrep postfix /var/log/audit/* | audit2allow -M mypostfix (749 bytes, text/plain)
2007-05-08 03:39 EDT, Matěj Cepl
no flags Details
Part of the audit.log (192.65 KB, text/plain)
2007-05-18 20:01 EDT, Matěj Cepl
no flags Details
/var/log/audit/audit.log (4.78 MB, text/plain)
2007-05-23 11:47 EDT, Matěj Cepl
no flags Details
even older audit logs from the same computer (612.65 KB, application/octet-stream)
2007-05-23 11:49 EDT, Matěj Cepl
no flags Details
current audit.log (127.19 KB, text/plain)
2007-05-29 18:07 EDT, Matěj Cepl
no flags Details
current audit.log (2.95 MB, text/plain)
2007-07-04 04:28 EDT, Matěj Cepl
no flags Details

  None (edit)
Description Mark Knoop 2006-11-15 08:13:06 EST
Description of problem:
I'm getting repeated SELinux denials reported which are cuased by various
postfix executables. Postfix seems to be running without problems, and some of
the denials are to devices that postfix should not have any reason to access. 

Version-Release number of selected component (if applicable):
postfix-2.3.3-2
selinux-policy-2.4.1-3.fc6

How reproducible:
Regularly.

Steps to Reproduce:
1. Install and use postfix
2. Check errors in setroubleshoot

Additional info:
See attached log - smtpd is trying to access /boot and sendmail.postfix is
trying to access /dev/hdk
Comment 1 Mark Knoop 2006-11-15 08:13:06 EST
Created attachment 141261 [details]
grep postfix /var/log/messages
Comment 2 Mark Knoop 2007-01-10 04:57:34 EST
Two things to add:

1. Something seems to be changing the context of /usr/libexec/postfix/lmtp - as
soon as I fix it, it's reverted back to the incorrect context. How would I go
about finding out what is doing this?

# date
Wed Jan 10 09:54:15 GMT 2007
# fixfiles -R postfix check
/sbin/restorecon reset /usr/libexec/postfix/lmtp context
system_u:object_r:postfix_smtp_exec_t:s0->system_u:object_r:postfix_exec_t:s0
# fixfiles -R postfix restore
# fixfiles -R postfix check
/sbin/restorecon reset /usr/libexec/postfix/lmtp context
system_u:object_r:postfix_smtp_exec_t:s0->system_u:object_r:postfix_exec_t:s0
# date
Wed Jan 10 09:54:26 GMT 2007

2. Bug 221347 seems to be a duplicate of this one.
Comment 3 Mark Knoop 2007-01-15 14:27:08 EST
The fixfiles weirdness in comment #2 is probably because lmtp is hardlinked to
smtp in /usr/libexec/postfix/. However
/etc/selinux/targeted/contexts/files/file_contexts defines different contexts
for them (lmtp is not explicitly defined).

/usr/libexec/postfix/.* --      system_u:object_r:postfix_exec_t:s0
/usr/libexec/postfix/smtp       --      system_u:object_r:postfix_smtp_exec_t:s0

This still doesn't explain why smtpd is trying to access /boot, /, and /home though.

I see that 221347 has been closed as the reporter was no longer experiencing the
bug. I am still seeing this with a regularly updated system.

Interestingly, this is not apparent when using evolution to send email, only
when using /bin/mail or sylpheed-claws (haven't tried other mailers).
Comment 4 Matěj Cepl 2007-01-16 06:09:35 EST
*** Bug 221347 has been marked as a duplicate of this bug. ***
Comment 5 Matěj Cepl 2007-01-16 06:37:06 EST
(In reply to comment #3)
> I see that 221347 has been closed as the reporter was no longer experiencing the
> bug. I am still seeing this with a regularly updated system.

my mistake -- it is still alive and kicking with FC6 (no problems with RHEL5b2
though); I just got confused by the bug not being reproducible 100% times.

> Interestingly, this is not apparent when using evolution to send email, only
> when using /bin/mail or sylpheed-claws (haven't tried other mailers).

For me Evolution (using /usr/sbin/sendmail) doesn't trigger this bug as well,
but Thunderbird (which cannot use sendmail directly) with SMTP to localhost does.
Comment 6 Matěj Cepl 2007-01-16 16:01:03 EST
Created attachment 145732 [details]
grep postfix /var/log/audit/audit.log

This may be even more interesting than previous attachment (hopefully).
Comment 7 Daniel Walsh 2007-01-17 11:04:36 EST
Ok we can dontaudit the getattr of /boot.
And I have fixed the file context of lmtp.

But what are the lnk_files tmp under the /var directory.  This seems to be a
local customization on your part and would require custom policy.  You can
generate custom policy to silance these, via
grep lnk_file /var/log/audit/audit.log | audit2allow -M mypostfix 

The other fixes will be in selinux-policy-2.4.6-28
Comment 8 Mark Knoop 2007-01-17 11:14:46 EST
(In reply to comment #7)
> Ok we can dontaudit the getattr of /boot.

Why does postfix need to look here at all, though?

I'm also seeing "getattr" to /home and "search" to / (see my attachment comment
#1). 

I'm no longer getting the "read"s to disk devices though.
Comment 9 Daniel Walsh 2007-01-17 11:35:24 EST
I think it is listing the contents of /  And therefore triggering getattr access
checks.  Lots of apps do this, although I do not know why.  I do not work on
postfix code, but until SELinux things like this were always ignored.
Comment 11 Matěj Cepl 2007-05-04 18:31:39 EDT
Created attachment 154182 [details]
Record of IRC chat about this bug on #postfix

Just to try to put some life into this bug, here is the record of IRC chat I
had about this bug on #postifx @ freenode. The guy blames postfix checking for
free space on all partitions -- that could be the reason why it goes to /home,
/boot, /tmp (assuming they are all partitions).

Reporter, are they?
Comment 12 Matěj Cepl 2007-05-08 03:39:10 EDT
Created attachment 154317 [details]
output of zgrep postfix /var/log/audit/* | audit2allow -M mypostfix

Does this make any sense?
Comment 13 Daniel Walsh 2007-05-14 15:31:50 EDT
This looks like there is a lnk_file in /var somewhere that postfix is not
allowed to read.  Do you have a special way of setting up your /var partition? 
Could you attach the avc messages that are generating this te file.
Comment 14 Matěj Cepl 2007-05-18 20:01:03 EDT
Created attachment 155038 [details]
Part of the audit.log

Per the last comment.
Comment 15 Daniel Walsh 2007-05-21 11:41:56 EDT
Looks like you have /var/tmp as a symlink?

Other stangeness you your logs?

s2disk is trying to mounton /proc directory?

setroubleshoot is requesting execmem execstack?????
Comment 16 Matěj Cepl 2007-05-23 11:43:45 EDT
I have no idea about setroubleshoot (well, I guess you should know more about it
than I do ;-)). s2disk is screwed up -- don't bother, that was just my attempt
to make it work and I gave up in meantime and switched to suspend2.

I was chatting about this with jkubin and pointed him towards my audit log on
http://www.ceplovi.cz/matej/tmp/audit.log.bz2 Does it make any more sense to you?

When I will be back at home with my notebook, I will check out that /var/tmp
link -- why shouldn't it be a symlink to /tmp?
Comment 17 Matěj Cepl 2007-05-23 11:47:48 EDT
Created attachment 155267 [details]
/var/log/audit/audit.log
Comment 18 Matěj Cepl 2007-05-23 11:49:19 EDT
Created attachment 155268 [details]
even older audit logs from the same computer
Comment 19 Matěj Cepl 2007-05-23 17:09:44 EDT
Actually, it was even worse -- /var/tmp was a symlink to /usr/local/tmp ;-)
needless to say, that I have restored (and restoreconed) /var/tmp

Concerning setroubleshootd -- yes, it doesn't work for me. This is an example
from today's /var/log/messages

May 23 22:56:02 chelcicky setroubleshoot: 2007-05-23 22:56:02,586 [rpc.ERROR] at
tempt to open server connection failed: (111, 'Spojen\xc3\xad odm\xc3\xadtnuto')
(that's "Connection rejected" in English).

Just now working on finding the proper setroubleshoot bug in BZ.
Comment 20 John Dennis 2007-05-29 17:40:51 EDT
re comment #19, is the setroubleshoot service running? First, check this:

% chkconfig --list setroubleshoot

Is it on? No?

then:

% chkconfig setroubleshoot on
% service setroubleshoot start

Comment 21 Matěj Cepl 2007-05-29 18:07:07 EDT
Created attachment 155647 [details]
current audit.log

Per request on fedora-selinux list
Comment 22 Matěj Cepl 2007-05-29 18:15:06 EDT
(In reply to comment #20)
> re comment #19, is the setroubleshoot service running? First, check this:

Of course, it is -- and after ten minutes of sealert trying to "Server Load" I
have killed it.
Comment 23 John Dennis 2007-05-30 11:03:21 EDT
re comment #21 attachment, this appears to be a binary file with the wrong
content-type. I did look at the file via your URL in the email. These errors
look most unusual. Is this an FC6 release as the bugzilla states? Have you
loaded any package versions from rawhide? Have you relabeled your entire system?
What is the content of /var/log/setroubleshoot/setroubleshootd.log? This issue
should be split off from this bugzilla into it's own if you are still having
problems. 
Comment 24 Matěj Cepl 2007-07-04 04:28:34 EDT
Created attachment 158504 [details]
current audit.log

Just to update for Fedora 7. I have uninstalled postfix, because it seems to be
not that much maintained in Red Hat (e.g., it seems to me that maintainer of
postfix hasn't bothered to see this bug yet). Dan, if you think there is
something interesting for you in my logs, I can install it for you to do any
testing you want, but otherwise, I think you somebody can close this bug.
Comment 25 Daniel Walsh 2007-07-06 11:46:46 EDT
The only additional one that I see which is not in FC7 SELinux policy is 

allow postfix_master_t sendmail_t:process signal;

Which I am adding to selinux-policy-2.6.4-27.fc7.src.rpm
Comment 26 Thomas Woerner 2007-10-04 07:16:16 EDT
Do you still have the problems with postfix?
Comment 27 Mark Knoop 2007-10-04 07:34:43 EDT
No, it's fine now (I think since selinux-policy-2.6.4-27.fc7).
Comment 28 Thomas Woerner 2007-10-04 08:42:53 EDT
O.k., I am closing this as "ERRATA", then.

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