On 26 Apr 2015, at 16:44, E.B. wrote:
[...]
usually I use restorecon, what's difference to fixfiles
if you don't mnind?
I use fixfiles because its command syntax sticks in my head better. One
can do the same things with restorecon. The author of both prefers
restorecon
(https://lists.fedoraproject.org/pipermail/selinux/2011-November/014117.html)
but on the other hand he did write fixfiles.
[...]
i don't mind that, seems like good choice, but what's
missing for people not experts in selinux (esp. if it's
forced turned on in default for *everyone*) is some docs
by *someone* hosted *somewhere* like tutorial on the simple
rule you need to add to open a new smtpd port.... i think
it's too much to expect you have to dig around in the port
list policy to try to figure out what _t type is being used
for postfix rules and then add the right one. too convoluted.
It is an unavoidable aspect of mandatory access control systems that
their administration is more complex, redundant, and convoluted than
that of traditional discretionary access control systems. That's why so
many people for so long have simply disabled SELinux or AppArmor or
whatever other security layers are available to them and relied on the
various unrelated subsystems that might exist on a system to each handle
their own security independently. The roots of the convolution are in
the design roots of SELinux and what sorts of systems seemed to need
better security 20 years ago...
But you're right: it certainly would be helpful if RedHat, being the
vanguard in enabling SELinux by default, would do a better job of making
sure that their docs for their base SELinux policy were installed more
consistently and were easier to navigate. It is insane that to get docs
on the postfix policies in EL7, one must install selinux-policy-devel
and dig through 14 postfix_*_selinux man pages and even then resort to
'semanage port -l|grep 25' to figure out how to bless a second smtpd. I
guess the proper way to push that would be a CentOS bug report.
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.
the point was exactly that, didn't want to replicate
anything and also not add another whole policy for something
already on the system. but if there is any other problem
i guess only way is to add a new local policy with just one
rule in it?
Yes, but that's one of the nice parts of the design of SELinux. You can
add local modules that deal with the same labels and functional roles as
the base policies without replacing the base modules. One is expected to
need bits of local policy that diverge from the base reference policy.
