Re: SELinux and AppArmor.

On June 17, 2019 11:50:45 PM GMT+03:00, Marko Rauhamaa <[email protected]> wrote:
>Lukas Vrabec <[email protected]>:
>> I like to see more distros using fedora selinux-policy as deault
>> SELinux policy. But as Stephen mentioned, it has to come from within.
>> From my POV, I like that refpolicy is more strict then fedora selinux
>> policy, because both policies could be used for different use cases.
>> If there is any possible cooperation with Ubuntu or SUSE on SELinux,
>> I'm more then happy to discuss possibilities.
>
>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
>participate
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.




>in distros. Ideally, an application would be written once and dropped
>as-is into every distro out there.
Focus on 'ideally".


>
>This document comes close to what is needed for us application
>developers:
>
>https://blogs.rdoproject.org/2017/09/selinux-policy-from-the-ground-up/
>
>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.

>
>The linked document by Miroslav Grepl (<URL:
>https://mgrepl.fedorapeople.org/PolicyCourse/writingSELinuxpolicy_MUNI.pdf>)
>belongs to a largish pile of information that educates you a lot about
>SELinux details but fails to teach you a methodology. First off, it's
>not clear if the document is meant for sysadmins or application
>developers.
>
>I believe I understand to a reasonable degree what labels are and how
>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 sounds
>great.

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


>
>Or maybe now that the kernel will allow the stacking of security
>modules, each application writer should write a dedicated security
>module for their application...

That would soon become... interesting

wolfy
_______________________________________________
selinux mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[email protected]