Warum werden Webserver traditionell als Superuser gestartet?

Als ich über ein zukünftiges Webserver-Setup nachdachte, fiel mir auf, dass Webserver aus irgendeinem Grund normalerweise als root starten und dann bestimmte Rechte ( setuid) für die Arbeitsprozesse löschen. Darüber hinaus ist häufig chrootbeteiligt, was nicht gerade als Sicherheitsmaßnahme gedacht ist.

Was ich mich gefragt habe, warum können Webserver (ich habe alles von Apache, LightTPD bis Nginx verwaltet) das Fähigkeitssystem ( capabilities(7)) nicht verwenden , z. B. CAP_NET_BIND_SERVICEunter Linux, und einfach als Nicht-Root-Benutzer starten? ... auf diese Weise immer noch einen privilegierten Port unter 1024 abhören.

Oder besser, ich denke, die meisten von ihnen könnten es, aber warum ist das nicht üblich? Warum nicht ...

• Verwenden Sie setcap(8)mit CAP_NET_BIND_SERVICEauf der Binärdatei, die ausgeführt wird?
• Richten Sie die Protokollordner so ein, dass der (Nicht-Root-) Benutzer dort schreiben kann
• ..., wenn Sie chrootüberhaupt Hilfe benötigen, den Webserver verwenden chrootoder lxc"einsperren" möchten?

Es gibt nichts anderes als einen (Arbeiter-) Kinderprozess, der Eltern töten könnte, den ich mir einfallen lassen könnte, was dies weniger vorteilhaft machen würde, als direkt als zu beginnen root.

Warum werden sie traditionell als Root gestartet, wenn danach alles getan wird, um die damit verbundenen impliziten Sicherheitsprobleme zu beseitigen?

Obwohl POSIX einen Standard für Funktionen hat, der meiner Meinung nach CAP_NET_BIND_SERVICE enthält, sind diese für die Konformität nicht erforderlich und können in gewisser Weise mit der Implementierung unter z. B. Linux nicht kompatibel sein .

Da Webserver wie Apache nicht nur für eine Plattform geschrieben werden, ist die Verwendung von Root-Rechten die portabelste Methode. Ich nehme an, es könnte dies speziell unter Linux und BSD tun (oder wo immer Unterstützung erkannt wird), aber dies würde bedeuten, dass das Verhalten von Plattform zu Plattform usw. variieren würde.

Mir scheint, Sie könnten Ihr System so konfigurieren, dass jeder Webserver auf diese Weise verwendet werden kann. Hier gibt es einige (möglicherweise ungeschickte) Vorschläge zu diesem WRT-Apache: NonRootPortBinding .

Warum werden sie traditionell als Root gestartet, wenn danach alles getan wird, um die damit verbundenen impliziten Sicherheitsprobleme zu beseitigen?

Sie werden als Root gestartet, da sie normalerweise auf einen privilegierten Port zugreifen müssen, und dies war traditionell die einzige Möglichkeit, dies zu tun. Der Grund für das anschließende Downgrade liegt darin, dass sie später keine Berechtigungen benötigen und das Schadenspotential begrenzen, das durch die Vielzahl von Add-On-Software von Drittanbietern entsteht, die üblicherweise vom Server verwendet werden.

Dies ist nicht unangemessen, da die privilegierte Aktivität sehr begrenzt ist und gemäß der Konvention viele andere Systemdämonen kontinuierlich Root ausführen, einschließlich anderer Inet-Dämonen (z sshd. B. ).

Beachten Sie, dass, wenn der Server so gepackt wäre, dass er als nicht privilegierter Benutzer mit CAP_NET_BIND_SERVICE ausgeführt werden könnte, jeder nicht privilegierte Benutzer den HTTP (S) -Dienst starten könnte, was möglicherweise ein größeres Risiko darstellt.

Auf Unix-basierten Systemen erfordern Dienste, die privilegierte Ports überwachen, den Segen des Systemadministrators. Dies zeigt an, dass der Dienst von einem vertrauenswürdigen Benutzer (zumindest vom Administrator) ausgeführt wird. Benutzer solcher Dienste können dann darauf vertrauen, dass die Serveranwendung administrativ überwacht wird. Der Wert dieses Vertrauens ist möglicherweise nicht so hoch wie in den vergangenen Jahrzehnten.

Viele Webserver werden auf älteren Betriebssystemkernen ausgeführt, die möglicherweise nicht die Funktionen unterstützen, die erforderlich sind, damit sie als nicht privilegierter Benutzer gestartet und ausgeführt werden können. Die erforderlichen Kerneländerungen sind relativ neu und nicht für alle Betriebssystemkerne standardisiert. Es ist möglich, die Software für solche Umgebungen bedingt zu kompilieren. Solche Änderungen konnten jedoch auf den meisten Plattformen nicht verwendet werden und sind möglicherweise nicht gut getestet oder so sicher wie gewünscht.

