On 10 Jun 2019, at 10:00, Lukas Vrabec lvrabec@redhat.com wrote:

It's not really easy to have SELinux enabled together with AppArmor on one system.

This is not quite true anymore, the kernel now has LSM stacking so you can run apparmor underneath selinux or, I believe, the other way around. You can look at https://lwn.net/Articles/785390/ https://lwn.net/Articles/785390/ for a starting point for more information.

AppArmor is not supported on Fedora.

Perhaps it should be supported in this model?

Best regards ZK

On Thu, Jun 13, 2019 at 12:53 AM Zygmunt Krynicki me@zygoon.pl wrote:

On 10 Jun 2019, at 10:00, Lukas Vrabec lvrabec@redhat.com wrote:

It's not really easy to have SELinux enabled together with AppArmor on one system.

This is not quite true anymore, the kernel now has LSM stacking so you can run apparmor underneath selinux or, I believe, the other way around. You can look at https://lwn.net/Articles/785390/ for a starting point for more information.

LSM stacking is still a work-in-progress. Some preparatory work has already been merged, but the final bits are still undergoing review. The latest patchset is being discussed here:

https://lore.kernel.org/selinux/20190531231020.628-1-casey@schaufler-ca.com/...

AppArmor is not supported on Fedora.

Perhaps it should be supported in this model?

Best regards ZK _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...

-- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc.

Thanks, but I meant was can AppArmor cause no Linux distro use SELinux anymore and use AppArmor instead of SELinux?

Sent from Yahoo Mail on Android

On Thu, Jun 13, 2019 at 4:11 PM, Ondrej Mosnacekomosnace@redhat.com wrote: On Thu, Jun 13, 2019 at 1:33 PM Ondrej Mosnacek omosnace@redhat.com wrote:

On Thu, Jun 13, 2019 at 12:53 AM Zygmunt Krynicki me@zygoon.pl wrote:

...

On 10 Jun 2019, at 10:00, Lukas Vrabec lvrabec@redhat.com wrote:

It's not really easy to have SELinux enabled together with AppArmor on one system.

This is not quite true anymore, the kernel now has LSM stacking so you can run apparmor underneath selinux or, I believe, the other way around. You can look at https://lwn.net/Articles/785390/ for a starting point for more information.

LSM stacking is still a work-in-progress. Some preparatory work has already been merged, but the final bits are still undergoing review. The latest patchset is being discussed here:

https://lore.kernel.org/selinux/20190531231020.628-1-casey@schaufler-ca.com/...

Sorry, actually this is the latest version:

https://lore.kernel.org/selinux/20190602165101.25079-1-casey@schaufler-ca.co...

...

AppArmor is not supported on Fedora.

Perhaps it should be supported in this model?

Best regards ZK _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...

-- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc.

On Mon, Jun 17, 2019 at 4:03 AM Ondrej Mosnacek omosnace@redhat.com wrote:

On Thu, Jun 13, 2019 at 1:59 PM Jason Long hack3rcon@yahoo.com wrote:

...

Thanks, but I meant was can AppArmor cause no Linux distro use SELinux anymore and use AppArmor instead of SELinux?

Why would you want to do that? What benefit would it bring to Fedora?

To be blunt, the poor adoption of SELinux in other distros is largely because the reference SELinux policy maintained by Tresys doesn't work at all. I wish Red Hat SELinux engineers would reach out to other distros and help them transition to our SELinux policy implementation[1], because it actually _works_.

For example, SUSE supports SELinux and AppArmor, but the selinux-policy package they have is based on refpolicy, which is horribly broken. Someone should work with them to migrate to the fedora-selinux policy.

In Debian, they've been so paralyzed about how to do security in the first place, they did nothing for over a decade. They have a hard time making any kind of decision.

Ubuntu had an SELinux expert over a decade ago, but he moved to Google and wrote the SELinux policies for Chrome OS and Android, as both use SELinux.

