Arch Linux

cgroup: cgroup2: unknown option "nsdelegate

primus

Hallo Forenmitglieder,

ich erhalte beim Start (tty1) folgende Meldung:

journalctl -b | grep cgroup
Okt 15 09:12:05 Archsilver kernel: cgroup: cgroup2: unknown option "nsdelegate"
Okt 15 09:12:05 Archsilver systemd[1]: File /usr/lib/systemd/system/systemd-journald.service:33 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.
Okt 15 09:12:05 Archsilver systemd[1]: File /usr/lib/systemd/system/systemd-udevd.service:32 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.
Okt 15 09:12:05 Archsilver systemd[1]: File /usr/lib/systemd/system/systemd-logind.service:34 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.
Okt 15 09:12:07 Archsilver systemd[1]: File /usr/lib/systemd/system/systemd-hostnamed.service:33 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.

Wenn es unter anderem mit iptables zu tun hat, ja dieser service wurde aktiviert.

Weiß jemand von euch, was man hier anpassen muss um sich auch keine Sicherheitslücke hereinzuholen?

Folgender Beitrag wurde gefunden:
https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html

Abschnitt: IPAddressAllow=ADDDRESS[/PREFIXLENGTH]…, IPAddressDeny=ADDRESS[/PREFIXLENGTH]…¶

Danke/Gruss/Primus

Greg

primus schrieb...Wenn es unter anderem mit iptables zu tun hat, ja dieser service wurde aktiviert

Was gibt denn # iptables -L heraus.

shibumi

Das hat nichts mit iptables zu tun. Das liegt am neuem systemd feature namens "IP Accounting". Siehe Lennart Poetterings Blogeintrag dazu: http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html
Ich habe das mal im systemd Code nachgeschlagen wann diese Meldung auftritt:


        /* Checks whether BPF firewalling is supported. For this, we check three things:
         *
         * a) whether we are privileged
         * b) whether the unified hierarchy is being used
         * c) the BPF implementation in the kernel supports BPF LPM TRIE maps, which we require

Mir würde spontan der Kernel einfallen. Was für einen Kernel hast du installiert? selbst kompiliert?

primus

Erstmal Danke für eure Unterstützung!

@shibumi, kein selbstkompilierter Kernel
uname -a
Linux Archsilver 4.9.56-1-lts #1 SMP Thu Oct 12 22:34:15 CEST 2017 x86_64 GNU/Linux

@Greg
das einzige was interessant bei den iptables wäre der Eintrag:
iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

Alles andere DROP wenn nicht explizit freigegeben.

primus

Wie steht es mit dem zusätzlichen Parameter "IPAddressAllow" wie im Beitrag beschrieben wird.
http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html

IP Access Lists
So much about IP accounting. Let's now have a look at IP access control with systemd 235. As mentioned above, the two new unit file settings, IPAddressAllow= and IPAddressDeny= maybe be used for that. They operate in the following way:

If the source address of an incoming packet or the destination address of an outgoing packet matches one of the IP addresses/network masks in the relevant unit's IPAddressAllow= setting then it will be allowed to go through.

Otherwise, if a packet matches an IPAddressDeny= entry configured for the service it is dropped.

If the packet matches neither of the above it is allowed to go through.

----------------------------------------------------------------------------------------------------------------------------------

Or in other words, IPAddressDeny= implements a blacklist, but IPAddressAllow= takes precedence.

Übersetzt: Mit anderen Worten, IPAddressDeny = implementiert eine Blacklist, aber IPAddressAllow = hat Vorrang.

----------------------------------------------------------------------------------------------------------------------------------

Let's try that out. Let's modify our last example above in order to get a transient service running an interactive shell which has such an access list set:

z.B. IPAddressAllow=localhost
IPAddressDeny=any

Sicherheitsbedenklich und funktioniert das überhaupt so, wenn ich diesen zusätzlichen Paramter in den oben aufgeführten " .service:3x" eintrage?

primus

niemand schriebDie im Threadtitel erwähnte Message ist mir heute auch untergekommen: da wurde versehentlich ein nicht zu dem zu startenden System passender Kernel gebootet. Ob die Meldung nun am altem Kernel und dazu nicht kompatiblen Modulen lag, oder am aktuellen systemd in Verbindung mit dem alten Kernel, habe ich nicht weiter evaluiert – ich hab’s so hingebogen, dass der aktuelle Kernel geladen wird, und gut.

Spricht bei dir viel dagegen, den aktuellen Kernel zu verwenden? Wenn nicht, würde ich einfach updaten.

Da zurzeit der Rest zufriedenstellend Funktioniert, möchte ich ungern den Kernel wechseln.
Trotzdem Danke für die getestete Möglichkeit, werde ich evtl. in Betracht ziehen.

Gruss/Primus

primus

Der oben genannte Fehler wurde durch die Installation eines Standard Kernels, wie auch bereits von "niemand" erwähnt, behoben.

Danke euch allen beteiligten!

Gruss/Primus