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.
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.