summaryrefslogtreecommitdiff
path: root/document.asciidoc
diff options
context:
space:
mode:
Diffstat (limited to 'document.asciidoc')
-rw-r--r--document.asciidoc63
1 files changed, 35 insertions, 28 deletions
diff --git a/document.asciidoc b/document.asciidoc
index 2a9e28e..12a160d 100644
--- a/document.asciidoc
+++ b/document.asciidoc
@@ -196,60 +196,67 @@ werden, die ``weston-launch'' erlaubt -- nicht aber alle für Root erlaubten.
Da auf einem Computer zumeist mehr als nur ein Dienst laeuft, welcher mit einem
Netzwerk oder dem Internet verbunden ist, ist auch die Angriffsmoeglichkeit auf
dieses System sehr hoch.
-Vor Allem beim Servern, welche viele Dienste wie HTTP, FTP, SMTP, POP3 und
-viele mehr anbieten ist die Gefahr einer Sicherheitsluecke sehr hoch.
+Vor allem bei Servern, welche viele Dienste wie HTTP, FTP, SMTP, POP3 und
+viele mehr anbieten, ist die Gefahr einer Sicherheitsluecke sehr hoch.
Sollte einer dieser Dienste ueber eine Sicherheitsluecke von einem Angreifer
-uebernommen werden, so koennte diese ebenfalls die anderen Dienste und deren
+uebernommen werden, so koennte dieser ebenfalls die anderen Dienste und deren
Daten manipulieren.
-Um dieses zu vermeiden, koennen diese Dienste in kuenstlichen Umgebungen
-von einander getrennt werden.
+//TODO: künstlich? Besser virtuell?
+Um dies zu vermeiden koennen diese Dienste in kuenstlichen Umgebungen
+voneinander getrennt werden.
Eine Variante dafuer ist der System-Call +chroot(2)+.
Dieser System-Call wechselt fuer einen Prozess und dessen Kind-Prozesse das
Root-Verzeichnis.
-Somit kann ein Prozess auf Dateien ausserhalb des neuen
+Dadurch kann ein Prozess auf Dateien außerhalb des neuen
Root-Verzeichnisses nicht mehr zugreifen.
Bereits geoeffnete Dateien koennen aber weiterhin verwendet werden,
-auch wenn diese Ausserhalb des neuen Root-Verzeichnisses liegen.
+auch wenn diese außerhalb des neuen Root-Verzeichnisses liegen.
Ein Beispiel fuer die Anwendung dieser Technik ist der Apache-Http-Server,
welcher meist in das Verzeichnis +/var/www+ als Root-Verzeichnis wechselt.
-Der +chroot(2)+-System-Call ist in erster Linie aber keine Sicherheitsfunktion.
-Es gibt definierte Wege aus einem chroot wieder heraus zu wechseln.
+Der +chroot(2)+-System-Call ist jedoch in erster Linie keine
+Sicherheitsfunktion,
+da es definierte Wege gibt, ein chroot wieder zu verlassen.
-Das Konzept von ``Jails'' wie etwas im FreeBSD-Betriebssystem verwendet werden,
-sind dafuer ausgelegt verschiedene Prozesse sicher von einander zu trennen.
-Bei den ``Jails'' werden die System-Calls des eingeschlossenen Processes
+Das Konzept von ``Jails'', wie etwa im FreeBSD-Betriebssystem verwendet,
+sind dafuer ausgelegt, verschiedene Prozesse sicher voneinander zu trennen.
+Bei den ``Jails'' werden die System-Calls des eingeschlossenen Prozesses
explizit gefiltert, um die Beeinflussung von anderen Prozessen zu verhindern.
+//FIXME: Warum explizit? Werden andere Dinge implizit gefiltert?
-Um verschiedene Prozesse von einander zu trennen kann auch das
+Um verschiedene Prozesse voneinander zu trennen, kann auch die
UNIX-Rechte-Verwaltung verwendet werden.
Jeder Service sollte unter einem separaten Nutzer-Konto laufen.
-Es sollte vermieden werden mehrere Dienste mit den selben Nutzungsrechten laufen
-zu lassen, da sich diese untereinander beeinflussen koennen.
+Es sollte vermieden werden, mehrere Dienste mit den gleichen Nutzungsrechten
+auszuführen, da sich diese untereinander beeinflussen koennen.
Sollte ein Dienst keine eigenen Dateien benoetigen, kann dieser unter dem
speziellen Nutzer ``nobody'' ausgefuehrt werden.
+//FIXME: Widerspruch der letzten beiden Satze
Unter vielen Unix-Systemen wird dieser speziell fuer diese Aufgabe verwendet.
=== Beschraenkung der Erreichbarkeit
-Sollte ein Dienst nur fuer einen bestimmten Kreis von Nutzern bestimmt sein,
-dann sollte man die Erreichbarkeit des Dienstes auf diesen Kreis beschraenken.
-Systemdienste muessen nur in wenigen Faellen eine weltweite Erreichbarkeit
-haben.
+Wenn ein Dienst nur fuer einen bestimmten Kreis von Nutzern bestimmt,
+dann sollte man die Erreichbarkeit des Dienstes auf diesen Kreis beschraenken,
+denn nur für wenige Systemdienste wird eine weltweite Erreichbarkeit benötigt.
+
Ein Systemdienst, welcher mit hoeheren Rechten laeuft und global ueber
-Netzwerk erreichbar ist, ist immer eine enormes Sicherheitsrisiko fuer das
-Gesamtsystem.
+Netzwerk erreichbar ist, stellt immer eine enormes Sicherheitsrisiko fuer das
+Gesamtsystem dar.
Bevor man sich bei der Entwicklung eines Systemdienstes fuer einen bestimmten
Kommunikationsweg entscheidet, muss man sich bewusst sein, wer mit wem
kommuniziert und wo sich die Kommumikationspartner befinden.
-Kommunikation innerhalb eines Hosts sollen ueber das Loopback-Interface
+Kommunikation innerhalb eines Hosts sollte ueber das Loopback-Interface
oder UNIX-Domain-Sockets gefuehrt werden.
-Ein Dienst welcher ueber das Loopback-Interface kommuniziert, kann von jedem
-Prozess erreicht werden, welcher einen Netzwerk-Socket oeffnen kann.
-UNIX-Domain-Sockets sind an Dateien gebundene Verbindungen.
-Dadurch laesst sich ueber die systeminterne Benutzer- und Rechteverwaltung
-der Zugriff auf die Verbindung steuern.
+Ein Dienst, welcher ueber das Loopback-Interface kommuniziert, kann von jedem
+Prozess erreicht werden, der einen Netzwerk-Socket oeffnen kann.
+//FIXME: Gibt es Programme, die keinen Socket öffnen können?
+UNIX-Domain-Sockets sind an Dateien gebundene Verbindungen,
+mit den gewöhnlichen Berechtigungs-Parametern, durch die sich ueber die
+systeminterne Benutzer- und Rechteverwaltung der Zugriff auf die Verbindung
+steuern lässt.
+//FIXME: geeignet?
Wird doch eine Netzwerkkommunikation benoetigt, kann ueber die geeignet Wahl
der IP-Adresse die Erreichbarkeit kontrolliert werden.
Fuer die Kommunikation von Diensten innerhalb einer Broadcast-Domain sollen
@@ -263,7 +270,7 @@ Auch Tunnel-Techniken wie IPSec und andere VPN-Loesungen koennen verwendet
werden, um einen Dienst ausschliesslich ausgewaehlten Nutzern zugaenglich
zu machen.
-Vor allem in Windows-Systemen ist es in der Vergangenheit oft grossen Problemen
+Vor allem in Windows-Systemen ist es in der Vergangenheit oft zu großen Problemen
mit Wuermern gekommen, weil verwundbare Dienste ueber das Netzwerk erreichbar
waren.