apparmor - dbus und network features - 15.3
Moin, auf einem frisch installierten Leap 15.3 erhalte ich folgendes -- snip -- Koldis:/home/joachim # systemctl status apparmor ● apparmor.service - Load AppArmor profiles Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled) Active: active (exited) since Sun 2022-02-20 13:08:20 CET; 22min ago Process: 394 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS) Main PID: 394 (code=exited, status=0/SUCCESS) Feb 20 13:08:12 Koldis apparmor.systemd[394]: Restarting AppArmor Feb 20 13:08:12 Koldis apparmor.systemd[394]: Reloading AppArmor profiles Feb 20 13:08:20 Koldis systemd[1]: Finished Load AppArmor profiles. -- snap -- apparmor ist also beendet. und an andere Stelle -- snipp -- Koldis:/home/joachim # systemctl status snapd ● snapd.service - Snap Daemon Loaded: loaded (/usr/lib/systemd/system/snapd.service; enabled; vendor preset: disabled) Active: active (running) since Sun 2022-02-20 13:08:34 CET; 22min ago TriggeredBy: ● snapd.socket Main PID: 986 (snapd) Tasks: 11 (limit: 4915) CGroup: /system.slice/snapd.service └─986 /usr/lib/snapd/snapd Feb 20 13:08:21 Koldis systemd[1]: Starting Snap Daemon... Feb 20 13:08:23 Koldis snapd[986]: AppArmor status: apparmor is enabled but some kernel features are missing: dbus, network Feb 20 13:08:28 Koldis snapd[986]: daemon.go:246: started snapd/2.54.3-lp153.1.1 (series 16; classic; devmode) opensuse-leap/15.3 (amd64) linux/5.3.18-150300.5> Feb 20 13:08:28 Koldis snapd[986]: daemon.go:339: adjusting startup timeout by 1m10s (pessimistic estimate of 30s plus 5s per snap) Feb 20 13:08:34 Koldis systemd[1]: Started Snap Daemon. Feb 20 13:13:36 Koldis snapd[986]: storehelpers.go:721: cannot refresh: snap has no updates available: "bare", "core18", "core20", "gnome-3-38-2004", "gtk-comm> Feb 20 13:13:36 Koldis snapd[986]: autorefresh.go:536: auto-refresh: all snaps are up-to-date -- snap -- Ich kenne mich mit apparmor nicht aus und kann jetzt nicht wirklich erkennen, wo das Problem liegt. snapd erwartet wohl ein dbus und ein network feature von apparmor, das bei der SuSE (oder auch generell) nicht vorhanden ist. Aber auch ohne snapd zeigt sich der Status von apparmor als (exited) Was läuft da schief? Gruß Joachim
Hallo Joachim, hallo zusammen, Am Sonntag, 20. Februar 2022, 13:38:59 CET schrieb Joachim H.:
auf einem frisch installierten Leap 15.3 erhalte ich folgendes
-- snip -- Koldis:/home/joachim # systemctl status apparmor ● apparmor.service - Load AppArmor profiles Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled) Active: active (exited) since Sun 2022-02-20 13:08:20 CET; 22min ago> Process: 394 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS) Main PID: 394 (code=exited, status=0/SUCCESS) [...] apparmor ist also beendet.
Ich fürchte, die systemctl-Ausgabe hat Dich etwas verwirrt ;-) "beendet" heißt: Alle AppArmor-Profile in /etc/apparmor.d/ wurden geladen. Und zwar erfolgreich, siehe status=0/SUCCESS. Da AppArmor kein Daemon ist, läuft natürlich auch kein Programm mehr (deswegen "beendet") - aber die Profile bleiben trotzdem geladen und aktiv.
und an andere Stelle
-- snipp -- Koldis:/home/joachim # systemctl status snapd [...] Feb 20 13:08:21 Koldis systemd[1]: Starting Snap Daemon... Feb 20 13:08:23 Koldis snapd[986]: AppArmor status: apparmor is enabled but some kernel features are missing: dbus, network [...] Ich kenne mich mit apparmor nicht aus und kann jetzt nicht wirklich erkennen, wo das Problem liegt.
snapd erwartet wohl ein dbus und ein network feature von apparmor, das bei der SuSE (oder auch generell) nicht vorhanden ist.
network wird im (open)SUSE-Kernel seit Jahren unterstützt, und ist seit Kernel 4.17 upstream (allerdings mit einem anderen Patch als der, der früher[tm] in den openSUSE-Kerneln war). Dazu kommt, dass für den Upstream-network-Support mindestens AppArmor 3.0 benötigt wird, während in 15.3 noch 2.13.x ist. dbus ist AFAIK erst seit Kernel 5.4 upstream, aber 15.3 hat noch 5.3.18. Außerdem wird auch für dbus mindestens AppArmor 3.0 benötigt. Ich habe von snap nicht wirklich Ahnung, meine Vermutung ist aber, dass es explizit nach dem network-Support der Ubuntu- oder neueren Upstream- Kernel sucht und diesen nicht findet. Bei network scheitert es vermutlich nur am zu alten AppArmor-Userspace, bei dbus zusätzlich auch an der Kernelversion. Trotzdem kannst Du snap benutzen. Es ist aber evtl. nicht ganz so sicher, wenn network und dbus nicht von AppArmor überwacht/eingeschränkt werden. Kleine Vorschau: In Leap 15.4 wird es AppArmor 3.0.4 und Kernel 5.14 geben. Das sollte[1] beide Probleme lösen und snap etwas sicherer machen. Gruß Christian Boltz [1] "Sollte", weil ich das nicht getestet habe. -- Die c't schrieb mal sinngemäß auf ein Mail: Aus einem MP3-File ein Midifile zu machen ist so, als würdest Du mit einem "Wiener Wald Händle" zum Tierarzt gehen und fragen: "Das arme Tier, Herr Doktor, ist da noch was zu retten?" [Dennis Kielhorn in suse-laptop]
Hallo Christian, Danke für die Info. Wäre dann jetzt TW eine Alternative um nicht auf den Release von 15.4 im Juni warten zu müssen? Ich würde jetzt ungern Ubuntu installieren wollen. Ob das snap-Zeugs ohne apparmor läuft, denke ich nicht. Zwar hat es wohl ein einziges mal funktioniert aber jetzt kommt auf der Konsole immer die Meldung -- snip -- joachim@Koldis:/snap/bin> ./musescore.mscore cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1 -- snap -- siehe dazu: https://github.com/lxc/lxd/issues/4402 Ist zwar für Ubuntu aber da bin ich auf den Hinweis mit apparmor gestoßen. J. Am 20.02.2022 um 14:08 schrieb Christian Boltz:
Hallo Joachim, hallo zusammen,
Am Sonntag, 20. Februar 2022, 13:38:59 CET schrieb Joachim H.:
auf einem frisch installierten Leap 15.3 erhalte ich folgendes
-- snip -- Koldis:/home/joachim # systemctl status apparmor ● apparmor.service - Load AppArmor profiles Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled) Active: active (exited) since Sun 2022-02-20 13:08:20 CET; 22min ago> Process: 394 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS) Main PID: 394 (code=exited, status=0/SUCCESS) [...] apparmor ist also beendet. Ich fürchte, die systemctl-Ausgabe hat Dich etwas verwirrt ;-)
"beendet" heißt: Alle AppArmor-Profile in /etc/apparmor.d/ wurden geladen. Und zwar erfolgreich, siehe status=0/SUCCESS.
Da AppArmor kein Daemon ist, läuft natürlich auch kein Programm mehr (deswegen "beendet") - aber die Profile bleiben trotzdem geladen und aktiv.
und an andere Stelle
-- snipp -- Koldis:/home/joachim # systemctl status snapd [...] Feb 20 13:08:21 Koldis systemd[1]: Starting Snap Daemon... Feb 20 13:08:23 Koldis snapd[986]: AppArmor status: apparmor is enabled but some kernel features are missing: dbus, network [...] Ich kenne mich mit apparmor nicht aus und kann jetzt nicht wirklich erkennen, wo das Problem liegt.
snapd erwartet wohl ein dbus und ein network feature von apparmor, das bei der SuSE (oder auch generell) nicht vorhanden ist. network wird im (open)SUSE-Kernel seit Jahren unterstützt, und ist seit Kernel 4.17 upstream (allerdings mit einem anderen Patch als der, der früher[tm] in den openSUSE-Kerneln war). Dazu kommt, dass für den Upstream-network-Support mindestens AppArmor 3.0 benötigt wird, während in 15.3 noch 2.13.x ist.
dbus ist AFAIK erst seit Kernel 5.4 upstream, aber 15.3 hat noch 5.3.18. Außerdem wird auch für dbus mindestens AppArmor 3.0 benötigt.
Ich habe von snap nicht wirklich Ahnung, meine Vermutung ist aber, dass es explizit nach dem network-Support der Ubuntu- oder neueren Upstream- Kernel sucht und diesen nicht findet. Bei network scheitert es vermutlich nur am zu alten AppArmor-Userspace, bei dbus zusätzlich auch an der Kernelversion.
Trotzdem kannst Du snap benutzen. Es ist aber evtl. nicht ganz so sicher, wenn network und dbus nicht von AppArmor überwacht/eingeschränkt werden.
Kleine Vorschau: In Leap 15.4 wird es AppArmor 3.0.4 und Kernel 5.14 geben. Das sollte[1] beide Probleme lösen und snap etwas sicherer machen.
Gruß
Christian Boltz
[1] "Sollte", weil ich das nicht getestet habe.
OK, das Problem hat an Relevanz verloren. Obwohl ich im Vorfeld die Repos durch bin, hatte ich keine Hinweise auf musescore gefunden und nur daher bin ich auf snap gewechselt. Habe aber gerade gesehen, dass musecore doch vorhanden und damit snap vorerst nicht mehr von Noten ist Danke, habe trotzdem was gelernt. Joachim Am 20.02.2022 um 14:41 schrieb Joachim H.:
Hallo Christian,
Danke für die Info.
Wäre dann jetzt TW eine Alternative um nicht auf den Release von 15.4 im Juni warten zu müssen? Ich würde jetzt ungern Ubuntu installieren wollen.
Ob das snap-Zeugs ohne apparmor läuft, denke ich nicht. Zwar hat es wohl ein einziges mal funktioniert aber jetzt kommt auf der Konsole immer die Meldung
-- snip -- joachim@Koldis:/snap/bin> ./musescore.mscore cannot change profile for the next exec call: No such file or directory snap-update-ns failed with code 1 -- snap --
siehe dazu: https://github.com/lxc/lxd/issues/4402
Ist zwar für Ubuntu aber da bin ich auf den Hinweis mit apparmor gestoßen.
J.
Am 20.02.2022 um 14:08 schrieb Christian Boltz:
Hallo Joachim, hallo zusammen,
Am Sonntag, 20. Februar 2022, 13:38:59 CET schrieb Joachim H.:
auf einem frisch installierten Leap 15.3 erhalte ich folgendes
-- snip -- Koldis:/home/joachim # systemctl status apparmor ● apparmor.service - Load AppArmor profiles Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled) Active: active (exited) since Sun 2022-02-20 13:08:20 CET; 22min ago> Process: 394 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS) Main PID: 394 (code=exited, status=0/SUCCESS) [...] apparmor ist also beendet. Ich fürchte, die systemctl-Ausgabe hat Dich etwas verwirrt ;-)
"beendet" heißt: Alle AppArmor-Profile in /etc/apparmor.d/ wurden geladen. Und zwar erfolgreich, siehe status=0/SUCCESS.
Da AppArmor kein Daemon ist, läuft natürlich auch kein Programm mehr (deswegen "beendet") - aber die Profile bleiben trotzdem geladen und aktiv.
und an andere Stelle
-- snipp -- Koldis:/home/joachim # systemctl status snapd [...] Feb 20 13:08:21 Koldis systemd[1]: Starting Snap Daemon... Feb 20 13:08:23 Koldis snapd[986]: AppArmor status: apparmor is enabled but some kernel features are missing: dbus, network [...] Ich kenne mich mit apparmor nicht aus und kann jetzt nicht wirklich erkennen, wo das Problem liegt.
snapd erwartet wohl ein dbus und ein network feature von apparmor, das bei der SuSE (oder auch generell) nicht vorhanden ist. network wird im (open)SUSE-Kernel seit Jahren unterstützt, und ist seit Kernel 4.17 upstream (allerdings mit einem anderen Patch als der, der früher[tm] in den openSUSE-Kerneln war). Dazu kommt, dass für den Upstream-network-Support mindestens AppArmor 3.0 benötigt wird, während in 15.3 noch 2.13.x ist.
dbus ist AFAIK erst seit Kernel 5.4 upstream, aber 15.3 hat noch 5.3.18. Außerdem wird auch für dbus mindestens AppArmor 3.0 benötigt.
Ich habe von snap nicht wirklich Ahnung, meine Vermutung ist aber, dass es explizit nach dem network-Support der Ubuntu- oder neueren Upstream- Kernel sucht und diesen nicht findet. Bei network scheitert es vermutlich nur am zu alten AppArmor-Userspace, bei dbus zusätzlich auch an der Kernelversion.
Trotzdem kannst Du snap benutzen. Es ist aber evtl. nicht ganz so sicher, wenn network und dbus nicht von AppArmor überwacht/eingeschränkt werden.
Kleine Vorschau: In Leap 15.4 wird es AppArmor 3.0.4 und Kernel 5.14 geben. Das sollte[1] beide Probleme lösen und snap etwas sicherer machen.
Gruß
Christian Boltz
[1] "Sollte", weil ich das nicht getestet habe.
participants (2)
-
Christian Boltz
-
Joachim H.