On 26 Apr 2015, at 13:36, E.B. wrote:
[quoting me]
See the man pages for audit2allow, semodule, checkmodule,
postfix_selinux and semanage. The first provides a complete
run-through
of how to adapt your local policies from your audit logs, but it is
useful to understand the others as well.
You're recommending building a new postfix selinux policy when one
already exists? Why? Why can't I add the needed permission to the
policy that comes with the yum installation of postfix?
I advised that you create a local policy module to supplement the
postfix policy module which in fact is part of the
selinux-policy-targeted package, part of the CentOS base.
HOWEVER: Looking more closely at my latest CentOS box makes me think
that something's wrong with your installation, since I can run
"systemctl restart postfix" without any problems. Note:
# ls -lZ /var/spool/postfix/private/defer
srw-rw-rw-. postfix postfix system_u:object_r:postfix_private_t:s0
/var/spool/postfix/private/defer
You may not have a policy bug, but a deployment error of some sort which
caused that socket to be mislabeled. Try 'fixfiles -v restore' (and of
course, RTFMP for fixfiles if you don't want to relabel everything to
defaults, but keep in mind that you probably do.)
IN GENERAL whenever you have a SELinux problem that audit2allow says
will be fixed by adding an allow rule for a particular file label, Step
Zero is to make sure that the relevant file is properly labeled.
Why was it missing???
That's a question for RedHat. They maintain the default SELinux
policies
that are distributed with CentOS.
Do you know how to find the package maintainer's contact or the
right place to submit a report?
Since you're coming at this via CentOS, I'd think
https://bugs.centos.org would be the right place to report a problem in
a base package, if there were a real bug. BUT, I'm pretty sure there is
none.
By the way, I also had AVCs when I tried to add another instance of
Postfix smtpd on local port 20025. Very frustrating there is no docs
how to add a rule for this common change.
There are, and it seems you've found them and used them in this case.
Why isn't this documented somewhere?
It is. See above.
No, I was reffering to docs for the postfix yum package.
SELinux policy is not part of any Postfix package. Postfix is not
strictly Linux software. I don't believe it remains true, but
historically the conventional wisdom has been that SELinux and AppArmor
and similar tools were more trouble than they were worth for Postfix or
any other MTA in anything but a trivial configuration.
Info for people
who use it on how to open new ports. If the command I used is the
right way to do it, then it should be simple duty to add a note about
it
as a doc on a readme file or web page associated with the yum
package. Or in the "yum info" notes!
It's not a Postfix issue. It's a SELinux issue. SELinux is an *optional*
feature of *some* platforms where Postfix runs, entirely external to
Postfix. Postfix also doesn't come with explanations of pf, ipfw,
iptables, or Cisco ASA configuration. The RPM packages that are
installed by 'yum' never include substantial documentation in the notes
that 'yum info' shows.
If you're going to run a system with SELinux in enforcing mode, you
really should read the available documentation and be prepared to
*invent* local adaptations to the baseline policies to fit your local
requirements. Once you start diverging from the config that was used
in
developing the default policies you risk running into them, which is
proper: SELinux is intended to be a straitjacket on a system.
I don't know why you say these things
Because I believe them to be relevant facts that you were not taking
into account.
-- 20025 is a very minor mod,
Yes. SELinux is designed to move the security of Linux away from the
traditional discretionary access control model where minor mods
generally just work because there is nothing prohibiting them towards a
more mandatory access control model where all is prohibited except that
which defined policy allows. The "targeted" policy assembly in the RHEL
family is a reasonable compromise towards the mandatory ideal and it
seems to me that it is correct for it not to allow arbitrary listener
additions. In a system where policy is supposed to overrule software
configuration, ANY TCP listener should require a specific explicit
policy rule.
but the major problem i asking about is i guess to be a bug in the
default policy for the package -- am NOT diverging from the deafult,
postfix restart should work without need to do research how to add
obscure permission to policy that's already on the system. Only way
to add a single unlink permission to a existing policy is to create a
whole new one with a custom .te file and installing it???????? wow.
You're making more of this than it is. Assuming that in fact there's a
bug that you've found in the default postfix SELinux policy, you
wouldn't need to replicate and replace the whole base postfix.pp, you'd
need to add a single rule. When I've run across gaps in the base policy,
I've put sets of related new rules into their own new policy modules.
The flipside of SELinux being closer to a mandatory model is that when
you need to allow something like creating and deleting a particular
filesystem node you aren't required to redefine the universe of what is
banned, you just need to allow one more type of action.
