Apache Server lässt sich nicht mehr starten, Ratschläge?

[Ellie224]

Ich hab folgendes Problem: Hab eine Website, die ich bei einem Hoster gemietet habe. Und bisher, -also die letzten 1,5 Jahre- hatte ich damit auch keine Probleme. Leider gibt es nun seit ein paar Tagen ein ungeklärtes Problem mit dem Apache Server (der sich partout nicht mehr starten lässt). Die Fehlermeldung:

Starting The Apache HTTP Server...

apache2.service: Failed to set up mount namespacing: Permission denied

apache2.service: Failed at step NAMESPACE spawning /usr/sbin/apachectl: Permission denied

apache2.service: Control process exited, code=exited, status=226/NAMESPACE

apache2.service: Failed with result 'exit-code'.

Failed to start The Apache HTTP Server.

apache2.service: Consumed 2ms CPU time.

Ich habe nichts am System verändert oder installiert und bis vor ca. 1 Woche lief alles einwandfrei. Das System läuft in einem lxc Linux Container mit Debian und anscheinend soll ein restriktives apparmor Profil im Kernel, welches das Hochfahren des Apache Servers blockiert die wahrscheinliche Ursache sein, es könnte aber auch etwas völlig Anderes sein. Die Fehlermeldung wenn ich versuche den Log auszugeben:

 kernel: [xxxxx.xxxxx] audit: type=1400 audit(xxxxx.xxx:xxxxxx): apparmor="DENIED" operation="mount" class="mount" info="failed perms check" error=-13 profile="lxc-xxxxxx_</var/lib/lxc>" name="/run/systemd/unit-root/" pid=xxxxxx comm="(d-logind)" srcname="/" flags="rw, rbind" (Zahlen und ID's durch xxx ersetzt)

Leider bin ich auf dem Gebiet kein Experte bzw. tappe da relativ weit im dunkeln. Die von meinem Hosting-Support wissen leider ebenfalls keine klare Lösung...

Irgendeine Idee was dahinter stecken könnte und wie man dieses Problem beheben kann?

 

[nebulein]

Nesting im LXC Container aktivieren.

 

[CoMo]

features: nesting=1

 

[Ellie224]

Das macht was genau, bzw. wo aktivier ich das?

 

[redjack1000]

In den Einstellungen des LXC Container.

Cu
redjack

 

[Uridium]

Ich würde es ohne Nesting machen.
https://forum.proxmox.com/threads/a...mespacing-permission-denied.56871/post-280885

 

[CoMo]

Warum? Nesting aktivieren ist die saubere Lösung, damit Apache selbst Namespaces spawnen darf, nämlich für ein eigenes /tmp. Und Nesting ist seit Proxmox 7.1 standardmäßig für neue unprivilegierte Container aktiviert, um Kompatibilität mit genau solchen Systemd-Features zu gewährleisten.

Kannst du bitte ausführen, warum du stattdessen die Systemd Unit bearbeiten und Sicherheitsfeatures deaktivieren möchtest?

 

[Uridium]

Weil der Container bereits in einem eigenen Namespace läuft. Dem Container selbst die Kontrolle darüber zu geben stellt ein unnötiges (und vor allem viel größeres) Sicherheitsrisiko dar (als das, was Du da aufzählst).

# Uncomment the following line to support nesting containers:
#lxc.include = /usr/share/lxc/config/nesting.conf
# (Be aware this has security implications)
https://github.com/lxc/lxc/blob/48b...60b1313364544b1c/src/lxc/lxccontainer.c#L1693
https://github.com/lxc/lxc/blob/main/config/apparmor/profiles/lxc-default-with-nesting

 

[CoMo]

Das Namespacing dient dazu, den Prozess innerhalb des Containers von anderen Prozessen abzuschirmen. So ist der Standard, so wird das Paket Upstream verteilt. Damit solche Systemd-Features funktionieren, gibt es Nesting.

Klar kann man da dran rumfummeln und alles irgendwie anders machen. Man kann es aber auch einfach so machen, wie es vorgesehen ist.

Das alles natürlich unter der Vorgabe, dass wir hier von einem unprivilegierten Container sprechen. Bisher hat der TE keinerlei Infos über den Hoster und das Hostsystem mit uns geteilt.

 

[Uridium]

So ist der Standard, so wird das Paket Upstream verteilt. Damit solche Systemd-Features funktionieren, gibt es Nesting.

Standard ist da gar nichts, das ist ja das Problem. Es gibt mittlerweile so viele "Sandboxes" (systemd-nspawn, lxc, firejail, bubblewrap, runC, docker, flatpak, etc), dass die sich irgendwann gegenseitig in die Quere kommen (sandbox stacking). Und dann werden Abstriche in der Sicherheit gemacht, damit es überhaupt funktioniert, was das ganze Sicherheitskonzept in Frage stellt. In einer idealen Welt gäbe es genau eine Sandbox (die oberste) und die darunterliegenden schalten sich ab. Das einzige Programm, das ich kenne, das sowas macht, ist Wine.

Das alles natürlich unter der Vorgabe, dass wir hier von einem unpriviligierten Container sprechen.

Ob es sich dabei (technisch) noch um einen unprivilegierten Container handelt, wenn man ihm die Macht über seccomp und cgroups gibt, ist diskussionsbedürftig.

Wenn man sich nicht anders zu helfen weiß, kann man Nesting gerne verwenden. Alle anderen wissen, warum sie das (wenn möglich) vermeiden wollen. Letztlich ist es auch nicht immer möglich. In diesem Fall ist es ja noch recht simpel, bei größeren Projekten kann der Aufwand aber komplett unverhältnismäßig (oder unmöglich) sein. Firefox, bzw. sämtliche auf 'xdg-desktop-portal' (z.B. GTK-) basierende Filepicker ("Datei Speichern" Fenster) sind derzeit solche Problemfälle, weil da jetzt standardmäßig bubblewrap drin steckt.

Ontopic:
Ich würde dem Threadersteller letztlich auch empfehlen Nesting einzuschalten, wenn er nicht weiß, worum es hier genau geht. Eingeschaltet wird es bei 'native LXC' in der Container-spezifischen 'config' Datei oberhalb des Container-Rootverzeichnisses. Diese Ordner können, je nach Distribution, woanders liegen. Bei Arch z.B. liegen die Container in '/srv/lxc/'.

 

[Ellie224]

Leider versteh ich noch immer nicht ganz genau was dieses Nesting ist / macht. Aber konnte jetzt zumindest das Problem mit den Start lösen indem ich: "sed -i -e 's,PrivateTmp=true,PrivateTmp=false\nNoNewPrivileges=yes,g' /lib/systemd/system/apache2.service" ausgeführt und danach den Daemon und Apache neu gestartet habe. War das jetzt so korrekt bzw. die empfohlene Vorgehensweise ?

 

[CoMo]

Nein. Die empfohlene Vorgehensweise ist, die Systemd Unit so zu lassen, wie sie ist und stattdessen Nesting zu aktivieren. Und wenn man sie bearbeitet, dann auf keinen Fall so wie du das gemacht hast, sondern via Drop-In-Override. So fliegt dir das bei jedem Update um die Ohren.

Leider versteh ich noch immer nicht ganz genau was dieses Nesting ist / macht.

Es gibt Schreibrechte auf /proc und /sys, damit der Container eigene Namespaces spawnen kann. Das möchte er, weil PrivateTmp=true.

 

[Uridium]

Leider versteh ich noch immer nicht ganz genau was dieses Nesting ist / macht.

Dein Container ist ein metaphorischer "Sandkasten" (Sandbox) mit unüberwindbaren Grenzen, die Messer, Gabel, Schere, Licht unerreichbar machen (sollen). Jetzt wollen die Insassen aber auch einen Sandkasten innerhalb des Sandkasten errichten (Verschachteln=Nesting), bemerken aber, dass sie das ohne die Werkzeuge außerhalb des Sandkasten nicht können und stellen beleidigt den Dienst ein (Error).
Jetzt gibt es zwei Möglichkeiten. Entweder gibt man ihnen die Macht über die Sandkästen (sowie das Potenzial den eigenen Sandkasten missbräuchlich zu manipulieren und verlassen zu können) oder man verwehrt ihnen den Zugriff auf die Werkzeuge und überzeugt sie stattdessen auf den Bau zu verzichten.

sondern via Drop-In-Override. So fliegt dir das bei jedem Update um die Ohren.

+1

 

[CoMo]

sowie das Potenzial den eigenen Sandkasten missbräuchlich zu manipulieren und verlassen zu können

Was im Falle eines unprivilegierten LXC-Containers vernachlässigbar ist, denn root im container ist nicht root auf dem Hostsystem, sondern ein normaler Benutzer mit minimalen Rechten.

 

[Uridium]

Unter der Haube passiert bei Nesting einiges mehr als diese vereinfachte Betrachtungsweise zu suggerieren vermag (context switching, pointer, buffer exploits). Ich will es nicht zu hoch hängen, die Sicherheitswarnung in LXC ist aber auch nicht unbegründet.

Nested virtualization is not supported by most cloud providers. There are security concerns with implementing nested virtualization as it enlarges the code base of host hypervisors, which expands the attack surface due to known security bugs.
https://research.ibm.com/blog/nested-virtualization-free-turtles

 

[CoMo]

Hinter dem Link geht es um Nested Virtualization, also das Durchreichen von Hardware-Virtualisierungs-Features der CPU an Gäste, sprich den direkten Zugriff von VMs durch den Hypervisor auf die physische Hardware.

Können wir aufhören, hier alles durcheinander zu werfen? Das hat mit LXC-Nesting nichts zu tun.

 

[Uridium]

Das spielt keine Rolle. Ich rede von Kernel Exploits.
https://discussion.fedoraproject.org/t/are-nested-namespaces-a-security-concern/147945/3