Manuel Wolfshant <wolfy(a)nobugconsulting.ro>:
On June 17, 2019 11:50:45 PM GMT+03:00, Marko Rauhamaa
>I believe distros writing policies is a bad idea. It should be up to
>application developers to contribute not only code but also the
>associated systemd, firewall and SELinux integration.
>IOW, there should be a clear methodology for applications to
That is an idealustic approach which ignores that way too many
develiperrs (or maybe I should say code writers) blatantly ignore
minimal security requiremets. Allowing _them_ to write the selinux
policy brings in the risk to render selinux useless simply
becausevthey'd write polucies that would not catch / block their coding
errors . And I mean here, among others, ipipes that are not used
correctly or accessing memory regions which they should not.
Hm, you trust an application developer to run code as root on the CPU
but don't trust them to write their own security policies.
Thing is, the application developer knows what the application intends
to do and can write a security policy matching those intentions. If a
generic security expert were to write the policy, they'd have to do some
guesswork and reverse engineering.
I'm an application developer. Nobody's going to integrate my application
with the distro except me and my teammates. It would help us
tremendously if there were a cookbook for the likes of us.
>However, I'm a bit appalled that they would recommend:
> * Use audit2allow
Unfortunately audit2allow , despite being extremely useful, can also
lead to incorrect or less than optimal policies. Except.for very simple
cases, its recommenations shiuld be reviewed by someone with a good
understanding of selinux.
(I'm beginning the suspect "someone with a good understanding of
selinux" is a mythical creature...)
What you are saying is that only a handful of distro high priests should
be trusted the development of security policies. For sysadmins, there
are the "booleans." For application developers, nothing.
>I believe I understand to a reasonable degree what labels are and
>SELinux does its enforcement mechanically. Similarly I understand the
>wavelengths of the red and blue colors, but that doesn't make me a
>Michelangelo. Or I understand the function of white and black piano
>keys, but that doesn't make me a Chopin. Advising me to use
>audit2allow is like telling me to keep banging the piano keys until it
And I fully agree with you here.. Which is why I do not agree with
letting the developers write the selinux policies for theit code. Or
better said, not using undigested whatever policy they might provide
You see, there's nobody to digest what I produce except my customer, who
expects the application to just plain work and do the right thing on
their distro of choice.