AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" Fehler

    Ich schaffe es nicht, bind9/named nach einer Migration von Ubuntu zu Debian zum Laufen zu bringen. In der Protokolldatei finde ich die folgende Ursache (Wiederholungen weggelassen):

    Code
    Feb 07 11:34:51 hostname audit[13400]: AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13400 comm="named" family="unix" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create" addr=none
Feb 07 11:34:51 hostname audit[13400]: AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13400 comm="named" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none
Feb 07 11:34:51 hostname kernel: audit: type=1400 audit(1675766091.081:193): apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13400 comm="named" family="unix" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create" addr=none
Feb 07 11:34:51 hostname kernel: audit: type=1400 audit(1675766091.081:194): apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13400 comm="named" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none
Feb 07 11:34:51 hostname audit[13413]: AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13413 comm="isc-worker0000" family="netlink" sock_type="raw" protocol=0 requested_mask="create" denied_mask="create"
Feb 07 11:34:51 hostname audit[13413]: AVC apparmor="DENIED" operation="create" profile="/usr/sbin/named" pid=13413 comm="isc-worker0000" family="unix" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create" addr=none



    Ich habe keine Ahnung von Apparmor und Google scheint nicht sehr hilfreich zu sein. Soll ich apparmor einfach abschalten oder kann das mit einigen Regeln in /etc/apparmor.d/local/usr.sbin.named behoben werden?

    Ich habe den Apparmor vorübergehend nur für named deaktiviert:

    Code
    ln -s /etc/apparmor.d/usr.sbin.named /etc/apparmor.d/disable/
apparmor_parser -R /etc/apparmor.d/disable/usr.sbin.named


    Named/bind9 ist jetzt aktiv, wird aber immer noch nicht von Liveconfig erkannt: Keine unterstützten Dienste gefunden.


    All dies gibt mir wenig Vertrauen, dass ich meinen Produktionsserver auf diese Weise aktualisieren kann. Das Funktionieren des DNS ist halt unerlässlich.

    Wir haben hier in unserer Testumgebung den BIND9 unter Debian 11 problemlos mit AppArmor am laufen.
    Die Log-Meldung deutet darauf hin, dass BIND ein Socket in einem Verzeichnis erzeugen möchte, wofür er keine Erlaubnis hat.
    Vermutlich wurde die bisherige BIND-Konfiguration vom Ubuntu migriert, und hatte da irgendwas drin was so unter Debian nicht klappt?


    Eventuell taucht in /var/log/named/messages eine Meldung auf, welche Aktion genau fehlschlägt (also welches Socket nicht erstellt werden kann).
    LiveConfig sollte den BIND unabhängig von AppArmor aber dennoch erkennen können.
    Was liefert die Ausgabe von "liveconfig --diag" (Abschnitt "Checking for DNS server software:") ?

    Zitat von kk

    Vermutlich wurde die bisherige BIND-Konfiguration vom Ubuntu migriert, und hatte da irgendwas drin was so unter Debian nicht klappt?


    Bedeutet dies, dass ich diese Frage von apt dist-upgrade mit Y hätte beantworten sollen?

    Code
    *** named.conf.options (Y/I/N/O/D/Z) [default=N] ?


    Gibt es auf Ihrem Testsystem etwas in /etc/apparmor.d/local/usr.sbin.named? Bei mir war es leer.

    Zitat von ñull

    Bedeutet dies, dass ich diese Frage von apt dist-upgrade mit Y hätte beantworten sollen?

    Code
    *** named.conf.options (Y/I/N/O/D/Z) [default=N] ?


    Diese Antwort ist eigentlich genau richtig.


    Zitat von ñull


    Gibt es auf Ihrem Testsystem etwas in /etc/apparmor.d/local/usr.sbin.named? Bei mir war es leer.


    Ja, diese Datei gibt es bei uns, und die ist recht gut gefüllt, und wurde vom Paket "bind9" mit installiert.


    Was liefert denn der Befehl "dpkg -l | grep bind9" ?

    Ich habe die Lösung gefunden! Einige Dienste waren nicht aktiviert und daher konnte bind9 nicht richtig installiert werden. Zuerst habe ich dies versucht:

    Code
    $ dpkg-reconfigure bind9
/usr/sbin/dpkg-reconfigure: bind9 is broken or not fully installed
$ apt install bind9
bind9 is already the newest version (1:9.11.5.P4+dfsg-5.1+deb10u8).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]


    Ich habe die Fragen mit den Standardoptionen beantwortet (die vorherige Frage kam allerdings nicht zurück). Dann sehe ich wieder diese Meldungen:


    Code
    bind9-pkcs11.service is a disabled or a static unit not running, not starting it.
bind9-resolvconf.service is a disabled or a static unit not running, not starting it.


    Ich habe sie vorher ignoriert, aber anscheinend versucht bind, diese beiden Unterdienste zu starten und schlägt fehl, weil sie nicht aktiviert sind. Also tat ich folgendes:


    Code
    $ systemctl enable bind9-pkcs11.service
Created symlink /etc/systemd/system/multi-user.target.wants/bind9-pkcs11.service → /lib/systemd/system/bind9-pkcs11.service.
$ systemctl enable bind9-resolvconf.service
Created symlink /etc/systemd/system/bind9.service.wants/bind9-resolvconf.service → /lib/systemd/system/bind9-resolvconf.service.


    Dann habe ich versucht, die Installation erneut durchzuführen:


    Code
    $ apt install bind9
$ liveconfig --diag
...
Checking for DNS server software:
 - Found 'bind' DNS server
   Version: '9.11.5'
   Package version: '1:9.11.5.P4+dfsg-5.1+deb10u8'
   DNSSEC support: yes
Done.


    Nach einem Neustart von liveconfig erschien bind auch im Web-Frontend. Nach dem Entfernen des Symlinks und dem Neustart von bind schien auch das erste Problem behoben zu sein:


    Code
    $ rm /etc/apparmor.d/disable/usr.sbin.named
$ apparmor_parser -R /etc/apparmor.d/usr.sbin.named
$ systemctl restart bind9
$ systemctl status bind9
● bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2023-02-07 19:28:50 CET; 2s ago


    Übrigens, ich habe meine Migration nach den Anweisungen dieses Beitrags durchgeführt: https://unix.stackexchange.com/a/718220/247520

    Problem war leider noch nicht gelöst. Nach Neustart ist Bind wieder inaktiv. Doch dann las ich Folgendes:


    Das erklärt einiges. Da ich immer noch auf Bullseye aktualisieren werde, denke ich, dass das Entfernen von Apparmor im Moment gerechtfertigt ist.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden