Ist das ganze Message System nicht ein riesen Security Loch?
-
dot schrieb:
mgaeckler schrieb:
hustbaer schrieb:
Ey, nochmal: du übersiehst hier dass man das nicht in allen Fällen machen kann.
Das geht z.B. wenn ich ein Programm A starte, und ein Programm B in der selben Session starte, beide unter meinem Account laufen lasse, dann können die sich gegenseitim im Speicher rumpfuschen.Das finde ich schlimm genug, sonst hätte ich geschrieben, daß da 100 Zeppeline nebeineinander durchpassen.
Was empfielst du denn als sichere Alternative?
So ähnlich wie ich das vorhin beschrieben habe:
Das System entscheidet ausschließlich an Hand eines Eintrags unter HKEY_LOCAL_MACHINE, das ja nur der Admin ändern darf, welche DLLs sich in welche Anwendung(en) einklinken dürfen. Sobald ein (Installations)programm versucht, so einen Schlüssel zu verändern, wird der Admin gefragt, ob er dieses zulassen will.
Für diejenigen Admins, die einen ganzen Rechnerpark einrichten müssen, könnte natürlich auch eine Policy eingeführt werden, so daß der arme Admin dies nicht für jeden Rechner einzeln bestätigen muß.Auf diese Art kann sich ein DAU nicht so leicht eine Schadsoftware einfangen, die diese Wege der Spionage nutzen will.
Wenn der DAU natürlich ein SuperDAU ist und immer mit Adminrechten am Rechner sitzt, dann ist, wie ich schon schrieb, sowieso alles zu spät.
mfg Martin
-
dot schrieb:
mgaeckler schrieb:
Das kann jeder Prozess, den der Benutzer gestartet hat. Sei es wissentlich oder aus Dummheit.
Ähm, das ist aber ein prinzipielles Problem. Jeder Prozess, den der Benutzer mit gewissen Rechten startet, sei es wissentlich oder aus Dummheit, kann unter jedem mit bekannten Betriebssystem die ihm verliehenen Rechte missbrauchen, um entsprechenden Schaden anzurichten!? Was genau kann da jetzt das OS dafür!?
Das OS kann was dafür, weil es nicht mehr Kontrollmöglichkeiten zur Verfügung stellt. Ein Beispiel:
Es wäre doch z.B. recht praktisch, wenn ich im System festlegen könnte, die Datei darf zwar von den Benutzern x, y und z bearbeitet werden aber nur mit dem Programm p. Mit *Nixen könnte man sowas ähnliches realisieren, da es dort das setuid-bit gibt. Aber das bereitet auch leider immer wieder Probleme und ist auch nicht so recht das gelbe vom Ei vor allen Dingen, weil diese Prozesse dann häufig gleich mit Superuserrechten laufen. Außerdem ist es nicht genau das was ich meine.
mfg Martin
-
mgaeckler schrieb:
Es wäre doch z.B. recht praktisch, wenn ich im System festlegen könnte, die Datei darf zwar von den Benutzern x, y und z bearbeitet werden aber nur mit dem Programm p.
Und was genau hindert dich unter Windows nun daran, das festzulegen?
-
dot schrieb:
mgaeckler schrieb:
Es wäre doch z.B. recht praktisch, wenn ich im System festlegen könnte, die Datei darf zwar von den Benutzern x, y und z bearbeitet werden aber nur mit dem Programm p.
Und was genau hindert dich unter Windows nun daran, das festzulegen?
Das Wissen um so eine Option hindert mich daran. Wo soll denn so eine Option sein? Ich kenne sowas nicht.
mfg Martin
-
Einfachste Lösung, die mir spontan einfällt: Du machst einen User a, der entsprechende Rechte im entsprechenden Ordner hat und gibst den Usern x, y und z das Recht, das jeweilige Programm als User a auszuführen...
-
dot schrieb:
Einfachste Lösung, die mir spontan einfällt: Du machst einen User a, der entsprechende Rechte im entsprechenden Ordner hat und gibst den Usern x, y und z das Recht, das jeweilige Programm als User a auszuführen...
Das könnte vieleicht eine Lösung sein. Aber ist es dann nicht so, daß die Anwender x, y und z jedesmal, wenn sie die Anwendung starten, das Kennwort von a eingeben müssen. Wie sieht es dann mit Netzlaufwerken aus? Kann das Programm dann auch auf die Netzlaufwerke der Benutzer zugreifen?
Solche Lösungen könnten zwar besonders kritische Probleme lösen, für einen allgemeinen Gebrauch erscheinen sie mir aber zu umständlich und werden daher für gewöhnlich von den Anwendern nicht angenommen.
mfg Martin
-
Wie sieht es dann mit Netzlaufwerken aus? Kann das Programm dann auch auf die Netzlaufwerke der Benutzer zugreifen?
Je nachdem welche Rechte du User a gegeben hast. Wenn das Programm als User a läuft sollte es eigentlich keine Kontrolle über z.b. die Daten von Benutzer x haben (korrigiert mich wenn ich mich irre). Und Passwort musst du ja keins festlegen für User a.
Solche Lösungen könnten zwar besonders kritische Probleme lösen, für einen allgemeinen Gebrauch erscheinen sie mir aber zu umständlich und werden daher für gewöhnlich von den Anwendern nicht angenommen
Für normale User reicht es ja auch nicht immer als Admin unterwegs zu sein, diese Lösung ist eher für Systeme mit mehreren Benutzern die unterschiedliche Rechte haben. Und ja, sowas zu konfigurieren ist immer etwas Aufwand, aber den hat man immer, oder hast du einen Vorschlag wie es besser gehen würde ?
-
Ideal wäre wenn jede Anwendung in einer Sandbox laufen würde und Löcher in die Sandbox nur durch Zustimmung des Nutzers geschlagen werden dürften (zum Beispiel für IPC oder Zugriff auf Teile des Dateisystems)
...aber ich befürchte dann hat man mehr mit den Berechtigungen zu tun als man tatsächlich produktiv arbeiten kann
-
DarkShadow44 schrieb:
Wie sieht es dann mit Netzlaufwerken aus? Kann das Programm dann auch auf die Netzlaufwerke der Benutzer zugreifen?
Je nachdem welche Rechte du User a gegeben hast. Wenn das Programm als User a läuft sollte es eigentlich keine Kontrolle über z.b. die Daten von Benutzer x haben (korrigiert mich wenn ich mich irre).
So sollte es sein und so ist es auch. Sonst wäre Kleinweich völlig verblödet.
DarkShadow44 schrieb:
Und Passwort musst du ja keins festlegen für User a.
Wo ist dann der Schutz? Wäre es dann auch nicht für ein Schadprogramm ein leichtes da einzudringen?
DarkShadow44 schrieb:
Und ja, sowas zu konfigurieren ist immer etwas Aufwand, aber den hat man immer, oder hast du einen Vorschlag wie es besser gehen würde ?
Da sind wir jetzt an einen Punkt, der zeigt, daß es sich hier um kein triviales Problem handelt. Bei den Kleinweichlösungen kommt es mir aber so vor, daß sie häufig die Symptome eines Fehlers beseitigen ohne den Fehler selbst zu beheben. Der Hauptgrund dürfte dabei wahrscheinlich sein, daß sie mit aller Gewalt an Konzepten festhalten, die zur Homecomputerzeit noch akzeptabel waren, aber heute eigentlich nicht mehr tragbar sind.
Eine Lösung für sowas zu finden, ist allerdings natürlich auch nicht einfach. Ein sicheres System muß nämlich
- Vom Konzept her so einfach sein, daß der Betriebsystementwickler bzw. -progammierer wenig bis gar keine Fehler machen kann.
- Der Anwendungsentwickler sollte sich ebenfalls wenig bis gar keine Gedanken darüber machen müssen.
- Für den Administrator, darf das ganze auch nicht zu umständlich sein (erst recht bei einem privat PC, der nicht von einem Fachmann gewartet wird)
- Und zu guter letzt, der Anwender selbst sollte nicht zu viel behindert werden.
Eine sehr schwere Aufgabe. Ich mache mir darüber schon seit vielen Jahren Gedanken und ich bin zu den Schluß gekommen, daß die OS Hersteller auf jeden Fall alte Zöpfe mal abschneiden müssen und sich mal wirklich darauf konzentrieren müssen, endlich mal sichere Systeme zu konzipieren.
mfg Martin
-
mgaeckler schrieb:
Eine Lösung für sowas zu finden, ist allerdings natürlich auch nicht einfach. Ein sicheres System muß nämlich
- Vom Konzept her so einfach sein, daß der Betriebsystementwickler bzw. -progammierer wenig bis gar keine Fehler machen kann.
- Der Anwendungsentwickler sollte sich ebenfalls wenig bis gar keine Gedanken darüber machen müssen.
- Für den Administrator, darf das ganze auch nicht zu umständlich sein (erst recht bei einem privat PC, der nicht von einem Fachmann gewartet wird)
- Und zu guter letzt, der Anwender selbst sollte nicht zu viel behindert werden.
Eine sehr schwere Aufgabe. Ich mache mir darüber schon seit vielen Jahren Gedanken und ich bin zu den Schluß gekommen, daß die OS Hersteller auf jeden Fall alte Zöpfe mal abschneiden müssen und sich mal wirklich darauf konzentrieren müssen, endlich mal sichere Systeme zu konzipieren.
Tja, der Anwender muss Administrator-Rechte haben, sonst laufen manche Spiele nicht.
-
volkard schrieb:
Tja, der Anwender muss Administrator-Rechte haben, sonst laufen manche Spiele nicht.
Ja das war leider nach der Einführung von Windows NT ein großes Problem. Viele Anwendungen, die nach NT portiert worden sind, gingen immer noch davon aus, daß der Benutzer Adminrechte hat. Auch sind viele Anwendungen davon ausgegangen, daß derjenige, der die Anwendung installiert hat, auch derjenige ist, der sie benutzt. Da werden dann wichtige Einstellungen unter HKEY_CURRENT_USER gespeichert und später nicht mehr gefunden. Das ist dann allerdings ein Problem, das man MS wirklich nicht anlasten kann.
mfg Martin
-
volkard schrieb:
Tja, der Anwender muss Administrator-Rechte haben, sonst laufen manche Spiele nicht.
Das finde ich zu unpräzise. Die Spiele brauchen keine Administratorrechte, sie wollen gar keine Windows-Domäne konfigurieren. Sie wollen einfach nur auf ihren Installationsordner zugreifen, was meiner Meinung nach keine überzogene Forderung darstellt. Es sollte die Möglichkeit geben zu sagen, dass das Spiel auf seinen Installationsordner und auf seine Registry-Keys zugreifen kann, aber nicht auf andere Installationsordner (Expansions mal ausgenommen) und nicht auf die Keys anderer Programme und Nutzerpasswörter ändern schon gar nicht.
mgaeckler schrieb:
Wenn der DAU natürlich ein SuperDAU ist und immer mit Adminrechten am Rechner sitzt, dann ist, wie ich schon schrieb, sowieso alles zu spät.
Da gehe ich auch nicht mit. Auch als Administrator muss ich die Möglichkeit haben geilemuschies.jpg.exe so auszuführen, dass es nichts kompromittieren kann. Ich bin generell dagegen, dass ich als einzelner Nutzer schizophren sein muss und mal Admin und mal Nutzer und mal eingeschränkterer Nutzer sein muss. Völlig falsche Denkweise. Ich bin immer Administrator. Nur dürfen die Programme, die ich ausführe, nicht mit Adminrechten gestartet werden. Also braucht man Programmrechte, die ungleich der Nutzerrechte sind. Damit lösen sich alle Probleme. Ich werde nie begreifen warum das nicht Standard ist bzw. noch nie versucht wurde.
-
nwp3 schrieb:
Also braucht man Programmrechte, die ungleich der Nutzerrechte sind. Damit lösen sich alle Probleme. Ich werde nie begreifen warum das nicht Standard ist bzw. noch nie versucht wurde.
Ist doch Standard auf jedem modernen OS!? Nur sind die Defaulteinstellungen halt nirgendwo so extrem wie du es gerne hättest, weil das Ding dann kein Mensch mehr würde benutzen wollen...
-
nwp3 schrieb:
volkard schrieb:
Tja, der Anwender muss Administrator-Rechte haben, sonst laufen manche Spiele nicht.
Das finde ich zu unpräzise. Die Spiele brauchen keine Administratorrechte, sie wollen gar keine Windows-Domäne konfigurieren. Sie wollen einfach nur auf ihren Installationsordner zugreifen, was meiner Meinung nach keine überzogene Forderung darstellt. Es sollte die Möglichkeit geben zu sagen, dass das Spiel auf seinen Installationsordner und auf seine Registry-Keys zugreifen kann, aber nicht auf andere Installationsordner (Expansions mal ausgenommen) und nicht auf die Keys anderer Programme und Nutzerpasswörter ändern schon gar nicht.
Genau, sowas wäre z.B. ganz praktisch. Dann könnte man sagen der Installationsordner XYZ der Anwendung XYZ darf auch nur von der Anwendung geändert werden. Der Eigentümer einer Datei/eines Ordner kann nicht nur festlegen welche Benutzer/Gruppen was damit machen dürfen sondern auch mit welchen Anwendungen. Eine Anwendung könnte dann schon beim Installieren festlegen, ich brauche Schreibrechte auf diese oder jene Unterverzeichnisse.
nwp3 schrieb:
mgaeckler schrieb:
Wenn der DAU natürlich ein SuperDAU ist und immer mit Adminrechten am Rechner sitzt, dann ist, wie ich schon schrieb, sowieso alles zu spät.
Da gehe ich auch nicht mit. Auch als Administrator muss ich die Möglichkeit haben geilemuschies.jpg.exe so auszuführen, dass es nichts kompromittieren kann. Ich bin generell dagegen, dass ich als einzelner Nutzer schizophren sein muss und mal Admin und mal Nutzer und mal eingeschränkterer Nutzer sein muss. Völlig falsche Denkweise. Ich bin immer Administrator. Nur dürfen die Programme, die ich ausführe, nicht mit Adminrechten gestartet werden. Also braucht man Programmrechte, die ungleich der Nutzerrechte sind. Damit lösen sich alle Probleme. Ich werde nie begreifen warum das nicht Standard ist bzw. noch nie versucht wurde.
Das wäre sicherlich wünschenswert. Nixen kennen dazu ja z.B. den Systermaufruf chroot, damit Programme, die vom Admin gestartet werden, nicht gleich das ganze System übernehmen können.
mfg Martin
-
dot schrieb:
nwp3 schrieb:
Also braucht man Programmrechte, die ungleich der Nutzerrechte sind. Damit lösen sich alle Probleme. Ich werde nie begreifen warum das nicht Standard ist bzw. noch nie versucht wurde.
Ist doch Standard auf jedem modernen OS!? Nur sind die Defaulteinstellungen halt nirgendwo so extrem wie du es gerne hättest, weil das Ding dann kein Mensch mehr würde benutzen wollen...
Ok. Wie starte ich (als Admin) notepad so, dass es auf C:\Users\nwp3\Desktop\passwords.txt nicht zugreifen kann? Und außerdem nur maximal 174MB RAM verbrauchen darf? Und mit www.c-plusplus.net per TCP und mit duckduckgo.com per UDP kommunizieren darf, außer an Sonntagen? Ich weiß bei keinem davon wie es geht und insbesondere das erste ist dringend nötig.
-
@nwp3
Verarscht du dich grad selbst?
-
nwp3 schrieb:
volkard schrieb:
Tja, der Anwender muss Administrator-Rechte haben, sonst laufen manche Spiele nicht.
Das finde ich zu unpräzise. Die Spiele brauchen keine Administratorrechte, sie wollen gar keine Windows-Domäne konfigurieren. Sie wollen einfach nur auf ihren Installationsordner zugreifen, was meiner Meinung nach keine überzogene Forderung darstellt. Es sollte die Möglichkeit geben zu sagen, dass das Spiel auf seinen Installationsordner und auf seine Registry-Keys zugreifen kann, aber nicht auf andere Installationsordner (Expansions mal ausgenommen) und nicht auf die Keys anderer Programme und Nutzerpasswörter ändern schon gar nicht.
Ich dachte eher an den "Hackerschutz", wo das Onlinegame versuchen will, zu schauen, daß keine Bots laufen, und deshalb Amin sein will.
-
hustbaer schrieb:
@nwp3
Verarscht du dich grad selbst?Nö, völlig ernst gemeint. Erscheint es eine Verarsche, weil ich das machen können will, oder weil ich nicht weiß wie es geht? Vielleicht waren die Beispiele etwas überzogen. Neues Beispiel: Ich möchte Windows sagen, dass Email-Anhänge (definiert durch den Speicherort \Bla\emails) nicht auf \Users\ich zugreifen können, wenn sie von Programm Emailclient gestartet wurden. Emailclient selbst darf auf alles zugreifen. Die Programme dürfen sich auch nicht umkopieren um die Regel zu umgehen. Mir erscheint das eine sinnvolle Einstellung und ich glaube jeder kann sich ähnliche Regeln ausdenken, die er gern von seinem Betriebssystem durchgesetzt haben will. Man kann Windows doch auch sagen, dass ein Programm ins Internet darf, aber nicht Server spielen darf. Warum gibt es für Ordner/Nachrichten/Speicherzugriffe/Hardwarezugriffe/DLL-Injections nichts bzw. warum sagt mit keiner wie es geht?
(Mir fällt gerade auf, dass man das neue Beispiel per FUSE implementieren könnte, aber ich bin gespannt auf die Standardlösung, die jedes moderne OS schon drin hat. Außerdem müsste man dann immer noch FUSE selbst irgenwie schützen und es funktioniert nicht für Nachrichten, Netzwerke, RAM, ...)
volkard schrieb:
Ich dachte eher an den "Hackerschutz", wo das Onlinegame versuchen will, zu schauen, daß keine Bots laufen, und deshalb Amin sein will.
In dem Fall würde ich Windows sagen wollen, dass das Spiel Adminrechte bekommt, aber den Bot nicht sehen darf. Kann man Windows auch nicht sagen, oder ich weiß nur nicht wie es geht.
-
@nwp3
Dass du das möchtest, ist mir schon klar. Dass es praktisch wäre auch.
Aber du hast behauptet (bzw. zumindest stark impliziert), dass es gaaaaanz einfach umzusetzen gewesen wäre.Und da behaupte ich mal einfach das krasse Gegenteil: das ist überhaupt nicht einfach umzusetzen.
Zumindest nicht so lange man den User nicht nerven will, und nicht so-gut-wie alles was ein OS ausmacht neu erfinden will.
-
nwp3 schrieb:
In dem Fall würde ich Windows sagen wollen, dass das Spiel Adminrechte bekommt, aber den Bot nicht sehen darf. Kann man Windows auch nicht sagen, oder ich weiß nur nicht wie es geht.
Denk doch mal nach, wenn Du den Bot wirksam mit ein paar Klicks vorm Admin unsichtbar machen kannst, dann kann sich auch die Malware verstecken.
