Requires: apparmor-abstractions
HI! Should adding AppArmor profiles directly to service packages be truly optional? Or would it be acceptable to e.g. add Requires: apparmor-abstractions I've copied lines like this from other .spec files: %if %{with apparmor} BuildRequires: apparmor-abstractions BuildRequires: apparmor-rpm-macros Recommends: apparmor-abstractions %endif But then I also have to conditionally take care of %dir %{_sysconfdir}/apparmor.d etc. Is this best practice? Or can I rely on apparmor-abstractions being present anyway and remove all the conditionals? Ciao, Michael.
On Tue, Feb 23, Michael Ströder wrote:
Is this best practice? Or can I rely on apparmor-abstractions being present anyway and remove all the conditionals?
apparmor is purly optional and we also provide and use SELinux meanwhile. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Dne 23. 02. 21 v 22:41 Thorsten Kukuk napsal(a):
[…] we also provide and use SELinux meanwhile.
Well, this seems like the optimistic declaration of the year, considering the state of our SELinux support. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Give a man a regular expression and he’ll match a string… teach him to make his own regular expressions and you’ve got a man with problems. -- yakugo in http://regex.info/blog/2006-09-15/247#comment-3022
On Tuesday 2021-02-23 22:44, Matěj Cepl wrote:
Dne 23. 02. 21 v 22:41 Thorsten Kukuk napsal(a):
[…] we also provide and use SELinux meanwhile.
Well, this seems like the optimistic declaration of the year, considering the state of our SELinux support.
1. modprobe iptable_filter 2. Declare "we're using iptables" It's even active, not like that setenforce= option you first need in selinux ;-)
On Tue, Feb 23, Jan Engelhardt wrote:
On Tuesday 2021-02-23 22:44, Matěj Cepl wrote:
Dne 23. 02. 21 v 22:41 Thorsten Kukuk napsal(a):
[…] we also provide and use SELinux meanwhile.
Well, this seems like the optimistic declaration of the year, considering the state of our SELinux support.
1. modprobe iptable_filter 2. Declare "we're using iptables"
It's even active, not like that setenforce= option you first need in selinux ;-)
You don't need a setenforce= option for SELinux and the security=selinux option is only necessary since we patched our kernel. Else you would need a security=apparmor option. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Tue, Feb 23, Matěj Cepl wrote:
Dne 23. 02. 21 v 22:41 Thorsten Kukuk napsal(a):
[…] we also provide and use SELinux meanwhile.
Well, this seems like the optimistic declaration of the year, considering the state of our SELinux support.
We have everything which is required to install and enable it, we have meanwhile QA for it, and for MicroOS it's now even the default and works fine as Container Host. For everything else, as already written some time ago: we need volunteers who test their typical workload, report bugs and even better, help to debug and adjust the policy. There will not be magically an armee of people fixing everything for you. At least on MicroOS, the state of SELinux is much better than the one of AppArmor, where we even don't have profiles for most services. The last time I checked, we had one service without SELinux profile on MicroOS, while with AppArmor, only one service was protected... Thorsten
Best,
Matěj
-- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Give a man a regular expression and he’ll match a string… teach him to make his own regular expressions and you’ve got a man with problems. -- yakugo in http://regex.info/blog/2006-09-15/247#comment-3022
pub rsa4096 2016-04-27 [SC] 3C76A027CA45AD7098B5BC1D79205802880BC9D8 uid Matěj Cepl <mcepl@cepl.eu> uid Matěj Cepl <ceplm@seznam.cz> uid Matěj Cepl <mcepl@redhat.com> uid Matěj Cepl <matej.cepl@gmail.com> uid Matěj Cepl <matej@ceplovi.cz> sub rsa4096 2016-04-27 [E]
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Dne 23. 02. 21 v 23:00 Thorsten Kukuk napsal(a):
We have everything which is required to install and enable it, we have meanwhile QA for it, and for MicroOS it's now even the default and works fine as Container Host.
True, ~@stitny$ getenforce Permissive ~@stitny$ (that's my main workstation), but I know perfectly well (from my experience with SELinux at Red Hat) that for the real SELinux use we need at least one full-time employee who doesn't do anything else than fixes SELinux policy to make it work. Then we can get to that state like Fedora, where well over two thirds of installations have SELinux in the enforcing state, but without that it feels like bungee-jumping without the cord.
For everything else, as already written some time ago: we need volunteers who test their typical workload, report bugs and even better, help to debug and adjust the policy. There will not be magically an armee of people fixing everything for you.
We don't an army, but somebody who would respond in some reasonable response time to my bugs (that's absolutely zero criticism to you or Johannes, but I am afraid neither of you have SELinux as their only responsibility, right?).
At least on MicroOS, the state of SELinux is much better than the one of AppArmor, where we even don't have profiles for most services. The last time I checked, we had one service without SELinux profile on MicroOS, while with AppArmor, only one service was protected...
Nothing in any of my messages should indicate that I approve of AppArmor, or that I think we actually support it. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 I disapprove of what you say, but I will defend to the death your right to say it. -- mistakenly attributed to Voltaire
Hello, Am Dienstag, 23. Februar 2021, 21:24:56 CET schrieb Michael Ströder:
Should adding AppArmor profiles directly to service packages be truly optional?
Or would it be acceptable to e.g. add
Requires: apparmor-abstractions
I'd say that's the correct thing if your package ships an AppArmor profile. A typical profile has #include <tunables/global> and #include <abstractions/base> (and probably more includes). These files are shipped in apparmor-abstractions, so #include'ing them means they are required by the profile. In case someone wonders - this won't _force_ anybody into enabling AppArmor. However, I'd highly recommend to enable AppArmor - for example, the samba profiles stopped an exploit from being exploited a few years ago. Regards, Christian Boltz -- You guys are right, how embarrassing. I'll crawl back under my rock for the week, sorry for the false alert. (At least I managed to confuse even Coolo, not that easy. :-) [Gerald Pfeifer in opensuse-factory]
participants (5)
-
Christian Boltz -
Jan Engelhardt -
Matěj Cepl -
Michael Ströder -
Thorsten Kukuk