[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postfix-users
Subject:    Re: [OT] Broken Selinux Postfix Policy?
From:       "Bill Cole" <postfixlists-070913 () billmail ! scconsult ! com>
Date:       2015-04-27 0:10:57
Message-ID: D3DEF054-F47C-4F0E-83D0-C76F26CCC0B8 () billmail ! scconsult ! com
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]