On 6/18/19 10:07 AM, Marko Rauhamaa wrote: > Manuel Wolfshant <wolfy@xxxxxxxxxxxxxxxxxx>: > >> On June 17, 2019 11:50:45 PM GMT+03:00, Marko Rauhamaa <marko@xxxxxxxxxx> wrote: >>> 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. > > 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. > Nice thought. But if somebody is writing custom policies, I'm expecting that they know security principles and are more strict then secure code. > 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. > You can look on this, it's not finished but some guide how to start with policy writing is here: http://redhatgov.io/workshops/selinux_policy/exercise1.1/ Thanks, Lukas. >>> 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 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 > > 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. > > > Marko > -- Lukas Vrabec Senior Software Engineer, Security Technologies Red Hat, Inc.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/selinux@xxxxxxxxxxxxxxxxxxxxxxx
