Der Entwickler von SELinux hat sehr wohl recht. Alle Sicherheitserweiterungen für Linux sind als zusätzliche Hürden gedacht und kein Entwickler einer dieser Erweiterungen wird 100%igen Schutz versprechen. Außerdem ist die Konfiguration sowohl von Apache als auch SELinux nicht simpel und braucht dadurch einiges an Erfahrung.
Von InsGesichtDamit am Fr, 3. August 2012 um 19:39 #
100% nicht, aber der Mehrgewinn hält sich in Grenzen. Ein Framework was kompliziert richtig zu konfigurieren ist, bietet nur trügerisch mehr Sicherheit. Und darum gehts, Augenwischerei.
Das Framework ist nur in wenigen Teilen "kompliziert". Zu 95% verstehen die Benutzer schlichtweg nicht das Design von SELinux. Welches aber nicht der Komplexität geschuldet ist, sondern eher dem Fehlen an gut übersetzten und knackigen Tutorials und auch der Benutzer selbst muß sich im Klaren sein, daß Security Frameworks kein Kinderspielzeug sind und einiges an Wissen erfordern.
Mit SELinux lassen sich diverse Sachen sogar sehr gut abschotten bzw. absichern. Für "sehr effektive" Regeln muß ich aber natürlich auch über entsprechendes Fachwissen verfügen.
Genauso wie bei einer Firewall auch. Ohne Wissen über TCP, UDP, ICMP, VPN, NAT, PAT brauche ich erst gar nicht anfangen eine richtige Firewall zu konfigurieren.
Die wirklich trügerische Sicherheit existiert nur dort, wo man dem Benutzer vorgauckelt, er könne mit 2 Mausklicks eine gute Konfiguration erhalten, ohne auch nur die geringste Ahnung über die Basics zu haben.
Scheinbar wurde der komplette Test ohne Wissen über SELinux bzw. den typischen und sinnvollen Zugriffsrechten eines Webservers durchgeführt.
Scheinbar wurde der komplette Test ohne Wissen über SELinux bzw. den typischen und sinnvollen Zugriffsrechten eines Webservers durchgeführt.
Das glaube ich nicht. Ich denke die wissen sehr genau wie Linux, Apache und SELinux arbeiten. Die wollen aber auch Ihre Studie verkaufen und die verkauft sich halt sehr viel besser, wenn man irgendein "Problem" gefunden hat. Stell Dir vor im Blog steht "Alles gut, wie erwartet.", wer kauft dann noch die Studie dazu.
Das kann ich dem Artikel nicht entnehmen. Ich würde das sogar stark bezweifeln, denn dann hätten die sicher nicht CentOS sondern das "original" RHEL getestet.
Die wirklich trügerische Sicherheit existiert nur dort, wo man dem Benutzer vorgauckelt, er könne mit 2 Mausklicks eine gute Konfiguration erhalten, ohne auch nur die geringste Ahnung über die Basics zu haben.
Genau das muss allerdings das Ziel sein. Also nicht die trügerische Sicherheit, sondern ein System so gut wie möglich absichern ohne sich eben viel Hintergrundwissen zu erarbeiten. Ob nun mit 2 Mausklicks oder mit 20 spielt zunächst einmal keine Rolle, dennoch muss man versuchen so etwas zu ermöglichen.
Natürlich ist das anspruchsvoll, aber dennoch erstrebenswert.
Selinux schützt Contexte vor einander, aber nicht innerhalb eines Contextes. Wenn der Webserver eine Datei lesen kann und der Angreifer eine Schwachstelle im Webserver findet, dann kann er natürlich auch die Datei lesen. Er kann aber keine Datei außerhalb dieses Contextes lesen.
Beispielsweise um Benutzerverzeichnisse herauszufinden. Oder wo sind die sonst gespeichert?
Allein schon wegen Plugins wie mod_userdir, etc...
Die Datei /etc/passwd wird von sehr sehr vielen Programmen benötigt und gelesen, daher ist sie auch von allen lesbar. Dies sollte sich eigentlich schon seit langem herumgesprochen haben. Nicht umsonst werden die heiklen Infos seit ca. 2 Jahrzehnten in /etc/shadow gespeichert.
Von InsGesichtDamit am Fr, 3. August 2012 um 21:47 #
Ist mir noch nicht untergekommen, nicht nur dass das ein ziemlich dämlicher Gedanke ist. Was haben denn lokale Benutzer mit Auth. im Web gemein? Sicher geht das irgendwie, ist aber nicht der Standard, wird nicht empfohlen, generell eine unschöne Lösung.
mod_userdir existiert. Es ist Sache des Admins, ob er das einsetzen will, aber wenn er es tut, benötigt es auch Zugriff auf /etc/passwd, um überhaupt feststellen zu können, welche Verzeichnisse denn per http://example.com/~myuser freizugeben sind.
Wenn man das nicht braucht, schaltet man es auch nicht ein. Alternativ kann man ausgewählten Benutzern auch einen VirtualHost der Art http://myuser.example.com einrichten. Das hat dazu noch den Vorteil, dass die DocumentRoot / ist - kann man z.B. nutzen, um auf demselben Rechner die aktuelle Entwicklerversion der Webseite zum Testen vorzuhalten.
> Ist mir noch nicht untergekommen, nicht nur dass das ein ziemlich dämlicher Gedanke ist.
Dies Funktion wird von tausenden Hostern eingesetzt. Natürlich stützen sich viele davon nicht auf die /etc/passwd sondern auf einen zentralen Dienst. Wofür aber Apache trotzdem die Rechte benötigt um an die Infos zu kommen. Außerdem geht es meist nicht um die Authentifizierung, sondern schlicht um das Homeverzeichnis eines Benutzers.
> Sicher geht das irgendwie, ist aber nicht der Standard, wird nicht empfohlen, generell eine unschöne Lösung.
Wie kommst du darauf? Wodurch wird diese Aussage begründet?
Ich möchte dir dringenst raten einen Blick in die Apache Doku (bzw. auch andere Webserver Dokus) zu werfen. Außerdem können ein paar Zeilen zu MAC bzw. RBAC auch ganz hilfreich sein, bevor man hier in mehreren Kommentaren seine Meinung zu diesem Thema bekundet.
In nahezu jedem Fall, da dort u.a. Informationen zum Apache-Benutzer stehen. Wenn Du das umgehen willst, dann musst Du nss_files aus nsswitch rausnehmen.
Langweilig!. Was sind das für Sicherheitsexperten... Wenn die keine Ahnung haben, sollten die so eie Quatsch einfach nicht schreiben und Prolinux muss auch noch jeden Quark rausbringen.
Der Beitrag ist aber sehr allgemein gehalten, der Link verweist auf eine Seite mit kyrillischer Schrift.... Ich kann hier wenig qualitativen Inhalt entnehmen. Es wäre schon, wenn der Autor ein paar Erläuterungen zu der Testumgebung gegeben hätte. Z.B. war. mod_security aktiviert ?
Der Autor des Blogs hat SELinux nicht verstanden. Ich gehe sogar davon aus, daß er Autor nur mangelhaftes Verständnis von "Mandatory Access Control" bzw. "Role Based Access Control" hat.
Sonst hätte er diese Test erst gar nicht durchgeführt. Er hätte genausogut schreiben können, daß iptables in einer Standardkonfiguration für Webhosting seine Angriffe auf den Webserver nicht unterbunden hat.
Es gibt diverse Security Plugins/Frameworks/Einstellungen für Apache, PHP und Perl welche dem Autor sicher mehr gebracht hätten.
Du weißt, welche Accounts es auf dem Rechner gibt und welche davon Shellzugriff haben, bei welchen sich also Bruteforcen lohnt. Evtl. kannst du die Accountnamen sogar mit einer Liste abgleichen und gucken, ob du jemanden findest, der überall dasselbe Kennwort nutzt.
In diesem Zusammenhang: Kennwortbasierte SSH-Logins abschalten! Keys-basierte Logins sind sichere *und* bequemer, wenn man sie erst einmal eingrichtet hat.
Klingt für mich so als ob die Versprechen die Red Hat seinen Kunden gibt, nur Marketing Gewäsch sind.
Der Entwickler von SELinux hat sehr wohl recht. Alle Sicherheitserweiterungen für Linux sind als zusätzliche Hürden gedacht und kein Entwickler einer dieser Erweiterungen wird 100%igen Schutz versprechen. Außerdem ist die Konfiguration sowohl von Apache als auch SELinux nicht simpel und braucht dadurch einiges an Erfahrung.
100% nicht, aber der Mehrgewinn hält sich in Grenzen. Ein Framework was kompliziert richtig zu konfigurieren ist, bietet nur trügerisch mehr Sicherheit. Und darum gehts, Augenwischerei.
Das Framework ist nur in wenigen Teilen "kompliziert". Zu 95% verstehen die Benutzer schlichtweg nicht das Design von SELinux. Welches aber nicht der Komplexität geschuldet ist, sondern eher dem Fehlen an gut übersetzten und knackigen Tutorials und auch der Benutzer selbst muß sich im Klaren sein, daß Security Frameworks kein Kinderspielzeug sind und einiges an Wissen erfordern.
Mit SELinux lassen sich diverse Sachen sogar sehr gut abschotten bzw. absichern. Für "sehr effektive" Regeln muß ich aber natürlich auch über entsprechendes Fachwissen verfügen.
Genauso wie bei einer Firewall auch. Ohne Wissen über TCP, UDP, ICMP, VPN, NAT, PAT brauche ich erst gar nicht anfangen eine richtige Firewall zu konfigurieren.
Die wirklich trügerische Sicherheit existiert nur dort, wo man dem Benutzer vorgauckelt, er könne mit 2 Mausklicks eine gute Konfiguration erhalten, ohne auch nur die geringste Ahnung über die Basics zu haben.
Scheinbar wurde der komplette Test ohne Wissen über SELinux bzw. den typischen und sinnvollen Zugriffsrechten eines Webservers durchgeführt.
Grüße,
unreal
Das glaube ich nicht. Ich denke die wissen sehr genau wie Linux, Apache und SELinux arbeiten. Die wollen aber auch Ihre Studie verkaufen und die verkauft sich halt sehr viel besser, wenn man irgendein "Problem" gefunden hat. Stell Dir vor im Blog steht "Alles gut, wie erwartet.", wer kauft dann noch die Studie dazu.
Habe einige andere Blogeinträge des Autors gelesen: Du hast recht.
Das kann ich dem Artikel nicht entnehmen. Ich würde das sogar stark bezweifeln, denn dann hätten die sicher nicht CentOS sondern das "original" RHEL getestet.
Natürlich ist das anspruchsvoll, aber dennoch erstrebenswert.
Deshalb gibt es bei SELinux viele vorkonfigurierte Policies, welche mittels Parameter zur Laufzeit konfiguriert werden können.
Aber wie so oft: Es sind natürlich auch hier Verbesserungen möglich und erwünscht.
Selinux schützt Contexte vor einander, aber nicht innerhalb eines Contextes.
Wenn der Webserver eine Datei lesen kann und der Angreifer eine Schwachstelle im Webserver findet, dann kann er natürlich auch die Datei lesen.
Er kann aber keine Datei außerhalb dieses Contextes lesen.
Vereinfacht gesagt.
Das liest sich aber ganz anders. In welchem Kontext muss denn Apache die /etc/passwd lesend zu greifen?
Beispielsweise um Benutzerverzeichnisse herauszufinden. Oder wo sind die sonst gespeichert?
Allein schon wegen Plugins wie mod_userdir, etc...
Die Datei /etc/passwd wird von sehr sehr vielen Programmen benötigt und gelesen, daher ist sie auch von allen lesbar. Dies sollte sich eigentlich schon seit langem herumgesprochen haben. Nicht umsonst werden die heiklen Infos seit ca. 2 Jahrzehnten in /etc/shadow gespeichert.
Gruß,
unreal
Ist mir noch nicht untergekommen, nicht nur dass das ein ziemlich dämlicher Gedanke ist. Was haben denn lokale Benutzer mit Auth. im Web gemein? Sicher geht das irgendwie, ist aber nicht der Standard, wird nicht empfohlen, generell eine unschöne Lösung.
mod_userdir existiert. Es ist Sache des Admins, ob er das einsetzen will, aber wenn er es tut, benötigt es auch Zugriff auf /etc/passwd, um überhaupt feststellen zu können, welche Verzeichnisse denn per http://example.com/~myuser freizugeben sind.
Wenn man das nicht braucht, schaltet man es auch nicht ein. Alternativ kann man ausgewählten Benutzern auch einen VirtualHost der Art http://myuser.example.com einrichten. Das hat dazu noch den Vorteil, dass die DocumentRoot / ist - kann man z.B. nutzen, um auf demselben Rechner die aktuelle Entwicklerversion der Webseite zum Testen vorzuhalten.
> Ist mir noch nicht untergekommen, nicht nur dass das ein ziemlich dämlicher Gedanke ist.
Dies Funktion wird von tausenden Hostern eingesetzt. Natürlich stützen sich viele davon nicht auf die /etc/passwd sondern auf einen zentralen Dienst. Wofür aber Apache trotzdem die Rechte benötigt um an die Infos zu kommen.
Außerdem geht es meist nicht um die Authentifizierung, sondern schlicht um das Homeverzeichnis eines Benutzers.
> Sicher geht das irgendwie, ist aber nicht der Standard, wird nicht empfohlen, generell eine unschöne Lösung.
Wie kommst du darauf?
Wodurch wird diese Aussage begründet?
Ich möchte dir dringenst raten einen Blick in die Apache Doku (bzw. auch andere Webserver Dokus) zu werfen. Außerdem können ein paar Zeilen zu MAC bzw. RBAC auch ganz hilfreich sein, bevor man hier in mehreren Kommentaren seine Meinung zu diesem Thema bekundet.
In nahezu jedem Fall, da dort u.a. Informationen zum Apache-Benutzer stehen. Wenn Du das umgehen willst, dann musst Du nss_files aus nsswitch rausnehmen.
Langweilig!. Was sind das für Sicherheitsexperten... Wenn die keine Ahnung haben, sollten die so eie Quatsch einfach nicht schreiben und Prolinux muss auch noch jeden Quark rausbringen.
Der Beitrag ist aber sehr allgemein gehalten, der Link verweist auf eine Seite mit kyrillischer Schrift....
Ich kann hier wenig qualitativen Inhalt entnehmen.
Es wäre schon, wenn der Autor ein paar Erläuterungen zu der Testumgebung gegeben hätte.
Z.B. war. mod_security aktiviert ?
Der Autor des Blogs hat SELinux nicht verstanden. Ich gehe sogar davon aus, daß er Autor nur mangelhaftes Verständnis von "Mandatory Access Control" bzw. "Role Based Access Control" hat.
Sonst hätte er diese Test erst gar nicht durchgeführt. Er hätte genausogut schreiben können, daß iptables in einer Standardkonfiguration für Webhosting seine Angriffe auf den Webserver nicht unterbunden hat.
Es gibt diverse Security Plugins/Frameworks/Einstellungen für Apache, PHP und Perl welche dem Autor sicher mehr gebracht hätten.
Grüße,
unreal
Was nützt einem eigentlich die passwd Datei? Wenn er /etc/shadow hätte lesen können, wär´s doch interessanter gewesen.
Du weißt, welche Accounts es auf dem Rechner gibt und welche davon Shellzugriff haben, bei welchen sich also Bruteforcen lohnt. Evtl. kannst du die Accountnamen sogar mit einer Liste abgleichen und gucken, ob du jemanden findest, der überall dasselbe Kennwort nutzt.
In diesem Zusammenhang: Kennwortbasierte SSH-Logins abschalten! Keys-basierte Logins sind sichere *und* bequemer, wenn man sie erst einmal eingrichtet hat.
Zumindest sollte man die Benutzer welche sich über ssh anmelden können einschränken. Gilt eigentlich für jeden Dienst.