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.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
@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.