SELinux is preventing postdrop (postfix_postdrop_t) "append" ... (usr_t)

grob115 · 01-02-2014, 07:12 AM

Hi, all of a sudden I'm seeing my Postfix not running. Trying to start it up failed. When I looked into /var/log/messages I saw some issue with SELinux.

However, when executing sealert I'm unable to intrepret meaning of the output. Can someone please give some light on this?

Code:

sealert -l 80211036-8d3d-4afc-8948-0667eb7130af

Summary:

SELinux is preventing postdrop (postfix_postdrop_t) "append" to
2F7573722F6C6F63616C2F617061636865322F6C6F67732F6572726F725F6C6F67202864656C6574656429
(usr_t).

Detailed Description:

SELinux denied access requested by postdrop. It is not expected that this access
is required by postdrop and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for
2F7573722F6C6F63616C2F617061636865322F6C6F67732F6572726F725F6C6F67202864656C6574656429,

restorecon -v
'2F7573722F6C6F63616C2F617061636865322F6C6F67732F6572726F725F6C6F67202864656C6574656429'

If this does not work, there is currently no automatic way to allow this access.
Instead, you can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context                user_u:system_r:postfix_postdrop_t
Target Context                root:object_r:usr_t
Target Objects                2F7573722F6C6F63616C2F617061636865322F6C6F67732F65
                              72726F725F6C6F67202864656C6574656429 [ file ]
Source                        postdrop
Source Path                   /usr/sbin/postdrop
Port                          <Unknown>
Host                          www.mydomain.com
Source RPM Packages           postfix-2.3.3-2.3.el5_6
Target RPM Packages
Policy RPM                    selinux-policy-2.4.6-279.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall_file
Host Name                     www.mydomain.com
Platform                      Linux www.mydomain.com 2.6.18-194.el5 #1 SMP Fri
                              Apr 2 14:58:14 EDT 2010 x86_64 x86_64
Alert Count                   30482
First Seen                    Sun Nov 24 07:05:36 2013
Last Seen                     Thu Jan  2 04:42:54 2014
Local ID                      80211036-8d3d-4afc-8948-0667eb7130af
Line Numbers

Raw Audit Messages

host=www.mydomain.com type=AVC msg=audit(1388666574.58:2677651): avc:  denied  { append } for  pid=2371 comm="postdrop" path=2F7573722F6C6F63616C2F617061636865322F6C6F67732F6572726F725F6C6F67202864656C6574656429 dev=dm-0 ino=8429137 scontext=user_u:system_r:postfix_postdrop_t:s0 tcontext=root:object_r:usr_t:s0 tclass=file

host=www.mydomain.com type=SYSCALL msg=audit(1388666574.58:2677651): arch=c000003e syscall=59 success=yes exit=0 a0=2b92fc13f130 a1=2b92fc13f160 a2=2b92fc139ee0 a3=0 items=0 ppid=2370 pid=2371 auid=0 uid=2 gid=2 euid=2 suid=2 fsuid=2 egid=90 sgid=90 fsgid=90 tty=(none) ses=17511 comm="postdrop" exe="/usr/sbin/postdrop" subj=user_u:system_r:postfix_postdrop_t:s0 key=(null)

unSpawn · 01-02-2014, 08:24 AM

Couple of comments.

Quote:

Originally Posted by grob115

Code:

Source RPM Packages           postfix-2.3.3-2.3.el5_6
Target RPM Packages
Policy RPM                    selinux-policy-2.4.6-279.el5
Platform                      Linux www.mydomain.com 2.6.18-194.el5 #1 SMP Fri
                              Apr 2 14:58:14 EDT 2010 x86_64 x86_64

- RHEL 5 has been at U10 for some time now.

Quote:

Originally Posted by grob115

Code:

First Seen                    Sun Nov 24 07:05:36 2013
Last Seen                     Thu Jan  2 04:42:54 2014
Local ID                      80211036-8d3d-4afc-8948-0667eb7130af

- IIRC this issue seems to have been seen since end of November last year. Trace events on or around that date.

Quote:

Originally Posted by grob115

Code:

host=www.mydomain.com type=AVC msg=audit(1388666574.58:2677651): avc:  denied  { append } for  pid=2371 comm="postdrop" path=2F7573722F6C6F63616C2F617061636865322F6C6F67732F6572726F725F6C6F67202864656C6574656429 dev=dm-0 ino=8429137 scontext=user_u:system_r:postfix_postdrop_t:s0 tcontext=root:object_r:usr_t:s0 tclass=file

