13.1. | Was ist ein Sandkasten (sandbox)? |
| „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 detaillierte 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 inetd(8)).
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. |
13.2. | Was sind die Sicherheitsstufen? |
| 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: Zurücksetzen 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 zumindest 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. Warnung: Die Sicherheitsstufen sind kein magischer
Zauberstab, der alle Ihre Problem löst; es gibt
viele bekannte Probleme. Und in der Mehrzahl der
Fälle vermitteln sie ein falsches Gefühl der
Sicherheit. Eines der größten Probleme ist, dass
alle für den Start des Systems benötigten
Dateien geschützt sein müssen, damit die
Sicherheitsstufe effektiv sein können. Wenn es ein
Angreifer schafft, seine eigenen Programme
ausführen zu lassen, bevor die Sicherheitsstufe
gesetzt wird (was leider erst gegen Ende des
Startvorgangs erfolgen kann, da viele der notwendigen
Tätigkeiten für den Systemstart nicht mit
einer gesetzten Sicherheitsstufe möglich
wären), werden die Schutzmechanismen ausgehebelt.
Es ist zwar nicht technisch unmöglich, alle beim
Systemstart genutzten Dateien zu schützen;
allerdings würde in einem so geschützten
System die Administration zu einem Alptraum, da man das
System neu starten oder in den Single-User-Modus bringen
müsste, um eine Konfigurationsdatei
ändern zu können. Dieses und andere Probleme werden häufig auf
den Mailinglisten diskutiert, speziell auf auf der
Mailingliste FreeBSD security. Das verfügbare Archiv
enthält ausgiebige Diskussionen. Einige Benutzer
sind guter Hoffnung, dass das System der Sicherheitsstufen
bald durch ein besser konfigurierbares System ersetzt
wird, aber es gibt noch keine definitiven Aussagen. Fühlen Sie sich gewarnt. |
13.3. | Wieso wartet BIND (named ) auf hohen Ports
auf Anfragen? |
| FreeBSD benutzt eine Version von BIND, die einen Port mit einer
hohen, zufälligen Nummer für den Versand von Anfragen
nutzt. Aktuelle Versionen wählen einen neuen, zufälligen
UDP-Port für jeden Query. Das kann für manche
Netzwerkkonfigurationen Probleme verursachen, besonders wenn eine
Firewall eingehende UDP-Pakete auf bestimmten Ports blockiert.
Wenn Sie durch eine solche Firewall wollen, können Sie die
avoid-v4-udp-ports und
avoid-v6-udp-ports Optionen ausprobieren, um
ein zufälliges Auswählen von Portnummern innerhalb eines
blockierten Bereiches zu verhindern. Warnung: Wenn eine Portnummer (wie 53) über die Optionen
query-source oder
query-source-v6 in
/etc/namedb/named.conf spezifiziert ist,
wird zufällige Portauswahl nicht verwendet. Es wird
dringend empfohlen, dass diese Optionen nicht für die
Spezifikation von festen Portnummern verwendet wird. Ach übrigens, herzlichen Glückwunsch. Es
ist eine sehr gute Angewohnheit, die Ausgaben von
sockstat(1) durchzusehen und auf merkwürdige
Dinge zu achten. |
13.4. | Wieso wartet der sendmail-Dienst
neuerdings sowohl auf Port 587 als auch auf dem
Standard-Port 25 auf Anfragen? |
| 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 steigender
Popularität. |
13.5. | Woher kommt dieser Benutzer toor
mit UID 0? Ist mein System gehackt worden? |
| 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. |
13.6. | Warum funktioniert suidperl nicht
richtig? |
| Aus Sicherheitsgründen wird suidperl
standardmäßig nicht installiert. 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 perl bauen. |