Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
@tonj: /var/run is where daemon processes may commonly keep PID files, fifo's, sockets or lock files. Since Postfix has been in Fedora for a while it should have a well-developed policy by now. The "preventing /usr/libexec/postfix/master (postfix_master_t) "read write" to <Unknown> (var_run_t)" Sealert looks like a warning for a missing rule. How that happened I don't know. Since you snipped your message it's hard to tell what's missing. Maybe you could tell us a bit about how you installed it and where from?
While Sealert (setroubleshootd) gives you graphical alerts, SE Linux' Access Vector Cache (AVC) messages get logged in /var/log/audit/audit.log (unless you don't have the auditd package installed in which case they'll end up in /var/log/messages). By grepping for those and running them through 'audit2allow' you could build a local policy (if Sealert doesn't advertise setting any booleans or running 'chcon' to set a context).
Originally Posted by Mr. C.
You might disable that SELinux hooey until you are knowledgeable in its use and find some demonstrable value in it
With all due respect but all questioning SE Linux by saying "demonstrable value" and calling it "hooey" demonstrates here is the amount of respect you regard SE Linux with. Of course you're entitled to your opinion, but for someone who appears to me as rather impartial and knowedgable I find that a bit, well, odd. If you would like to have a technical and objective discussion about SE Linux you're invited to start one in the Linux Security forum.
I'll allow Wietse Venema's (author or postfix, tcpwrappers, etc.) own humorous words speak to SELinux:
> Needless to say, I do not offer any warranties for damage done
> by Selinux brain damage.
> Kill off SeLinux, AppArmor, and so on. Postfix warranty is voided by
> such "security" "improvements".
> If someone believes that these extras are useful, then it is their
> responsibility to provide configurations that don't interfere with
> LEGITIMATE Postfix behavior.
> What about SeLinux, AppArmor, Systrace, or other goop that regulates
> system calls so that they no longer behave as documentated?
My somewhat tongue-in-cheek hooey remark was not with respect to the engineering or technical merits of SElinux; it was related to its *understandability* and *usability* for admins performing general duties (as in, this OP). The most rigorous security tool/policy available in the hands of a novice reduces the value of the tool substantially (think: ssh w/weak passords). And the more complicated the tool, the likelihood of implementing and having confidence in an understandable, sane security policy drops exponentially. My point was against security via hyper-complexity. Wait... didn't Red Hat just get compromised! Oops.
Btw. Postfix 2.5 introduced changes, which required SELinux policy changes. Postfix now uses a private data directory for certain cache files.
thanks for all the responses here. I took Mr C's advice and disabled SELinux. I'm new to linux and I can't handle most of this stuff, it makes my head spin. I have postfix started now and I can make alterations to the configuration.
Perhaps at some time in the future when I'm more experienced (50 years?) I'll resolve this SELinux thing rather than disable it.