warum erfindest man nicht einfach SE-Linux? Will sagen, die Laufzeitumgebung für sowas gibt es schon, schafft nur keiner, es beherrschbar zu verpacken. Was für Programme "normal" ist, scheint relativ schwer zu erkennen zu sein. Kann sein, dass Fedora da schon weiter ist, aber generell schaltet wohl "jeder" ausser ein paar Organisationen mit sehr viel Zeit, das einfach immer nur ab.
Bei Perl5 gibt es den tainted Modus (-t/-T), der Warnungen oder Fehlern führt, wenn man Werte benutzt, die vom User stammen. Erst nach einem Test auf den Wert, konnte es genutzt werden. Hat glaube ich so nie jemand übernommen.
Sicherheit ist immer ein Kampf um Wissensvorsprung. Wir können es schwerer machen, Systeme zu übernehmen, aber wir können es nicht verhindern. Oberhalb einer gewissen Komplexität, werden Fehler immer passieren und dann auch ausnutzbar sein.
Welche Waffen haben wir?
Diversifizierung 1: Nutzen wir einfach verschiedene Software, dann sind Exploits nicht so weithin anwendbar. Wenn wir Iceweasel 3.0.20 anwenden, passt der Firefox 3.6.8 Exploit vielleicht schon nicht, und mit Chomium oder Konqueror erst recht nicht.
Diversifizierung 2: Nutzen wir unterschiedliche Hardware. Wieviele Exploits für den Apache können meinen ARM-Server übernehmen?
Diversifizierung 3: Nutzen wir unterschiedliche Konfigurationen. Wenn openSUSE, Fedora, Ubuntu und Debian alles irgendwie ein wenig anders machen, dann sind Exploits nicht übertragbar.
Das gut daran, machen wir eh alles schon. Wir wissen nur nicht, dass dies genau der Grund ist, warum "Linux" sicherer ist.
SELinux, Apparmor oder der tainted Modus von Perl kenne ich natürlich schon. Warum niemand den tainted Modus übernommen hat, ist mir auch ein Rätsel.
Ich meine nur, dass die meisten Programmiersprachen nach diversen Paradigmen entworfen werden, aber selten auch nach Sicherheitsaspekten. Wenn zum Beispiel, die Überprüfung, ob ein Programm mit rechten XYZ auf Ordner ABC schreiben darf, direkt in die Laufzeitumgebung der Sprache integriert, dann läuft der Sicherheitsmechanismus unter jedem System und bei jedem Programmierer. DIe Wahrscheinlichkeit, dass so ein Fehler geschieht ist dann nahezu null.
Diversifikation ist ja schön und gut, aber meiner Meinung nach ein vollkommen anderes Feld. Diversifikation ersetzt in keinster Weise eine adäquate Sicherheitsstruktur.
aber die "Laufzeitumgebung" ist libc/Kernel und die nutzt jede Sprache, ob sie will oder nicht. Mit SE-Linux kannst Du dann "cat" dann wohl ein Label geben, dass das Lesen von Dateien erlaubt, aber ihr Erzeugen verbietet.
Ich muss gestehen, ich weiß jetzt nicht genau, woran Du denkst, wenn Du Sicherheitsaspekte von Sprachen meinst.
Das Problem beim Entwickeln, ist dass Du immer was möglich machst, was vorher nicht ging. Woran erkennst Du oder die Laufzeitumgebung der Sprache, dass zu viel möglich wurde?
In Ada (für Safety-Anwendungen erstellt, was aber nicht Security wäre) kann ich Dir (anderem Code) einen "Access" auf eine Struktur (Record) geben. Damit kannst Du nur indem Du sehr genau auf Deine Füsse zielst, an eine Addresse kommen.
Tja, aber was wenn Du dadurch zuviel Schreibzugriff hast? Wenn Du eigentlich nur ein oder ein paar Felder brauchst? Wenn deshalb der Code, das Interface zuviel erlaubt?
Schnittstellen sind überhaupt das Schwerste was es gibt für einen Entwickler, wenn er sie richtig hinbekommen soll. Er muss dann nämlich beide Seiten sehr gut kennen, was er bei Systemen der Komplexität von sagen wir Ubuntu aber häufig nicht ist und nicht sein kann, aber sich trotzdem so benehmen will oder muss.
Ich muss gestehen, ich weiß jetzt nicht genau, woran Du denkst, wenn Du Sicherheitsaspekte von Sprachen meinst.
Ich habe doch das Beispiel mit dem Schreiben auf Dateien mit den falschen Rechten genannt. Mit root Rechten sollte niemals ins Home eines Benutzers geschrieben werden dürften. Das ist eine Einschränkung die nie verletzt werden darf.
Wenn jetzt im Programm irgendwo ein "fopen(directory,"w")" steht sollte beim Kompilieren Code hinzugefügt werden, der zur Laufzeit überprüft, mit welchen Rechten das Programm läuft und welche Rechte „directory“ hat. Wenn das Ergebnis „Root-Rechte” und „Verzeichnis unter /home/XYZ/“ ist, dann wird an der Stelle schlicht agebrochen.
Die Idee ist einfach, für die Anwendung Einschränkungen zu definieren die beim Build-Prozess zu entsprechendem Security-Code führt, der Verhindert, dass das Programm diese Einschränkungen verletzt.
Wenn das Ergebnis „Root-Rechte” und „Verzeichnis unter /home/XYZ/“ ist, dann wird an der Stelle schlicht agebrochen.
Das ganze macht meiner Meinung keinen Sinn. Für rechte Verwaltung dieser Art in das Betreibssystem zuständig, nicht die Programmiersprache selbst. Warum soll die Programmiersprache eine zusätzliche Rechte Verwalung haben, welche - so wie du das Beispiel hier angibst - dann auch noch die des Betriebssystem irgendwie aus hebeln soll? Wer soll dann eigentlich definieren wo welches Programm schreiben soll? Wie soll die Programmiersprache erkennen ob root nun in ein Home-Verzeichnis schreiben darf oder nicht?
Die Lösung deines Problems ist ganz einfach: Soll ein Programm keine root Rechte haben, dann darfst du es auch nicht als root ausführen. Starte das Programm einfach mit einem User der nicht ins die Home-Verzeichnisse schreiben darf.
Natürlich gibt es auch komplexere Probleme, welche man nicht so einfach simpler Rechte Vergabe im Datei-System beheben kann. Doch genau da setzen die von dir schon genannten SE-Linux und Appamor an. Das Problem ist nur, dass man für jedes Programm ein Profil definieren muss, was es darf und was nicht. Natürlich könnte man das auch auf Ebene der Programmiersprachen lösen, doch das eigentliche Problem (Die Frage: "Wer darf was wo lesen und schreiben?") löst sich dadurch auch nicht auf magische weise.
Hallo Du,
warum erfindest man nicht einfach SE-Linux? Will sagen, die Laufzeitumgebung für sowas gibt es schon, schafft nur keiner, es beherrschbar zu verpacken. Was für Programme "normal" ist, scheint relativ schwer zu erkennen zu sein. Kann sein, dass Fedora da schon weiter ist, aber generell schaltet wohl "jeder" ausser ein paar Organisationen mit sehr viel Zeit, das einfach immer nur ab.
Bei Perl5 gibt es den tainted Modus (-t/-T), der Warnungen oder Fehlern führt, wenn man Werte benutzt, die vom User stammen. Erst nach einem Test auf den Wert, konnte es genutzt werden. Hat glaube ich so nie jemand übernommen.
Sicherheit ist immer ein Kampf um Wissensvorsprung. Wir können es schwerer machen, Systeme zu übernehmen, aber wir können es nicht verhindern. Oberhalb einer gewissen Komplexität, werden Fehler immer passieren und dann auch ausnutzbar sein.
Welche Waffen haben wir?
Diversifizierung 1: Nutzen wir einfach verschiedene Software, dann sind Exploits nicht so weithin anwendbar. Wenn wir Iceweasel 3.0.20 anwenden, passt der Firefox 3.6.8 Exploit vielleicht schon nicht, und mit Chomium oder Konqueror erst recht nicht.
Diversifizierung 2: Nutzen wir unterschiedliche Hardware. Wieviele Exploits für den Apache können meinen ARM-Server übernehmen?
Diversifizierung 3: Nutzen wir unterschiedliche Konfigurationen. Wenn openSUSE, Fedora, Ubuntu und Debian alles irgendwie ein wenig anders machen, dann sind Exploits nicht übertragbar.
Das gut daran, machen wir eh alles schon. Wir wissen nur nicht, dass dies genau der Grund ist, warum "Linux" sicherer ist.
Gruss,
Kay
SELinux, Apparmor oder der tainted Modus von Perl kenne ich natürlich schon. Warum niemand den tainted Modus übernommen hat, ist mir auch ein Rätsel.
Ich meine nur, dass die meisten Programmiersprachen nach diversen Paradigmen entworfen werden, aber selten auch nach Sicherheitsaspekten. Wenn zum Beispiel, die Überprüfung, ob ein Programm mit rechten XYZ auf Ordner ABC schreiben darf, direkt in die Laufzeitumgebung der Sprache integriert, dann läuft der Sicherheitsmechanismus unter jedem System und bei jedem Programmierer. DIe Wahrscheinlichkeit, dass so ein Fehler geschieht ist dann nahezu null.
Diversifikation ist ja schön und gut, aber meiner Meinung nach ein vollkommen anderes Feld. Diversifikation ersetzt in keinster Weise eine adäquate Sicherheitsstruktur.
Hallo Du,
aber die "Laufzeitumgebung" ist libc/Kernel und die nutzt jede Sprache, ob sie will oder nicht. Mit SE-Linux kannst Du dann "cat" dann wohl ein Label geben, dass das Lesen von Dateien erlaubt, aber ihr Erzeugen verbietet.
Ich muss gestehen, ich weiß jetzt nicht genau, woran Du denkst, wenn Du Sicherheitsaspekte von Sprachen meinst.
Das Problem beim Entwickeln, ist dass Du immer was möglich machst, was vorher nicht ging. Woran erkennst Du oder die Laufzeitumgebung der Sprache, dass zu viel möglich wurde?
In Ada (für Safety-Anwendungen erstellt, was aber nicht Security wäre) kann ich Dir (anderem Code) einen "Access" auf eine Struktur (Record) geben. Damit kannst Du nur indem Du sehr genau auf Deine Füsse zielst, an eine Addresse kommen.
Tja, aber was wenn Du dadurch zuviel Schreibzugriff hast? Wenn Du eigentlich nur ein oder ein paar Felder brauchst? Wenn deshalb der Code, das Interface zuviel erlaubt?
Schnittstellen sind überhaupt das Schwerste was es gibt für einen Entwickler, wenn er sie richtig hinbekommen soll. Er muss dann nämlich beide Seiten sehr gut kennen, was er bei Systemen der Komplexität von sagen wir Ubuntu aber häufig nicht ist und nicht sein kann, aber sich trotzdem so benehmen will oder muss.
Gruß,
Kay
Ich habe doch das Beispiel mit dem Schreiben auf Dateien mit den falschen Rechten genannt. Mit root Rechten sollte niemals ins Home eines Benutzers geschrieben werden dürften. Das ist eine Einschränkung die nie verletzt werden darf.
Wenn jetzt im Programm irgendwo ein "fopen(directory,"w")" steht sollte beim Kompilieren Code hinzugefügt werden, der zur Laufzeit überprüft, mit welchen Rechten das Programm läuft und welche Rechte „directory“ hat. Wenn das Ergebnis „Root-Rechte” und „Verzeichnis unter /home/XYZ/“ ist, dann wird an der Stelle schlicht agebrochen.
Die Idee ist einfach, für die Anwendung Einschränkungen zu definieren die beim Build-Prozess zu entsprechendem Security-Code führt, der Verhindert, dass das Programm diese Einschränkungen verletzt.
Wenn das Ergebnis „Root-Rechte” und „Verzeichnis unter /home/XYZ/“ ist, dann wird an der Stelle schlicht agebrochen.
Das ganze macht meiner Meinung keinen Sinn. Für rechte Verwaltung dieser Art in das Betreibssystem zuständig, nicht die Programmiersprache selbst. Warum soll die Programmiersprache eine zusätzliche Rechte Verwalung haben, welche - so wie du das Beispiel hier angibst - dann auch noch die des Betriebssystem irgendwie aus hebeln soll? Wer soll dann eigentlich definieren wo welches Programm schreiben soll? Wie soll die Programmiersprache erkennen ob root nun in ein Home-Verzeichnis schreiben darf oder nicht?
Die Lösung deines Problems ist ganz einfach: Soll ein Programm keine root Rechte haben, dann darfst du es auch nicht als root ausführen. Starte das Programm einfach mit einem User der nicht ins die Home-Verzeichnisse schreiben darf.
Natürlich gibt es auch komplexere Probleme, welche man nicht so einfach simpler Rechte Vergabe im Datei-System beheben kann. Doch genau da setzen die von dir schon genannten SE-Linux und Appamor an. Das Problem ist nur, dass man für jedes Programm ein Profil definieren muss, was es darf und was nicht. Natürlich könnte man das auch auf Ebene der Programmiersprachen lösen, doch das eigentliche Problem (Die Frage: "Wer darf was wo lesen und schreiben?") löst sich dadurch auch nicht auf magische weise.