[linux-l] Einige Fragen zu GRsecurity...

Peter Ross Peter.Ross at alumni.tu-berlin.de
Mi Jan 21 02:20:02 CET 2004


On Mon, 19 Jan 2004, Oliver Beck wrote:

> Ist hier überhaupt jemand, der sich in Sachen ACL's (mit welcher Methode
> auch immer) auskennt/beschäftigt?

Ich;-)

Angefangen hat alles mit einem Studentenpool an der Uni mit Windows 3.11,
an dem jeder alles installieren konnte und dies auch geschah. Das hat mich
bewogen, Windows NT 3.51 einzusetzen. Da konnte man "out of the box" auch
noch alles installieren, also musste ich kreaftig an den Policies und ACLs
rumschrauben, habe gesehen, wie maechtig das sein kann, wie kompliziert
aber auch und das man sich damit gut ins Knie schiessen kann.

Da habe ich das gute rwxrwxrwx zu schaetzen gelernt;-) Mein neugieriges
Rumspielen mit Slowlaris-ACLs war relativ folgenlos, nur Spass.

Uebrigens, ich weiss wohl, dass Windows-ACLs nicht denen von GRSecurity
entsprechen;-) Aber ein Grundsatz-Problem ist das Gleiche: hoehere
Komplexitaet. Standard-Unix-Sicherheit ueber Filerechte hat pro File
_einen_ Nutzer, _eine_ Gruppe und _einen_ Satz an Rechten fuer den Rest
der Welt. SUID und SGID verkonplizieren das noch etwas..

Mit ACLs kann man halt fuer jedes File mengentechnisch eine wesentlich
hoehere Anzahl von Regeln haben, der Regelraum ist teilweise substraktiv
(gilt fuer alle Nutzer, Gruppen, Files.. AUSSER fuer ..)

Du merkst schon in Deinem simplen Beispiel, wie schnell man sich mit ACLs
ins Knie schiessen kann. Vorallem das sehe ich als echten Nachteil. Jede
Methode ist nur so gut, wie sie der Admin beherrscht, und manche Sachen
sind schon recht unangenehm komplex..

Es bedarf desweiteren einer gewissen Erfahrung und Reife in der Nutzung
von Sicherheitsrichtlinien auf Fileebene. Das rwxrwxrwx-Modell hat schon
einige Jahre auf dem Buckel. So ganz simpel ist es ja auch nicht. Man
denke z.B. an den Zugriff auf die Dateien in /var/mail, /tmp, Stickybits
etc. Inzwischen kann man so einigermassen Vertrauen haben, dass es
einigermassen auch von den Programmierern beherrscht wird (auch wenn man
immer mal wieder Sicherheitsloecher in der Art von Editoren findet, die
Tempdateien mit der umask anlegen, obwohl die Ursprungsdatei halt 600
hatte, und so Spionieren ermoeglichen). Zu Zeiten von WinNT 3.51, s.oben,
gab es unter Windows-Programmierern dahingehend gar keine Erfahrungen,
dementsprechend schwierig war es, ein System "abzudichten". Inzwischen ist
es doch selbst da etwas besser geworden.

In den letzten zwei Jahren (bis vor einem halben Jahr) habe ich mich nun
mit Linux-Sicherheit beschaeftigt ..oder eher muessen, ich habe erst durch
erzwungene Nutzung von Linux richtig begriffen, wie gut meine von Freunden
mit inspirierte Wahl von FreeBSD als freies Betriebssystem vorher war..
Ich durfte Webhosting aufsetzen und mich durch den Wust an Linux-Projekten
durchwuehlen, um evt. eine Sicherheit zu erreichen, die ein ungepatchtes
FreeBSD so mitbringt.

Es ist also eine ziemliche Sysiphusarbeit, einem komplexen System
ordentliche Standardeinstellungen zu verpassen. Wie es scheint, hat SE
Linux es immerhin zu einer gewissen Reife gebracht, so dass Russell Coker
sich sicher ist, dass "Standard-root" nur die Passwortdateien schreiben
kann, alles andere sei tabu. Immerhin ist es erst einige Monate her, dass
er eine Maschine zum Austesten von SE Linux ins Netz gestellt hat, in der
Standard-root /dev/kmem schreiben konnte. Es braucht eben Zeit, um solche
Loecher zu entdecken.

Wie es ausschaut, graebst Du Dich auch gerade durch
Linux-Sicherheits-Aspekte durch? Wie waere es mal mit einer
Kurzaufstellung, dann koennte man das vielleicht gemeinsam machen?

Wuerde mir (und wahrscheinlich auch anderen) auch helfen, den Wust mal zu
ordnen. Eines der Probleme im Bereich Linux ist fuer mich, dass es etwas
wildwuechsig ist.

Einige der angeschauten Projekte muss ich auch mal wieder auffrischen. Ich
habe erst z.B. ein vor einem Jahr angeschautes Projekt, FreeBSD-jail(2)
nachzubauen, gesucht, kann es aber nicht mehr finden. In guter
Linux-Manier sah das Konzept gleich eine Verbesserung vor - FreeBSD-jail
bindet eine IP an und hat eine Wurzel, bei dem Linux-"jail" (es hiess
anders) sollte das durch zwei Rufe getrennt sein.

(Uebrigens, FreeBSD-jail(2) ist quasi ein gehaertetes chroot(2) in einem
Standardkernel seit nun schon mehreren Jahren, mit, nach Angaben der
Entwickler, nur 300 Zeilen Aenderungen eingefuehrt, simpel die
Prozessstruktur um eine Jail-ID erweitert und die bei Systemrufen
abgetestet, klingt mir wesentlich robuster als grsecurity-Nachflicken von
chroot(2)..)

Gruss
Peter




Mehr Informationen über die Mailingliste linux-l