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

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?

Couple of comments.

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


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


- 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?

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

I don't notice anything.

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.
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.


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.

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

Sorry not much sleep last night but here it is.
Nothing but sorry what is this checking?
What does flipping this boolean do? Any risks?

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


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


'man find', see "-context".


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".

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.

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.

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:object_r:usr_t".
If this is true, should we not use the following command instead? However it also reported nothing.
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?

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.

Ah, thanks. Much clearer now.


...apparently SELinux begs to differ ;-p


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.


Apart from the one char difference between an existing and a non-existing context, my mistake, you should be running 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 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.


It may be a temporary file. Come to think of it you could use Inotify to generate additional diagnostics: then try to re-create the conditions by sending and receiving email.

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?

I have again executed all three of the following and none returned anything.
Just want to be sure, it's the third one that we want, not the first or second one, right?

Sorry what is a CAPP like rule set?

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.

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.


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).


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



DAG, EPEL, RPMForge.


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.


No it isn't.

Sorry why isn't configuring from source the safest?

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.

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.


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.