host=www.mydomain.com type=SYSCALL msg=audit(1388666574.58:2677651): arch=c000003e syscall=59 success=yes exit=0 a0=2b92fc13f130 a1=2b92fc13f160 a2=2b92fc139ee0 a3=0 items=0 ppid=2370 pid=2371 auid=0 uid=2 gid=2 euid=2 suid=2 fsuid=2 egid=90 sgid=90 fsgid=90 tty=(none) ses=17511 comm="postdrop" exe="/usr/sbin/postdrop" subj=user_u:system_r:postfix_postdrop_t:s0 key=(null)

- Does inode 8429137 exist and if so what is it?
- The target context is usr_t which isn't common for anything that lives in /var. See 'semanage fcontext -l|grep 'spool/post';'.

- What does maillog have to say?
- Are there any (seemingly unrelated) messages in other logs between the time Postfix died and you tried to restart it?
- Have you changed any Postfix configuration or anything else that could have affected Postfix?
- What does 'getsebool -a|grep postfix' (or 'getsebool -a|grep post') return?
- Just to make certain: what does 'rpm -Vv|grep -v '\.\{8\}';' return?

grob115 · 01-02-2014, 08:50 AM

Hi, thanks for the reply. Here are some of the information. Hope it helps to give a better picture.

Quote:

Does inode 8429137 exist and if so what is it?

Code:

[root@www ~]# cd /
[root@www /]# find . -inum 8429137
find: ./proc/3610/task/3610/fd/4: No such file or directory
find: ./proc/3610/fd/4: No such file or directory
[root@www /]#
[root@www /]# ls -ltr /proc/3610/task/3610/fd/
ls: /proc/3610/task/3610/fd/: No such file or directory
[root@www /]#
[root@www /]# ls -ltr /proc/3610/fd
ls: /proc/3610/fd: No such file or directory
[root@www /]#

Quote:

The target context is usr_t which isn't common for anything that lives in /var. See 'semanage fcontext -l|grep 'spool/post';'.

Code:

[root@www /]# semanage fcontext -l|grep 'spool/post'
/var/spool/postfix(/.*)?                           all files          system_u:object_r:postfix_spool_t:s0
/var/spool/postfix/usr(/.*)?                       all files          system_u:object_r:lib_t:s0
/var/spool/postfix/etc(/.*)?                       all files          system_u:object_r:etc_t:s0
/var/spool/postfix/lib(64)?(/.*)?                  all files          system_u:object_r:lib_t:s0
/var/spool/postfix/lib(64)?/ld.*\.so.*             regular file       system_u:object_r:ld_so_t:s0
/var/spool/postfix/lib(64)?/lib.*\.so.*            regular file       system_u:object_r:shlib_t:s0
/var/spool/postfix/lib(64)?/devfsd/.+\.so.*        regular file       system_u:object_r:shlib_t:s0
/var/spool/postfix/lib(64)?/[^/]*/lib.*\.so.*      regular file       system_u:object_r:shlib_t:s0
/var/spool/postfix/pid/.*                          all files          system_u:object_r:postfix_var_run_t:s0
/var/spool/postfix/flush(/.*)?                     all files          system_u:object_r:postfix_spool_flush_t:s0
/var/spool/postfix/public(/.*)?                    all files          system_u:object_r:postfix_public_t:s0
/var/spool/postfix/bounce(/.*)?                    all files          system_u:object_r:postfix_spool_bounce_t:s0
/var/spool/postfix/private(/.*)?                   all files          system_u:object_r:postfix_private_t:s0
/var/spool/postfix/maildrop(/.*)?                  all files          system_u:object_r:postfix_spool_maildrop_t:s0
/var/spool/postfix/postgrey(/.*)?                  all files          system_u:object_r:postgrey_spool_t:s0
/var/spool/postfix/pid                             directory          system_u:object_r:var_run_t:s0
/var/spool/postfix/etc/localtime                   regular file       system_u:object_r:locale_t:s0

Quote:

What does maillog have to say?

I don't notice anything.

Quote:

Are there any (seemingly unrelated) messages in other logs between the time Postfix died and you tried to restart it?

The only thing I noticed is the following type of message logged in my /var/log/message file. In fact almost all lines are showing this.

Code:

Jan  2 06:43:43 www setroubleshoot: SELinux is preventing postdrop (postfix_postdrop_t) "append" to 2F7573722F6C6F63616C2F617061636865322F6C6F67732F6572726F725F6C6F67202864656C6574656429 (usr_t). For complete SELinux messages. run sealert -l 80211036-8d3d-4afc-8948-0667eb7130af

