Re: SELinux and AppArmor.

Lukas Vrabec <[email protected]> Wed, 19 Jun 2019 17:54:40 +0200
Newsgroups	gmane.linux.redhat.fedora.selinux
Organization	Red Hat, Inc.
Message-ID	<[email protected]>
On 6/18/19 10:07 AM, Marko Rauhamaa wrote:
> Manuel Wolfshant <[email protected]>:
> 
>> On June 17, 2019 11:50:45 PM GMT+03:00, Marko Rauhamaa <[email protected]> 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.

_______________________________________________
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]
signature.asc (application/pgp-signature, 488 B)