Apparmor denied bei named

P

Pixelpirat

Member
Hallo,
nach meinen Updates von ISCP habe ich nach dem Neustart massenhafte Einträge in der /var/log/messages
Code: 
Dec 14 16:43:33 mx kernel: [1929307.344170] audit: type=1400 audit(1639496613.058:1152): apparmor="DENIED" operation="open" profile="named" name="/sys/kernel/mm/transparent_hugepage/enabled" pid=192443 comm="named" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Dec 14 17:15:01 mx kernel: [1931196.153100] audit: type=1400 audit(1639498501.866:1179): apparmor="DENIED" operation="open" profile="named" name="/sys/kernel/mm/transparent_hugepage/enabled" pid=195971 comm="named" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Dec 14 17:25:01 mx kernel: [1931795.699808] audit: type=1400 audit(1639499101.418:1180): apparmor="DENIED" operation="open" profile="named" name="/sys/kernel/mm/transparent_hugepage/enabled" pid=196479 comm="named" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Irgendwie wird da von Apparmor etwas gesperrt. Leider stehe ich an diesem Punkt etwas auf dem Schlauch. Ich hatte mit Apparmor in der Vergangenheit nichts zu tun.

Vielleicht kann mir jemand einen Tipp geben, wie ich das Problemchen lösen kann.

Vielen Dank.
 
P

Pixelpirat

Member
Nein, das war es nicht. Ich habe herausgefunden, dass dieser Teil der Meldung
Code: 
operation="open" profile="named" name="/sys/kernel/mm/transparent_hugepage/enabled"
bedeutet, dass "named" (Profile=) Leserechte auf "/sys/kernel/mm/transparent_hugepage/enabled" (Name=) haben möchte. Dazu habe ich in der usr.sbin.named bei apparmor diesen TEintrag dazu gefügt:

Code: 
  /proc/1/environ r,
  /proc/cmdline r,
  /sys/kernel/mm/transparent_hugepage/enabled r,
  /proc/sys/kernel/osrelease r,
Diese 3 Einträge wurden jeweils beim Neustart von named bemängelt.
Ich verstehe leider den Sinn dahinter nicht, weil ich apparmor auch nicht verstehe. Darin liegt das größte Problem.
Das ist alles auf dem Master. Den Slave habe ich mir noch nicht näher angeschaut,

Dazu kommt noch, wenn ich apparmor neu startet kommen diese Meldungen in /var/log/messages:
Code: 
Dec 15 15:39:28 mx01 kernel: [76558.898381] audit: type=1400 audit(1639579168.137:58): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/sbin/haveged" pid=188942 comm="apparmor_parser"
Dec 15 15:39:28 mx01 kernel: [76558.898421] audit: type=1400 audit(1639579168.137:59): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="lsb_release" pid=188939 comm="apparmor_parser"
Dec 15 15:39:28 mx01 kernel: [76558.901111] audit: type=1400 audit(1639579168.137:60): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/bin/man" pid=188941 comm="apparmor_parser"
Dec 15 15:39:28 mx01 kernel: [76558.901118] audit: type=1400 audit(1639579168.137:61): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="man_filter" pid=188941 comm="apparmor_parser"
Dec 15 15:39:28 mx01 kernel: [76558.901122] audit: type=1400 audit(1639579168.137:62): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="man_groff" pid=188941 comm="apparmor_parser"
Dec 15 15:39:28 mx01 kernel: [76558.901127] audit: type=1400 audit(1639579168.137:63): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="nvidia_modprobe" pid=188940 comm="apparmor_parser"
Dec 15 15:39:28 mx01 kernel: [76558.901132] audit: type=1400 audit(1639579168.137:64): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="nvidia_modprobe//kmod" pid=188940 comm="apparmor_parser"
Dec 15 15:39:28 mx01 kernel: [76558.906587] audit: type=1400 audit(1639579168.145:65): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="named" pid=188944 comm="apparmor_parser"
Dec 15 15:39:28 mx01 kernel: [76558.906920] audit: type=1400 audit(1639579168.145:66): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/sbin/ntpd" pid=188945 comm="apparmor_parser"
Dec 15 15:43:08 mx01 kernel: [76779.584087] audit: type=1400 audit(1639579388.821:67): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/sbin/haveged" pid=189218 comm="apparmor_parser"

Alles Meldungen die ich erst seit dem Update auf ispc 3.2.7p1

Momentan stehe ich ohne Lösungsidee da.
 
T

Till

Administrator
ISPConfig verwendet Apparmor ja nicht, daher ist es vermutlich eher ein zeitlicher Zufall dass es mit dem ISPConfig Update zusammen gefallen ist, vielleicht ist es erst durch den beim update ausgeführen bind restart aufgefallen. Mit Apparmor kann ich Dir leider auch nicht weiter helfen, da ich es nicht eibsetze, und es muss sich um ein unabhängig von ISPConfig bestehendes Problem mit BIND handeln. Ggf. musst Du AppArmor erst mal abschalten oder in den nur reporting Modus schalten.
 
P

Pixelpirat

Member
Ok. Danke fürs Feedback. Ich werde apparmor abschalten und wenn ich mal Ruhe dafür habe mich damit beschäftigen ob es überhaupt für einen Server sinnvoll ist. Alles was ich bisher darüber gefunden hatte, bezog sich auf DesktopRechner.
 
L

logifech

Active Member
Es liegt tatsächlich an Apparmor, es verbietet nämlich die Erstellung von Files unter /etc/bind normalerweise sollte man Zonefiles unter /var/lib/bind erstellen.
 
P

Pixelpirat

Member
Zitat von logifech:
Es liegt tatsächlich an Apparmor, es verbietet nämlich die Erstellung von Files unter /etc/bind normalerweise sollte man Zonefiles unter /var/lib/bind erstellen.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Deine Aussage passt nicht zu meinen Logeinträgen. Schau dir bitte mal die Meldungen in meinem Post #1 an. Das war der Ursprung von allem. Der Logeintrag sagt das named auf ein kernelmodul kein Leserecht hat. Soweit bin ich mittlerweile gekommen.
Nach diversen Änderungsversuchen in Apparmor hatte ich die Meldungen in post #3
die Lese-/Schreibrechte für bind/named in /etc/bind und /var/bind/ waren bereits in dem default Profile von Apparmor gesetzt. Reines Debian ohne fremd repos.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top