Quote:

Have you changed any Postfix configuration or anything else that could have affected Postfix?

No I haven't made anything changes.

Quote:

What does 'getsebool -a|grep postfix' (or 'getsebool -a|grep post') return?

Code:

[root@www /]# getsebool -a|grep postfix
allow_postfix_local_write_mail_spool --> off
postfix_disable_trans --> off
[root@www /]# getsebool -a|grep post
allow_postfix_local_write_mail_spool --> off
postfix_disable_trans --> off
postgresql_disable_trans --> off
postgrey_disable_trans --> off

Quote:

Just to make certain: what does 'rpm -Vv|grep -v '\.\{8\}';' return?

Code:

[root@www /]# rpm -Vv|grep -v '\.\{8\}'
rpmv: no arguments given for verify

unSpawn · 01-02-2014, 09:59 AM

Quote:

Originally Posted by grob115

No I haven't made anything changes.

Since this issue seems to have been seen since end of November last year did you trace events on or around that date?
*And BTW, RHEL 5 has been at U10 for some time now. Keeping up with updates is one of the sysadm best practices.

Quote:

Originally Posted by grob115

Code:

[root@www /]# rpm -Vv|grep -v '\.\{8\}'
rpmv: no arguments given for verify

Couldn't you have given it a package name like "postfix"?..

Asserting postdrop delivers to a location in /var (do confirm) what does 'find /var/ -context "*:user_t:*" -printf "%p %Z\n";' return?
If nothing, though I'm kind of loathe to suggest it w/o further T/S, then you could try flipping the "allow_postfix_local_write_mail_spool" boolean and see if that works.

grob115 · 01-02-2014, 10:19 AM

Quote:

*And BTW, RHEL 5 has been at U10 for some time now

Yes thanks. Exactly why I'm building and testing latest packages now. It's because of this I run into this.

Quote:

Couldn't you have given it a package name like "postfix"?..

Sorry not much sleep last night but here it is.

Code:

[root@www ~]# rpm -V postfix-2.3.3-2.3.el5_6
S.5....T  c /etc/postfix/main.cf
S.5....T  c /etc/postfix/master.cf

Quote:

Asserting postdrop delivers to a location in /var (do confirm) what does 'find /var/ -context "*:user_t:*" -printf "%p %Z\n";' return?

Nothing but sorry what is this checking?

Code:

[root@www ~]# find /var/ -context "*:user_t:*" -printf "%p %Z\n"
[root@www ~]#

Quote:

you could try flipping the "allow_postfix_local_write_mail_spool" boolean and see if that works.

What does flipping this boolean do? Any risks?

unSpawn · 01-02-2014, 01:12 PM

Quote:

Originally Posted by grob115

Exactly why I'm building and testing latest packages now. It's because of this I run into this.

I do not understand what that is supposed to convey. Explain?

Quote:

Originally Posted by grob115

Code:

[root@www ~]# rpm -V postfix-2.3.3-2.3.el5_6
S.5....T  c /etc/postfix/main.cf
S.5....T  c /etc/postfix/master.cf

So these files did change. If it's just host names and such, OK, but what else?..

Quote:

Originally Posted by grob115

Nothing but sorry what is this checking?

'man find', see "-context".

Quote:

Originally Posted by grob115

What does flipping this boolean do? Any risks?

Packages include man pages like "postfix_postdrop".
SELinux adds a few related ones and suffixes them with "_selinux" like "postfix_postdrop_selinux".
The boolean is described in "postfix_local_selinux".

grob115 · 01-02-2014, 11:49 PM

Quote:

I do not understand what that is supposed to convey. Explain?

Sorry for being so vague. Just reviewed what I typed and am surprised also how vague I was. What I meant was I'm in the process of planning upgrade for both my hardware and software. I'll basically procure new boxes and re-install everything with the latest compatible versions. To facilitate this, I'm in the process of building and installing these late packages in the latest CentOS 6, referencing what I had setup 3 years ago. So that's why I discovered some strange stuff with the current setup.

Quote:

So these files did change. If it's just host names and such, OK, but what else?..

These files were changed as part of any Postfix installation. There are a hosts of other variables to set such as permitted networks, cross checking with external sites such as the various RBLs, throttling logins from specific IPs to discourage hacks, etc. But I haven't changed anything on this box from which I saw these SELinux. I might had changed something back in 24 Nov 2013 but I really can't recall and really don't think I did.

Quote:

'man find', see "-context".

I am familiar with find and know what contexts are in basic terms but never realized that find can find files with specific context. Thanks. Looking at this again, I see SELinux is reporting that the source is attempting to access a target with the context of "root