If Red Hat were to help other distros support SELinux using our policy and our enhanced tools, then the community around SELinux would be much stronger and there'd be much more usage and upstream support for it due to the higher exposure.

[1]: https://github.com/fedora-selinux/selinux-policy

-- 真実はいつも一つ！/ Always, there's only one truth!

On 6/17/19 5:07 PM, Stephen Smalley wrote:

On 6/17/19 4:23 AM, Neal Gompa wrote:

...

On Mon, Jun 17, 2019 at 4:03 AM Ondrej Mosnacek omosnace@redhat.com wrote:

...

On Thu, Jun 13, 2019 at 1:59 PM Jason Long hack3rcon@yahoo.com wrote:

...

Thanks, but I meant was can AppArmor cause no Linux distro use SELinux anymore and use AppArmor instead of SELinux?

Why would you want to do that? What benefit would it bring to Fedora?

To be blunt, the poor adoption of SELinux in other distros is largely because the reference SELinux policy maintained by Tresys doesn't work at all. I wish Red Hat SELinux engineers would reach out to other distros and help them transition to our SELinux policy implementation[1], because it actually _works_.

For example, SUSE supports SELinux and AppArmor, but the selinux-policy package they have is based on refpolicy, which is horribly broken. Someone should work with them to migrate to the fedora-selinux policy.

In Debian, they've been so paralyzed about how to do security in the first place, they did nothing for over a decade. They have a hard time making any kind of decision.

Ubuntu had an SELinux expert over a decade ago, but he moved to Google and wrote the SELinux policies for Chrome OS and Android, as both use SELinux.

If Red Hat were to help other distros support SELinux using our policy and our enhanced tools, then the community around SELinux would be much stronger and there'd be much more usage and upstream support for it due to the higher exposure.

I'm certainly in favor of encouraging wider adoption and use of SELinux by other distros, but I'm not sure about your assessment of the root causes of the current lack of support or how to address them.

I haven't looked in a while, but at least at some point, SUSE was in effect just cloning the Fedora SELinux-related packages along with all of their patches.  That wasn't really the problem.  I think the problem is that SELinux support is not a first class feature of SUSE, isn't part of their QA process, and isn't getting any testing or help from their other developers or users beyond whoever maintains the SELinux-related packages (and maybe not even by that person beyond a token "does it still boot" test). Even if they use Fedora's policy (if they aren't already), they will still need some policy adaptation for their particular distro distinctives and they will still need a developer and user community that is actively testing and maintaining it.  The latter is not something Red Hat or others can really provide for them externally; it has to come from within.

Agree here. 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.

Lukas.

With respect to Android, I just wanted to clarify the history there: we created the original Android SELinux reference implementation including policy and userspace bits and got it adopted into Android via the Android Open Source Project [1].  No one from Ubuntu was ever involved to my knowledge.  The Android security team did a great job integrating it and then building upon it in every subsequent Android release, but I'm not aware of any connection to Ubuntu.  ChromeOS has only gained SELinux support recently as a side effect of adding the Android container support.  There is work in progress to expand that support to the rest of ChromeOS but that is also being led by someone previously involved in the Android SELinux integration, not someone from Ubuntu. In any event, the key to the long term viability and success of Android SELinux support is that it is a first class feature (actually a mandatory feature of Android), is part of their standard testing processes, and gets wider testing and help from the entire Android team and ecosystem.

[1] http://selinuxproject.org/page/SEAndroid _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org 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@lists.fedoraproject.or...

On June 17, 2019 11:50:45 PM GMT+03:00, Marko Rauhamaa marko@pacujo.net wrote:

Lukas Vrabec lvrabec@redhat.com:

...

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

On 6/18/19 10:07 AM, Marko Rauhamaa wrote:

Manuel Wolfshant wolfy@nobugconsulting.ro:

...

On June 17, 2019 11:50:45 PM GMT+03:00, Marko Rauhamaa marko@pacujo.net 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