BIND DNSSEC Permission denied

  • Hallo,


    leider erhalte ich bei meinem BIND Setup mit DNSSEC die folgende Meldung in den Logs und, dass die .jnl / .jbk Files nicht erstellt werden konnten. Die Berechtigungen habe ich mehrfach geprüft. BIND darf in dem Verzeichniss schreiben. AppArmor habe ich auch temporär deaktiviert. Brachte leider keine Abhilfe. BIND schreibt trotzdem nicht. Weiß jemand von euch weiter?

    Code
    Feb 03 21:23:09 ns1.domain.tld named[16869]: zone domain.tld/IN (signed): reconfiguring zone keys
    Feb 03 21:23:09 ns1.domain.tld named[16869]: /etc/bind/domains/zone_domain.tld.signed.jnl: create: permission denied
    Feb 03 21:23:09 ns1.domain.tld named[16869]: zone domain.tld/IN (signed): zone_rekey:dns_journal_open -> unexpected error
  • Hat es schon mal funktioniert?
    SELinux/AppArmor - Berechtigungen und ALCs (getfacl) wären die üblichen Verdächtigen. Aber das hast Du ja scheinbar schon gecheckt.


    Mein HowTo zu diesem Thema ist hier: https://hitco.at/blog/sicherer…ste-anbieter-dnssec-dane/

    Konkretes PDF hier:

    https://hitco.at/blog/wp-conte…DANE-HowTo-2016-04-28.pdf


    Auf Seite 24 siehst Du, wie ich den Domains-Ordner mit Ownership und Berechtigungen versehe.

  • Hallo gunnarh,


    es hat noch nicht funktioniert, ist ein neues Setup.


    Ich habe mich in der Tat an dein HowTo orientiert und schon mehrfach die Berechtigungen neu gesetzt, wie beschrieben:


    Code
    chown -R root:bind /etc/named/domains
      chmod 0660 –R /etc/named/domains
      chmod 2770 /etc/named/domains
      chmod 2770 /etc/named/domains/keys


    Das Verzeichnis domains schaut so aus:

    Code
    drwxrws--- 3 root bind 4096 Feb  3 20:17 domains

    im Verzeichnis domains so:

    Code
    -rw-rw---- 1 root bind 2329 Feb  3 19:01 domains.conf
    drwxrws--- 2 root bind 4096 Feb  3 18:59 keys
    [...]

    AppArmor hatte ich wie folgt ausgeschaltet:

    Code
    service apparmor stop

    Vielleicht habe ich auch etwas übersehen, bin für jede Hilfe dankbar!


    Edit: Debian 10 ist hier im Einsatz.

  • Ich bin mit AppArmor leider (noch) nicht vertraut.

    Soweit ich das verstehe kann der AppArmor-Schutz aber nicht einfach durch Stoppen des Service abgeschaltet werden. Dafür müsste man schon einen Kernel-Parameter ändern und neu starten.


    Wenn ich

    https://wiki.ubuntu.com/DebuggingApparmor

    richtig verstehe, wäre die empfohlene Vorgangsweise:


    Code
    sudo aa-complain /usr/sbin/named

    auszuführen, um für den named-Prozess AppArmor temporär außer Kraft zu setzen.

  • Richtig, mit aa-status findest du auch den aktuellen Zustand der einzelnen Prozesse und Profile heraus. Unter Debian Buster musst du da ggf eine zusätzliche im Profil hinzufügen (/etc/apparmor.d/usr.sbin.named.conf)

  • Hallo,


    ja, tatsächlich liegt es an AppArmor. Leider habe auch ich von AppArmor (noch) wenig Ahnung.


    Debugmodus kann wieder mit

    Code
    aa-enforce

    zurückgenommen werden?

    @chrko: Wie kann in diesem Fall der Eintrag in /etc/apparmor.d/usr.sbin.named.conf aussehen? Was unterscheidet dies von /etc/apparmor.d/local/usr.sbin.named.conf?

  • Du musst in dem Profil folgende Zeile auf deine Pfade angepasst hinzufügen:

    Code
    /etc/bind/zones/** rw,

    Ich habe mich leider auch noch nicht im Detail mit apparmor weiter auseinander gesetzt. Bei mir (Debian 10/Buster) existiert /etc/apparmor.d/local/README, die die Unterscheidung erklärt. Ich hatte beim "schnell schnell" fixen einfach den Eintrag in /etc/apparmor.d/usr.sbin.named hinzugefügt an entsprechender Stelle. Am Ende der Datei wird jedoch die Datei /etc/apparmor.d/local/usr.sbin.named eingebunden, so dass auch hier diese Zeile einfach einfügen kannst.


    Viele Grüße