bject_r:usr_t".

Code:

Target Context                root:object_r:usr_t

If this is true, should we not use the following command instead? However it also reported nothing.

Code:

find /var/ -context "*:*:user_t" -printf "%p %Z\n"

My knowledge of SELinux is limited. I read about it 3 years ago when I setup the whole rig but have since then forgotten every bit of it. I haven't had the chance to get to refresh myself on them yet. What I don't understand is if SELinux has detected something attempted to access a target with a specific context, why can't we find these targets now?

Quote:

Packages include man pages like "postfix_postdrop".
SELinux adds a few related ones and suffixes them with "_selinux" like "postfix_postdrop_selinux".
The boolean is described in "postfix_local_selinux".

Um... the only I found is the man page for Postfix within which the only reference to either selinux or postdrop is the following. Don't think it's what we're after however. Wonder if it's because the man page you refer to isn't available in my older version of Postfix.

Quote:

setgid_group (postdrop)
The group ownership of set-gid Postfix commands and of group-writable Postfix directories.

unSpawn · 01-03-2014, 07:26 AM

Quote:

Originally Posted by grob115

Sorry for being so vague. Just reviewed what I typed and am surprised also how vague I was. What I meant was I'm in the process of planning upgrade for both my hardware and software. I'll basically procure new boxes and re-install everything with the latest compatible versions. To facilitate this, I'm in the process of building and installing these late packages in the latest CentOS 6, referencing what I had setup 3 years ago. So that's why I discovered some strange stuff with the current setup.

Ah, thanks. Much clearer now.

Quote:

Originally Posted by grob115

But I haven't changed anything on this box from which I saw these SELinux.

...apparently SELinux begs to differ ;-p

Quote:

Originally Posted by grob115

I might had changed something back in 24 Nov 2013 but I really can't recall and really don't think I did.

Why don't you keep all configuration under revision control (basic 'rcs' will do just fine)? That'll allow you to know when changes were made, who they were made by and why. Plus revision control also allows you to roll back when required. Also jot down any changes with a risk attached in a machine-centric admin log and you'll facilitate easy sharing of knowledge between admins plus you've got an audit trail.

Quote:

Originally Posted by grob115

I am familiar with find and know what contexts are in basic terms but never realized that find can find files with specific context. Thanks. Looking at this again, I see SELinux is reporting that the source is attempting to access a target with the context of "root

bject_r:usr_t".

Code:

Target Context                root:object_r:usr_t

If this is true, should we not use the following command instead? However it also reported nothing.

Code:

find /var/ -context "*:*:user_t" -printf "%p %Z\n"

Apart from the one char difference between an existing and a non-existing context, my mistake, you should be running

Code:

find /var/ -context "*:usr_t:*" -printf "%p %Z\n"

I'm trying to see what entities have the "usr_t" context. With the Targeted Policy the Object Role doesn't change and I don't care for ownership right here.

Quote:

Originally Posted by grob115

My knowledge of SELinux is limited. I read about it 3 years ago when I setup the whole rig but have since then forgotten every bit of it.

I encountered SELinux way back when Fedora was still at Fedora Core 2. At the time SELinux was "not production ready" but it has improved dramatically over the years to the point where I consider any on-line documentation, tutorial or so-called "advice" that suggests to first to turn off SELinux while troubleshooting as completely useless. I run a mostly CAPP-like rule set, can read audit.log lines and use the SELinux-provided tools to create local policy customizations though I rarely hand-craft policies.

Quote:

Originally Posted by grob115

What I don't understand is if SELinux has detected something attempted to access a target with a specific context, why can't we find these targets now?

It may be a temporary file. Come to think of it you could use Inotify to generate additional diagnostics:

Code:

inotifywait -m -e create -e open -e access -e modify -e close_nowrite -e close_write -r /var

then try to re-create the conditions by sending and receiving email.

grob115 · 01-03-2014, 12:24 PM

Quote:

Why don't you keep all configuration under revision control (basic 'rcs' will do just fine)?

Good point. Never thought of that. Thanks. I'm familiar with SVN but not RCS. Is that something different or basically just a source control? You mentioned I can tell what changes were made by who. Is this done automatically or relying on someone checking in the changes?

Quote:

Apart from the one char difference between an existing and a non-existing context, my mistake, you should be running

Code:

find /var/ -context "*:usr_t:*" -printf "%p %Z\n"

I'm trying to see what entities have the "usr_t" context. With the Targeted Policy the Object Role doesn't change and I don't care for ownership right here.