Es ist üblich, dass Daemon-Prozesse als Root ausgeführt werden, um alles zu tun, was Root-Zugriff erfordert, und dann zu einer nicht privilegierten UID zu wechseln. Auf diese Weise können Ressourcen gesichert werden, während verhindert wird, dass das Programm nach seiner Ausführung großen Schaden anrichtet. Im Falle eines Webservers sollten SSL-Schlüssel vor dem Lesen durch eine Rouge-Server-Anwendung geschützt werden, müssen jedoch gelesen werden, um den SSL-Listener zu konfigurieren. Geteilte Berechtigungen ermöglichen den geteilten Zugriff auf Ressourcen, mit denen die Sicherheit erheblich erhöht werden kann.

Während es möglich ist, einen Webserver ins Gefängnis zu bringen, kann das Gefängnis auf vielen Systemen erhebliche Teile des Dateisystems enthalten. Dies kann sowohl schwierig zu konfigurieren als auch fehleranfällig sein. Das Jailing einer Anwendung bedeutet im Allgemeinen, dass es sich um eine sicherere Konfiguration handelt. In diesem Fall kann diese Vertrauensstellung aufgrund des Risikos, dass das Gefängnis falsch konfiguriert ist, fehl am Platz sein. Auch ohne Gefängnis kann es schwierig sein, Zugangsprobleme zu diagnostizieren. Wenn große Teile des Dateisystems aus dem Gefängnis ausgeschlossen werden, wird dies schwieriger.

Es gibt mehrere Gründe, einen Webserver als Root zu starten:

• zum Binden an Port 80 (Ports unter 1024 sind für root reserviert, sodass ein Remotebenutzer, der eine Verbindung zu einem Dienst an einem niedrigen Port herstellt, weiß, dass dieser Dienst von root genehmigt wurde);
• eine Beschränkung einzurichten, zB Chroot;
• gegebenenfalls zum Lesen und Bereitstellen der Webseiten der Benutzer.

Der geringste Grund ist ein schlechtes Setup. Der einfachste Weg, um ein solches Setup zu sichern, besteht darin, dass Benutzer Webseiten öffentlich machen müssen. Dies funktioniert nicht, wenn Benutzer private Webseiten mit Zugriffskontrolle haben möchten (z. B. eine Universitätsmaschine, auf der Professoren Prüfungstexte über das Internet austauschen möchten, die Studenten sie jedoch nicht sehen lassen möchten). In diesem Fall ist ein komplexerer Ansatz erforderlich (z. B. müssen Webseiten über eine ACL verfügen, mit der der Webserver sie lesen kann).

Webserver, die als Root gestartet werden, werden häufig nur als Root gestartet, geben dann jedoch Berechtigungen an einen dedizierten Benutzer weiter. Bevor sie Berechtigungen löschen, binden sie Port 80, lesen möglicherweise einige Dateien (z. B. private SSL-Schlüsseldateien) und führen möglicherweise eine andere Eindämmung durch.

[Warum nicht] setcap(8)mit CAP_NET_BIND_SERVICEauf der Binärdatei verwenden, die ausgeführt wird?

Dies ist möglich, erfordert jedoch ein System, das Funktionen unterstützt. Im Vergleich zur Geschichte von Unix und sogar zu Webservern ist dies relativ neu.

[Warum nicht] die Protokollordner so einrichten, dass der (Nicht-Root-) Benutzer dort schreiben kann?

Das wird normalerweise gemacht; Andernfalls protokolliert der Webserverprozess über einen Unix- oder Internet-Socket bei einem Protokollierungsdämon.

[Warum nicht] Wenn Sie der Meinung sind, dass chroot überhaupt hilft, verwenden Sie chroot oder lxc, um den Webserver "einzusperren"?

Dies bedeutet, dass der Webserver alle Konfigurationsdateien lesen kann, z. B. private SSL-Schlüssel. Manchmal können Angreifer durch Sicherheitslücken beliebige Dateien abrufen. Wenn Sie den Server so einschränken, dass er nicht auf Konfigurationsdateien zugreifen kann, wird in diesem Fall eine Gefährdung vermieden.

Es ist eine Schwäche der meisten Unix-Systeme, dass sie einem nicht privilegierten Prozess nicht erlauben, einen Einschlussbereich einzurichten, aus dem er nicht ausbrechen kann. Unter Linux ist dies möglich, da die Namespace-Verbesserungen in Kernel 3.8 noch nicht weit verbreitet sind.