Kapitel 13. Sicherheit

“Sandkasten” (sandbox) ist ein Ausdruck aus dem Bereich Sicherheit. Er hat zwei Bedeutungen:

• Ein Programm, das innerhalb virtueller Wände ausgeführt wird. Wenn ein Angreifer über eine Sicherheitslücke in diesen Programm einbricht, verhindern diese Wände ein tieferes Vordringen in das System.

  Man sagt: Der Prozess kann innerhalb der Wände “spielen”, das heißt nichts, was der Prozess in Bezug auf die Ausführung von Code tut, kann die Wände durchbrechen. Es ist also keine detailierte Revision des Codes erforderlich, um gewisse Aussagen über seine Sicherheit machen zu können.

  Die Wände könnten z.B. eine Benutzerkennung sein. Dies ist die Definition, die in den Hilfeseiten security(7) und named(8) benutzt wird.

  Nehmen Sie zum Beispiel den Dienst ntalk (siehe auch /etc/inetd.conf). Dieser Dienst ist früher mit der Benutzerkennung root gelaufen; nun läuft er mit der Benutzerkennung tty. Der Benutzer tty ist ein Sandkasten, der dazu gedacht ist, es jemandem, der über ntalk erfolgreich in das System eingebrochen ist, schwer zu machen, über diese Benutzerkennung hinaus vorzudringen.

• Ein Prozess, der sich innerhalb einer simulierten Maschine befindet. Dies ist etwas fortgeschrittener; grundsätzlich bedeutet es, dass jemand, der in der Lage ist, in einen Prozess einzudringen, annehmen könnte, er könnte weiter in die Maschine eindringen, tatsächlich aber nur in eine Simulation der Maschine einbricht und keine echten Daten verändert.

  Der gängigste Weg, dies zu erreichen, ist, in einem Unterverzeichnis eine simulierte Umgebung zu erstellen und den Prozess in diesem Verzeichnis mit chroot auszuführen (für diesen Prozess ist / dieses Verzeichnis und nicht das echte / des Systems).

  Eine weitere gebräuchliche Anwendung ist, ein untergeordnetes Dateisystem nur mit Leserechten zu mounten, und dann darüber eine Dateisystemebene zu erstellen, die einem Prozess einen scheinbar schreibberechtigten Blick in das Dateisystem gibt. Der Prozess mag glauben, dass er in der Lage ist, diese Dateien zu verändern, aber nur der Prozess sieht diesen Effekt - andere Prozess im System natürlich nicht.

  Es wird versucht, diese Art von Sandkasten so transparent zu gestalten, dass der Benutzer (oder Hacker) nicht merkt, dass er sich in ihm befindet.

Ein UNIX® System implementiert zwei Arten von Sandkästen - eine auf Prozessebene und die andere auf der Ebene der Benutzerkennung.

Jeder Prozess auf einem UNIX System ist komplett von allen anderen Prozessen abgeschirmt. Ein Prozess kann den Adressraum eines anderen Prozesses nicht modifizieren. Das ist anders als bei Windows®, wo ein Prozess leicht den Adressraum eines anderen überschreiben kann, was zu einem Absturz führt.

Ein Prozess gehört einer bestimmten Benutzerkennung. Falls die Benutzerkennung nicht die von root ist, dient sie dazu, den Prozess von Prozessen anderer Benutzer abzuschirmen. Die Benutzerkennung wird außerdem dazu genutzt, Daten auf der Festplatte abzuschirmen.

Die Sicherheitsstufen sind ein Sicherheitsmechanismus, der im Kernel angesiedelt ist. Wenn die Sicherheitsstufe einen positiven Wert hat, verhindert der Kernel die Ausführung bestimmter Tätigkeiten; nicht einmal der Super-User (also root) darf sie durchführen. Zurzeit können über die Sicherheitsstufen unter anderem die folgenden Tätigkeiten geblockt werden:

• Änderungen bestimmter Dateiattribute, wie zum Beispiel schg (das "system immutable" Attribut)

• Schreibender Zugriff auf die Speicherbereiche des Kernels mittels /dev/mem und /dev/kmem.

• Laden von Kernel-Modulen.

• Änderungen an den Firewall-Regeln.