I have again executed all three of the following and none returned anything.

Code:

find /var/ -context "*:user_t:*" -printf "%p %Z\n"
find /var/ -context "*:usr_t:*" -printf "%p %Z\n"
find /var/ -context "*:*:usr_t" -printf "%p %Z\n"

Just want to be sure, it's the third one that we want, not the first or second one, right?

Quote:

I run a mostly CAPP-like rule set

Sorry what is a CAPP like rule set?

Quote:

It may be a temporary file. Come to think of it you could use Inotify to generate additional diagnostics

The inotify tool set isn't available from the standard repos. Which one do you use? Dag or EPEL or somewhere? Generally how much can we trust the repos (standard or not)? Not sure what mechanism is in place to gate keep people from uploading malicious packaged code to them. Safest is always to run the ./configure from source but I don't have time to do this for all software.

unSpawn · 01-03-2014, 03:30 PM

Quote:

Originally Posted by grob115

Is that something different or basically just a source control?

Just that. Compared to CVS, SVN, GIT and whatever else RCS is decidedly ancient but it works for me. Choose whatever you're comfortable with.

Quote:

Originally Posted by grob115

You mentioned I can tell what changes were made by who. Is this done automatically or relying on someone checking in the changes?

Unless you explicitly set the author tag it'll be equal to $LOGNAME. Since it is trivial to lie about the author tag it makes sense to have additional measures in place and expand the audit trail beyond what unprivileged users can change (rootsh, audit.rules).

Quote:

Originally Posted by grob115

I have again executed all three of the following and none returned anything.

Code:

find /var/ -context "*:user_t:*" -printf "%p %Z\n"
find /var/ -context "*:usr_t:*" -printf "%p %Z\n"
find /var/ -context "*:*:usr_t" -printf "%p %Z\n"

Just want to be sure, it's the third one that we want, not the first or second one, right?

Second one ;-p Since it doesn't return anything that's a dead end.

Quote:

Originally Posted by grob115

Sorry what is a CAPP like rule set?

Code:

locate capp lspp nispom

Quote:

Originally Posted by grob115

The inotify tool set isn't available from the standard repos. Which one do you use? Dag or EPEL or somewhere?

DAG, EPEL, RPMForge.

Quote:

Originally Posted by grob115

Generally how much can we trust the repos (standard or not)? Not sure what mechanism is in place to gate keep people from uploading malicious packaged code to them.

I'm certain there's established rules for master keys, package submission, build processes and signing. Then there's (AFAIK) a limited amount of package builders and they perform reasonably good Quality Assurance. So I trust them as long as the repo GnuPG sig and stored hashes match.

Quote:

Originally Posted by grob115

Safest is always to run the ./configure from source

No it isn't.

grob115 · 01-04-2014, 11:30 AM

Sorry why isn't configuring from source the safest?

unSpawn · 01-07-2014, 03:34 PM

Basically you'll take responsibility for doing everything Red Hat already does for you: source taint checks, testing, quality assurance. Each and every time.

grob115 · 01-08-2014, 09:35 AM

Quote:

Originally Posted by unSpawn

Basically you'll take responsibility for doing everything Red Hat already does for you: source taint checks, testing, quality assurance. Each and every time.

Okay I didn't know the repositories that shipped with CentOS or RHEL contains only packages contributed by Red Hat. Even then with regards to source taint, isn't it safe as long as I do the check against the signature posted on the site assuming the site hasn't been defaced?

The problem I have with *NIX is every package is installed at different location. If I want to have everything installed under the same directory, I can run configure with --prefix to install it at a specific directory.

unSpawn · 01-12-2014, 07:28 AM

Quote:

Originally Posted by grob115

Even then with regards to source taint, isn't it safe as long as I do the check against the signature posted on the site assuming the site hasn't been defaced?

Sure, but how about quality assurance? And then there's the fact that you won't automagically update software the RPMDB doesn't check or warn for.

Quote:

Originally Posted by grob115

The problem I have with *NIX is every package is installed at different location. If I want to have everything installed under the same directory, I can run configure with --prefix to install it at a specific directory.

RHEL / CentOS like most Linux distributions install all packages in locations adhering to the FSSTND, LSB, FHS or whatever is the standard these days. And source packages usually have a sane --prefix="/usr/local" set. So while you might want to do something nice with "everything installed under the same directory" if it doesn't conform to those the previous two "rules" it isn't compliant anyway, meaning hassle, extra maintenance, risks and whatnot. Not is it suboptimal but having to discuss this is also a distraction from what this thread was or should have been about.