Um die eingestellte Sicherheitsstufe eines aktiven Systems abzufragen, reicht das folgende einfache Kommando:

# sysctl kern.securelevel

Die Ausgaben wird den Namen der sysctl(8)-Variablen (in diesem Fall kern.securelevel) und eine Zahl enthalten. Die Zahl ist der aktuelle Wert der Sicherheitsstufe. Wenn die Zahl positiv (größer als Null) ist, sind zumindestens einige der Schutzmaßnahmen aktiviert.

Sie können die Sicherheitsstufe eines laufenden Systems nicht verringern, da dies den Mechanismus wertlos machen würden. Wenn Sie eine Tätigkeit ausführen müssen, bei der die Sicherheitsstufe nicht-positiv sein muss (z.B. ein installworld oder eine Änderung der Systemzeit), dann müssen Sie die entsprechende Einstellung in /etc/rc.conf ändern (suchen Sie nach den Variablen kern_securelevel und kern_securelevel_enable) und das System rebooten.

Weitere Informationen über die Sicherheitsstufen und genaue Informationen, was die Einstellungen bewirken, können Sie der Online-Hilfe init(8) entnehmen.

FreeBSD benutzt seit Version 3.0 eine Version von BIND, die einen Port mit einer hohen, zufälligen Nummer für den Versand von Anfragen nutzt. Wenn Sie Port 53 für abgehende Anfragen benutzen wollen, um durch eine Firewall zu kommen oder sich einfach nur besser zu fühlen, können die folgenden Zeilen in /etc/namedb/named.conf eintragen.

options {
        query-source address * port * 53;
};       

Wenn Sie möchten, können Sie statt * auch eine einzelne IP-Adresse eintragen, um die Dinge noch weiter einzuschränken.

Ach übrigens, herzlichen Glückwunsch. Es ist eine sehr gute Angewohnheit, die Ausgaben von sockstat(1) durchzusehen und auf merkwürdige Dinge zu achten.

Aktuelle Sendmail-Versionen unterstützen eine neue Technik zur Einlieferung von Mails, die Port 587 nutzt. Diese Technik wird zwar noch nicht oft angewendet, erfreut sich aber ständig steigenden Popularität,

Keine Panik. toor ist ein “alternativer” Account für den Super-User (wenn man root rückwärts schreibt, erhält man toor). Früher wurde er nur erzeugt, wenn die Shell bash(1) installiert wurde, heute wird er auf jeden Fall erzeugt. Dieser Account ist für die Verwendung mit einer alternativen Shell vorgesehen; damit ist es nicht mehr erforderlich, die Shell von root zu ändern. Dies ist wichtig, wenn eine Shell verwendet wird, die nicht zum Lieferumfang von FreeBSD gehört, zum Beispiel aus einem Port oder einem Package. Diese Shells werden in der Regel in /usr/local/bin installiert und dieses Verzeichnis liegt standardmäßig auf einem anderem Filesystem. Wenn die Shell von root in /usr/local/bin liegt und /usr (oder das Filesystem, auf dem /usr/local/bin liegt) nicht gemountet werden kann, kann sich root nicht mehr einloggen, um das Problem zu beheben. Es ist allerdings möglich, das System zu rebooten und das Problem im Single-User Modus zu lösen, da man hier gefragt wird, welche Shell benutzt werden soll.

Einige Anwender benutzen toor mit einer alternativen Shell für die tägliche Arbeit und benutzen root (mit der Standard-Shell) für den Single-User Modus und für Notfälle. Standardmäßig kann man sich nicht als toor anmelden, da der Account kein gültiges Passwort hat; Sie müssen sich also als root anmelden und ein Passwort für toor setzen, wenn Sie diesen Account benutzen wollen.

Aus Sicherheitsgründen wird suidperl standardmäßig ohne das SUID-Bit installiert. Der Systemadministrator kann das normale Verhalten mit dem folgenden Befehl herstellen:

# chmod u+s /usr/bin/suidperl

Wenn Sie wollen, dass suidperl auch beim Update via Sourcecode das SUID-Bit erhält, müssen Sie in /etc/make.conf die Zeile ENABLE_SUIDPERL=true einfügen, bevor Sie make buildworld starten.