Wahlweise als Admin oder Hauptbenutzer

Hallo Thomas,

Das Ganze ist prinzipiell möglich und auch nicht schwer in SuRun zu integrieren.
Allerdings muss das auch verwaltet werden, ohne noch mehr Verwirrung des normalen Benutzers zu schaffen.

Wenn ich Dich richtig verstanden habe, geht es u.A. darum, unbekannte Software als Hauptbenutzer zu starten. Es müsste also in SuRuns AutoMagie bzw. in "Starte als Administrator..." ein neuer Schalter rein, der eine "vordefinierte Benutzergruppe" festlegt unter der das Programm läuft.

Das GUI wird derzeit überarbeitet (siehe http://forum.kay-bruns.de/post/1583).
Es ist bereits vorgesehen, Programme als anderer Benutzer ausführen zu können.
Es wäre dort auch möglich eine Gruppe anzugeben, wenn das Programm als der angemeldete Benutzer starten soll.
Man könnte sogar jedes einzelne Privileg und den Besitzer neu erstellter Objekte für jedes Programm separat angeben. Ich befürchte aber, dass das zu komplex für 99% der Benutzer sein würde.

Das mit der vordefinierten Gruppe wäre wohl die einfachste Variante.

Es gibt viele vordefinierte Gruppen. Sollen nur Administratoren und Hauptbenutzer in die Auswahl?
Man könnte sogar Gäste mit aufnehmen. Dann wäre in SuRun so was, wie mit DropMyRights möglich... Allerdings muss "Starte als Administrator..." dann zwingend geändert werden.

Kay wrote:Wenn ich Dich richtig verstanden habe, geht es u.A. darum, unbekannte Software als Hauptbenutzer zu starten.

Kay, was verstehst du unter unbekannter Software?

Mir fallen da 2 Definitionen ein:

1. Die Software ist tatsächlich völlig unbekannt. Man hat eine Datei (im Zweifelsfall zum Installieren), ansonsten keine Info. Klassischer Fall, wo die Frage nach der Vertrauenswürdigkeit nicht beantwortbar ist.

2. Die Software ist dem Benutzer oder zumindest allgemein bekannt und auch als vertrauenswürdig (sofern von offizieller Quelle geladen) anzusehen (Beispiele: OpenOffice, Mozilla-Produkte), nur ist in dem Fall eventuell unbekannt, wie sie sich bezüglich der Rechte verhält. (Daß sich die Frage bei den genannten Produkten nicht wirklich stellt, sei mal außen vor gelassen).

Im Fall 2 ist ganz klar: Die Software wird dem Rechner nichts böses tun, ob man sie mit Admin-Rechten oder Hauptbenutzer-Rechten ausführt. Da man aber eben nicht weiß, welche Rechte benötigt werden, kann man es auch gleich mit LUA-Rechten versuchen. Admin-Rechte werden aber nichts verschlimmern. EDIT: Fußnote

Im ersten Fall ist ebenso klar, daß man eine völlig unbekannte Software am besten gar nicht installiert, jedenfalls nicht in einem produktiven System. Es ist eigentlich der klassische Fall, wo man ein abgeschlossenes und ohne Verlust zurücksetzbares System wie zum Beispiel eine virtuelle Maschine (möglichst ohne Netzwerkfunktinalität) verwendet. Aber dann spielt der Grad der Rechte-Anhebung auch keine Rolle. Mit unzureichenden Rechten kann ich eine unzureichend bekannte Software aber nicht analysieren, weil ich nicht sagen kann, ob Mängel auf Rechte-Mängel zurück zu führen sind.

Wo ist da der Sinn für Hauptbenutzer? Ich habe sowieso den Eindruck gewonnen, daß sich viele, die "Hauptbenutzer" verwenden (wollen), sich über die Implementation nicht im klaren sind, und die Wortwahl für die Benennung dieser Gruppe ist wahrscheinlich mit daran Schuld.

Statt Hauptbenutzer hätte MS wohl besser daran getan, die Gruppe zum Beispiel "Moderatoren" zu benennen, denn sie ist von ihren Möglichkeiten den Administratoren viel näher als den Benutzern; die Wortwahl suggeriert aber, als ob Hauptbenutzer ebenfalls im Wesentlichen eingeschränkt seien, nur halt ein kleines bißchen weniger eingeschränkt. Das ist falsch. Hauptbenutzer sind eine Gruppe, die von MS aus Kompatibilitätsgründen zu NT4 zusammen mit W2k eingeführt worden ist und MS selbst rät klar davon ab, Hauptbenutzer außer in zwingenden Fällen zu benutzen. Hauptbenutzer haben völlig ausreichende Rechte, um ein System zu kompromittieren. Ist also eine nicht-vertrauenswürdige Software tatsächlich schädlich, so wird sie das auch tun, egal ob Admin- oder Hauptbenutzer-Rechte zu Grunde liegen.

Die Unterschiede zwischen Admins und HBs (wie gesagt historisch gewachsen) können aber dazu führen, daß unbekannte Software, und dazu gehören Installationsprogramme typischerweise, mit HB-Rechten funktionieren kann, aber nicht muß. Die Tatsache, daß die Software unbekannt ist besagt ja schon, daß man das nur durch Versuche herausfinden kann, aber eine fehlgeschlagene Installation kann dann - wenn der Installer unsauber programmiert worden ist - verheerend auf das System auswirken. HBs sind also gut für zerschossene Systeme, zumindest aber defekte Programme - und für Beschuldigungen, daß SuRun nicht richtig funktioniert hätte. In der Software-Dokmentation wird man HB nicht finden. Ich kenne unter hunderten Programmen nur eines, bei dem der Hauptbenutzer überhaupt im Zusammenhang mit Installation erwähnt worden ist, und da auch noch falsch; mittlerweile wird bei Terratec (darum handelt es sich) die FAQ nur noch auf englisch mitgeliefert und da steht dann auch richtig Administrator.

Daß das ganze den Grad der Verwirrung bei den SuRun-Benutzern erhöhen wird, würde eine unausweichliche Folge sein; außer der Verwirrung ist der positive Effekt nicht zu finden, denn HBs sind kein Sicherheitsvorteil gegenüber Admin-Rechten, sie taugen lediglich zur Illusion über höhere Sicherheit und das bei denjenigen, die diese Illusion der eindeutigen Empfehlung von MS vorziehen.

tlu hat mir im vergangenen Jahr einmal den Vorwurf gemacht, mit der von mir propagierten Trennung zwischen Surun und RunAs die Dinge zu verkomplizieren. Etwas anzubieten, was laut Hersteller ein "no no" ist (und nur für eine explizite Situation geschaffen wurde), ist demgegenüber aber die Potenzierung von Kompliziert, und das ohne Sicherheitsgewinn und mit zweifelhaften und unzuverlässigen Ergebnissen.

Kay wrote:Man könnte sogar Gäste mit aufnehmen. Dann wäre in SuRun so was, wie mit DropMyRights möglich...

Das mit den Gästen mußt du mal erläutern. Welcher Sicherheitsgewinn soll dadurch entstehen?

EDIT: Fußnote: Damit daß jetzt keiner in den falschen Hals kriegt: Gerade in Bezug auf Mozilla-Proddukte, also Browser, Mail-Clients, heißt das natürlich nicht, daß ich damit der Meinung bin, daß man diese mit erweiterten Rechten benutzen solle. Im Gegenteil, ich habe hier schon bei Gelegenheit dagegen gewettert; obiges bezog sich ausschließlich auf die Produkte als solche, aber diese Produkte öffnen Dokumente und führen gegebenenfalls Inhalte aktiv aus, Inhalte die der Benutzer im Voraus typischerweis nicht kennt. Diese Inhalte können gefährlich sein und deren Gefahr läßt sich durch "Reduktion" der erweiterten Rechte auf HB nicht einmal reduzieren! Für OOo gilt dasselbe spätestens ebenfalls dann, wenn Makros in den Dokumenten sind.

Cosmo, wo du recht hast, hast du recht.

Das ist in der Tat völlig überflüssig bzw. kontraproduktiv.

Kay, lass das bitte bleiben!

Die Frage ob es Software gibt die nicht das macht was sie vorgibt stellt sich kaum, weil einer der Hauptgründe statt "ausführen als" lieber "surun" zu nutzen ist dass es Software geben könnte die das Admin PW mitloggen könnte...

Es geht nicht nur um unbekannte Software, sondern auch um die Ausführung von bekannter Software (Beispiel: Konfigurationstools von Lancom).
Es ist für die meisten Programme, die aus irgendwelchen Gründen nicht im Benutzerkontext laufen, einfach nicht nötig dass diese mit Administratorrechten gestartet werden. Sollte diese Programme (nicht das angeführte Beispiel) selber Programme o.ä. starten, laufen diese wiederum mit Adminrechten...usw. Thunderbird und Firefox zum update sind tatsächlich solche Beispiele. Warum nicht mit Adminrechten? Weil es nicht nötig ist und jeder Prozeß der unnötig mit Amdinrechten läuft ein zusätzliches Risiko darstellt.

Mit Hauptbenutzerrechten war nur ein Beispiel, leider ruft es wie auf Bestelleung die Hasser der Hauptbenutzer(gruppe) auf den Plan, wer nur 101% sichere Software auf dem Rechenr hat, der brauch weder surun noch Benutzerkonten. Es geht mir nur darum eine Anwendung die nicht mit Benutzerrechten läuft nicht gleich mit Adminrechten starten zu müssen - wie es auch immer realisiert wird.

Im GUI würde [ ]nur mit Hauptbenutzer- statt Administratorrechten starten schon reichen. Eventuell als Option bei der Installation für die angeblichen Nichtversteher.

Als anderer user auszuführen hat den Nachteil dass es nicht im gleichen userkontext ausgeführt werden kann - ein großer Vorteil von surun (ohne mach-mich-adminscripte o.ä.)

Danke an Kay, dass dir das angesehen hast. Ich will surun nicht komplizierter, sondern dass es noch ein bisschen mehr zur Sicherheit beitragen kann.

Vielen Dank.

Thomas

Cosmo wrote: Kay, was verstehst du unter unbekannter Software?

Hätte ich genauer spezifizieren sollen: Software, die SuRun nicht kennt.
Das zielte darauf ab, ob in der Automagie und im Bestätigungs-Dialog eine zusätzliche Option rein müsste...

Aber Dank der bisherigen Reaktionen kann ich mir die ganze Arbeit ja wahrscheinlich sparen. :-D

EDIT: Ich hatte Thomas' Antwort noch nicht gesehen.

Ich habe mal probehalber einen Hauptbenutzer angelegt und mir dessen Rechte angesehen.
Er hat gegenüber normalen Benutzern nur das "SeProfileSingleProcessPrivilege", was das Profilieren anderer Prozesse ermöglicht. Der Hauptbenutzer kann also anscheinend keine Dienste oder Treiber installieren. Die ganze "Unsicherheit" des Hauptbenutzers scheint wohl nur in den Standard-Zugriffsrechten zu liegen.

Umgekehrt kann man sicherlich auch durch setzen der Zugriffsrechte die bockigen Programme zum Laufen bewegen. Jedenfalls hat das hier bisher immer funktioniert.

Hmmm.

Kay wrote:

Cosmo wrote: Kay, was verstehst du unter unbekannter Software?

Hätte ich genauer spezifizieren sollen: Software, die SuRun nicht kennt.
Das zielte darauf ab, ob in der Automagie und im Bestätigungs-Dialog eine zusätzliche Option rein müsste...

Aber Dank der bisherigen Reaktionen kann ich mir die ganze Arbeit ja wahrscheinlich sparen. :-D

Was obiges mit den HB-Männchen zu tun hat, vermag ich nicht zu erkennen.
Genauso wenig wie die Frage mit den Gästen.

Sparen kannst du dir das, aber nicht wegen der Reaktionen, sondern weil es falsch ist.

Wünsche gibt es für alles mögliche. Heerscharen von Benutzern, die ihre XP / Vista immer noch so benutzen wie vor 1 Jahrzehnt W98 sprechen für den Wunsch, einmal im Leben Admin sein zu dürfen. Dieser Wunsch ändert nichts daran, daß er hintergestrig und falsch ist. (Im übrigen wäre SuRun anderenfalls flüssig ein Kropf, denn wozu braucht ein Rund-um-die-Uhr-Admin Surun?

Kay wrote:Ich habe mal probehalber einen Hauptbenutzer angelegt und mir dessen Rechte angesehen.
Er hat gegenüber normalen Benutzern nur das "SeProfileSingleProcessPrivilege", was das Profilieren anderer Prozesse ermöglicht. Der Hauptbenutzer kann also anscheinend keine Dienste oder Treiber installieren.

Wie ja auch in der Hilfe dokumentiert ist (1. Treffer bei Stichwort HB).

Thomas wrote: Die Frage ob es Software gibt die nicht das macht was sie vorgibt stellt sich kaum, weil einer der Hauptgründe statt "ausführen als" lieber "surun" zu nutzen ist dass es Software geben könnte die das Admin PW mitloggen könnte...

Falsch. Und das gleich doppelt und dreifach.


Erstens: Wenn von einer eingesetzten Software nicht ausgeschlossen werden kann, daß sie das PW mitloggt, so ist sie nicht bekannt (per Definition). Damit gehört sie nicht auf ein Produktivsystem. Und erst recht ist das Starten von Software, der man nicht vertraut, daß sie so etwas nicht tut, mit wie auch immer erhöhten Rechten ein Schuß ins eigene Knie.

Zweitens: Oder sollte auf dem Rechner virulent eine solche SW laufen, ohne daß der Benutzer das weiß? Dann gäbe es auf dem Rechner allerdings ein kardinales Sicherheitproblem und die Gesamt-Konfiguration wäre fehlerhaft. Das wissend ein HB-Männchen zu verwenden, indem man die Literaturstellen darüber einfach ignoriert statt sie zu lesen und statt dessen der Illusion folgt, ist ... naja: weniger gelungen. Denn wie soll sich Schad-Software auf einem richtig konfigurierten und verwendeten System einnisten? Im Konto wäre es möglich, aber nur bei fehlerhafter Konfiguration und Benutzung. (Was aber nichts mehr mit SuRun zu tun hat.)

Drittens: In Post #1 ist der Bezug zwischen dem HB-Wunsch und dem Installieren ausdrücklich geschrieben worden. Niemand hindert dich, ein HB-Konto einzurichten und es zum Installieren zu verwenden, SuRun wird dafür nicht gebraucht. In dem Fall bist du ganz allein für fehlerhafte Installationen verantwortlich.

Viertens: Wenn es auch im Nicht-Installer geht, so hat dich Kay bereits darauf hingewiesen, wie es noch besser und sicherer geht.

Fünftens: Du magst es noch nicht gesehen haben. aber SuRun bietet eine Option an, den "Ausführen als" Dialog durch einen eigenen, gegenüber "mitloggen" sicheren zu ersetzen. Wenn es also um nicht mehr als das geht (ich finde in dem Quote oben nicht mehr als Begründung), so ist das bereits machbar. Hat aber wiederum nichts mit HB zu tun.

Thomas wrote:Es ist für die meisten Programme, die aus irgendwelchen Gründen nicht im Benutzerkontext laufen, einfach nicht nötig dass diese mit Administratorrechten gestartet werden. Sollte diese Programme (nicht das angeführte Beispiel) selber Programme o.ä. starten, laufen diese wiederum mit Adminrechten...usw. Thunderbird und Firefox zum update sind tatsächlich solche Beispiele. Warum nicht mit Adminrechten? Weil es nicht nötig ist und jeder Prozeß der unnötig mit Amdinrechten läuft ein zusätzliches Risiko darstellt.

Du behauptest, daß Admin-Rechte nicht nötig und HB-Rechte für die meisten Programme ausreichend sind. Wie willst du deine Behauptung denn beweisen? Das ist völlig unmöglich mangels entsprechender Dokumentation. Daß du selbst die meisten Programme (die es gibt, nicht nur die, die du kennst) selber darauf untersucht hast, stelle ich in Abrede. Womit die Haltlosigkeit der Behauptung schon klar auf der Hand liegt. Aber selbst das einmal hypothetisch zugestanden: Was hilft das einem Benutzer, bei dem das betreffende Installationsprogramm mit HB-Rechten ausgeführt nur noch Schrott hinterläßt? Er hat eine Baustelle, die erst so richtig langatmige Reparaturen mit vollen Admin-Rechten erforderlich machen, also das genaue Gegenteil von sicher. Erfahrungsgemäß wird anschließend das betreffende Programm oder SuRun als Schuldiger angeprangert, "denn das hat das ja erlaubt". (Ich stelle mir gerade einen Geisterfahrer vor, wegen dem es ein paar Tote gegeben hat und der darauf erklärt: "Die meisten leben aber noch".)

Sollte das Installationsprogramm zu Beginn den Typ des aktuellen Kontos prüfen, so wird es gar nicht erst laufen sondern mit dem Hinweis auf erforderliche Admin-Rechte stoppen. Nur kann man sich nicht darauf verlassen, daß diese Kontrolle eingebaut ist und meinen, daß ohne dem die Installation mit HB-Rechten funktioniert. Es interessiert heute keinen mehr (schon gar nicht Leute, die ihre aktuelle Software verkaufen wollen), was auf NT4-Systemen passiert. Bestenfalls findet man NT4 in vielen Fällen nicht als unterstütztes OS angegeben. Und HB ist eine NT4-Kompatibilitäts-Schnittstelle und nichts anderes.

Es ist falsch und ein Ausdruck falschen Verständnisses (sagte ich schon, daß du die Literatur mal lesen solltest?), wenn du das Ausführen von vertrauenswürdigen Programmen (siehe Beispiele) für legitime Zwecke mit Admin-Rechten per se als zusätzliches Risiko darstellst. Welches Risiko denn? Und welche Prozesse startest du aus dem Update-Installer von Thunderbird (zum Beispiel)? Vernünftigerweise keinen. Und ich vertraue diesem Programm (wiederum als Beispiel), daß es ebenfalls keine als den zum Zweck des Update erforderlichen startet, anderenfalls würde ich ihm nicht meine Mails anvertrauen.

Jeder Windows-Rechner läuft mit etlichen Diensten, also administrativ ausgeführten Programmen. Es gibt jede Menge obskurer Empfehlungen, alle möglichen MS-Dienste abzustellen. Und es gibt jede Menge Systeme, die anschließend nicht oder fehlerhaft laufen. Stellen diese Dienste per se ein Risiko dar? Nein, es sei denn es lägen Programmfehler oder nicht installierte Updates (weil zum Beispiel der erforderliche Dienst für AU deaktiviert wurde) vor, aber dann reicht das HB-Männchen zum Kompromittieren völlig aus. EDIT: Die Frage lautet also nicht, ob ein Programm mit administrativen Rechten läuft (wenn das nämlich so einfach wäre, dürfte man kein OS der Welt verwenden, weil sie nämich darauf angewiesen sind), sondern ob das administrativ ausgeführte Programm im Zusammenhang mit der aktuellen Aufgabe (Update ist OK, Mails lesenen oder Browsen nicht) einen Schadcode ausführen wird. Tut es das nicht, dann passiert ... na was wohl: Nur das, was passieren soll (zum Beispiel das Update), und nicht mehr. [1]

Das kann man auch nicht damit "beweisen", indem man jetzt Schubladen mit "HB-Haßern" und Freunden konstruiert. Aber bitte, wenn du meinst, das tlu und ich einen Club bilden, wir befinden uns da in guter Gesellschaft, denn nach deiner Einteilung gehört merkwürdigerweise auch Microsoft zu den HB-Haßern. Mit der Gesellschaft kann ich leben. Und habe damit auch gleich noch die ausdrückliche Bestätigung von dir, daß du dich im Widerspruch zur MS-Dokumentation befindest. Auch das ist ja nichts verbotenes, aber dann muß man schon sachlich dagegen argumentieren, und zwar Punkt für Punkt. Daß die Tatsache, daß du dich in den Widerspruch zu MS manövriert hast, irgendeinen Anspruch auf solide Begründung darstellen soll, erschließt sich mir nicht.

Kay wrote: Hmmm.

Der Punkt ist: Bietet SuRun HB als Option an, so wird es benutzt werden. Die Benutzer werden damit Schiffbruch erleiden; es ist gar keine Frage, ob es passiert, sondern nur wann. Es wird korrumpierte Systeme geben, weil die Option zur Unzeit benutzt worden ist - und sei es nur deswegen, weil sie vergessen haben, für eine kritische Installation vom HB wieder auf Admin umzustellen oder aus Gewohnheit im Dialog (wie immer es auch angeboten wird) dieses mal eben doch nicht Admin statt HB zu wählen. Und die Benutzer werden - nicht völlig zu Unrecht - argumentieren, daß die Option ja da sei und einen Sinn machen müsse; anderenfalls sei sie ja sinnlos. (Eben) Und deswegen werden sie SuRun zumindest eine Mitschuld für ihr nicht funktionierendes Programm oder im Murphy-Fall korrumpiertes System geben.

Übrigens: HB würden genau diejenigen benutzen, die ihn nicht verstanden (wenn überhaupt etwas darüber gelesen) haben. Sieht nicht wie eine Zielgruppe aus.

Der Hauptbenutzer ist technisch einem Moderator gleichzusetzen, einem Begriff, den aus dem Forenbegriff die meisten kennen dürften. Es ist kein eingeschränkter Kontotyp, sondern ein impotenter Administrator. Er kann Schadsoftware nicht aufhalten, aber viel Schaden anrichten. Dafür eine Option anzubieten, beurteile ich als falsch.


[1] Es gibt bekanntlich Update-Muffel. Ich sehe schon die neue "Begründung": Ich habe nicht upgedatet, weil ich das automatische Update abgeschaltet habe, um administrative Prozesse einzusparen und ich auch nur einmal im Jahr in das Admin-Konto zum manuellen Update gehe, um das Risko zu reduzieren." Herr, laß Hirn regnen.

Auf Grund der Beitragslänge und der Formulierungen könnte sich sogar der gleiche hinter dem Benutzer verbirgt, der mir auch im usenet geantwortet hat, ist aber egal. Ob hier oder da hat so eine Diskussion offenbar keinen Zweck, in diesem Stil ("Herr, laß Hirn regnen") diskutiere ich nicht und lasse mich auch nicht provozieren.

Meine Bitte an Kay bleibt, er hat offenbar erkannt dass es von Vorteil sein kann, nicht jedes Programm, dass nicht mit Benutzerrechten funktioniert oder kein update gestattet, immer mit Administratorrechten zu starten.

Vielen Dank und auf Wiedersehen.

Thomas

ich werd auch mal stellung beziehen:

ich halte von dem acc 'Hauptbenutzer' sowenig,
dass ich ihn gleich nach der windowsinstallation lösche...

und ich sehe auch keinen sinn ihn in SuRun einzubeziehen

...ich teile Cosmos meinung,
die texte mögen etwas lang sein aber das ist auch nötig.

Cosmo wrote:

Thomas wrote: statt "ausführen als" lieber "surun" zu nutzen ist dass es Software geben könnte die das Admin PW mitloggen könnte...

...
Wenn von einer eingesetzten Software nicht ausgeschlossen werden kann, daß sie das PW mitloggt, so ist sie nicht bekannt (per Definition).

Das hast Du bestimmt falsch verstanden. Auch als Gast laufende Schadsoftware kann einen Hook einrichten und von "Ausführen als..."(RunAs) das Kennwort erhaschen. Mit SuRun und mit SuRuns RunAs geht das nicht.

Allerdings hat das nix mit HB zu tun.

Cosmo wrote: Oder sollte auf dem Rechner virulent eine solche SW laufen, ohne daß der Benutzer das weiß? Dann gäbe es auf dem Rechner allerdings ein kardinales Sicherheitproblem und die Gesamt-Konfiguration wäre fehlerhaft.

Es ist schwer, sich z.B. gegen bezahlte Flash-Werbung mit Viren drin zu wehren.
Die meisten sind damit überfordert und sehen nur bunte Filmchen.
Dass Flash code ausführt, der sich nicht dauerhaft installieren, aber z.B. durch RunAs oder "Neuer Hardware gefunden" ein Admin-Kennwort erhaschen kann, ist kaum zu vermeiden.

...Das hat auch nix mit HB zu tun...

Cosmo wrote: Denn wie soll sich Schad-Software auf einem richtig konfigurierten und verwendeten System einnisten?

Es reicht schon, wenn sie läuft, sie muss nicht nisten. Jedes erspähte Kennwort ist eins zuviel. Es gibt Prognosen, die besagen, dass sich ein Wurm gar nicht mehr einnisten werden wird. Er läuft, solange der Browser läuft, im Browser-Prozess selbst und benutzt dessen Internet-Verbindung direkt durch die Firewall. Durch gezielte Werbung und aktive Inhalte ist das leicht und bleibt eher unentdeckt.

...jepp, hat nix mit HB zu tun...

Cosmo wrote: Es ist falsch und ein Ausdruck falschen Verständnisses wenn du das Ausführen von vertrauenswürdigen Programmen (siehe Beispiele) für legitime Zwecke mit Admin-Rechten per se als zusätzliches Risiko darstellst.
Welches Risiko denn?

Da hätte ich was: Ein als Admin laufendes Programm kann leider auch von Gästen Ferngesteuert werden.
Man kann auf dessen Menüs klicken und z.B. den Öffnen-Dialog zum Ausführen von Software missbrauchen.
Unter Vista soll das Problem durch die Integritäts-Level behoben sein. (Ich hab es noch nicht ausprobiert)

All das ist recht theoretisch und ...hat mit HB nix zu tun.

Cosmo wrote: Und welche Prozesse startest du aus dem Update-Installer von Thunderbird (zum Beispiel)?

Das ist auch ein riesen Problem: Installer haben den "Programm jetzt starten"-Knopf, den nicht-Experten leider drücken. Das beschränkt sich nicht nur auf Mozilla-Produkte (die in Vista übrigens nach der Installation vorbildlich das Programm als nicht-Admin starten), ich sehe den Blödsinn bei fast allen. Erst wollen die einen Admin zum Installieren, dann das Programm direkt starten... Mit Vernunft und Verständnis hat das nix zu tun, es ist nur halt so.

Nun aber mal zur Hauptbenutzer-Gruppe:

Ich sehe bisher auch keinen großen Sinn im Ausführen als HB, weil er dafür zu wenige Rechte hat. Was ein HB kann, kann man auch durch Ändern der Zugriffsrechte erreichen (vom Profilieren mal abgesehen), aber auch dieses Privileg kann man im Gruppenrichtlinien-Editor erteilen.
Ich sehe allerdings auch keine größere Gefahr, wenn man ein Programm als HB statt als Admin startet.
Man sollte ganz klar immer mit so wenigen Privilegien, wie nötig arbeiten, also als Benutzer oder Gast. ;-)

Das ganze Gruppen-Gedöhns würde ich eh' nur programmieren, wenn man nicht nur zwischen Admin/HB/Benutzer/Gast umschalten könnte, sondern die einzelnen Privilegien und Benutzer-/System-Gruppen für das Programm festlegen kann. Dann wäre das universell und man kann sich alles erteilen bzw. entziehen, was man will.

Allerdings ist das nun wieder nur was für Experten.

Ich denke, es ist wohl fürs Erste gut, so wie es ist.
Ich nehme die Diskussion hier als Anregung, die im Hinterkopf steckt, wenn wieder etwas umgebaut werden muss/soll. Mit SuRun 1.2.0.7 wird (hoffentlich) der Benutzer pro Programm auswählbar sein. In diese neu zu schaffenden Strukturen gleich Gruppen und Privilegien einzuplanen ist sicherlich nicht verkehrt, auch wenn das erstmal nicht benutzt wird.

n8

Kay wrote:

Cosmo wrote:

Thomas wrote: statt "ausführen als" lieber "surun" zu nutzen ist dass es Software geben könnte die das Admin PW mitloggen könnte...

...
Wenn von einer eingesetzten Software nicht ausgeschlossen werden kann, daß sie das PW mitloggt, so ist sie nicht bekannt (per Definition).

Das hast Du bestimmt falsch verstanden. Auch als Gast laufende Schadsoftware kann einen Hook einrichten und von "Ausführen als..."(RunAs) das Kennwort erhaschen. Mit SuRun und mit SuRuns RunAs geht das nicht.

Ich habe zu meiner Schande und Verärgerung festgestellt, daß ich einen ganz anderen Fehler gemacht habe, dazu mehr am Ende.

Hier allerdings habe ich nichts mißverstanden. Unter erstens habe ich den Fall beantwortet, wenn die per RunAs / Surun gestartete Software selber schnüffelt und habe gesagt, daß eine SW, die man nicht kennt und der man nicht vertrauen kann, auf einem Produktivrechner nicht hin gehört. In Post #3 hatte ich auch schon den Hinweis auf eine isolierte Testumgebung genannt. Für den Fall, den du wahrscheinlich mit "als Gast laufende Schadsoftware" meinst, habe ich unter zweitens geantwortet. Auf den letzten Aspekt war ich unter fünftens eingegangen.

Kay wrote:

Cosmo wrote: Oder sollte auf dem Rechner virulent eine solche SW laufen, ohne daß der Benutzer das weiß? Dann gäbe es auf dem Rechner allerdings ein kardinales Sicherheitproblem und die Gesamt-Konfiguration wäre fehlerhaft.

Es ist schwer, sich z.B. gegen bezahlte Flash-Werbung mit Viren drin zu wehren.
Die meisten sind damit überfordert und sehen nur bunte Filmchen.
Dass Flash code ausführt, der sich nicht dauerhaft installieren, aber z.B. durch RunAs oder "Neuer Hardware gefunden" ein Admin-Kennwort erhaschen kann, ist kaum zu vermeiden.

Wenn Flash funktioniert, dann tut sie das nur, wenn man es ihr erlaubt, das Konto also mit entsprechenden Einstellungen läuft. Die aber haben mit SuRun (ergo auch mit Thomas' Wunsch) nun überhaupt nichts mehr zu tun, deswegen habe ich das nicht weiter vertieft. Mik hat ja schon freundlich umschrieben, daß meine Antworten von der Länge her grenzwertig sind, noch länger (und letztlich off topic) wollte ich es nun nicht auch noch werden lassen.

Kay wrote:

Cosmo wrote: Denn wie soll sich Schad-Software auf einem richtig konfigurierten und verwendeten System einnisten?

Es reicht schon, wenn sie läuft, sie muss nicht nisten. Jedes erspähte Kennwort ist eins zuviel. Es gibt Prognosen, die besagen, dass sich ein Wurm gar nicht mehr einnisten werden wird. Er läuft, solange der Browser läuft, im Browser-Prozess selbst und benutzt dessen Internet-Verbindung direkt durch die Firewall. Durch gezielte Werbung und aktive Inhalte ist das leicht und bleibt eher unentdeckt.

Aus vorgenanntem Grund bin ich wie gesagt nicht auf Konto-interne Dinge, einschließlich Benutzer-Prozesse eingegangen, hier geht es um das System. Wenn Schad-Software als System-Prozeß im Benutzerkonto läuft, muß sie sich zuvor eingenistet haben. Was vielleicht etwas sehr kurz, aber siehe oben.

Kay wrote:

Cosmo wrote: Es ist falsch und ein Ausdruck falschen Verständnisses wenn du das Ausführen von vertrauenswürdigen Programmen (siehe Beispiele) für legitime Zwecke mit Admin-Rechten per se als zusätzliches Risiko darstellst.
Welches Risiko denn?

Da hätte ich was: Ein als Admin laufendes Programm kann leider auch von Gästen Ferngesteuert werden.
Man kann auf dessen Menüs klicken und z.B. den Öffnen-Dialog zum Ausführen von Software missbrauchen.

Es gibt keine Software, die einerseits Privilegien einräumt (wie SuRun das tut), andererseits aber verhindern soll, daß der Mensch vor der Tastatur sei es aus Sabotage oder überquellender Dummheit den Rechner kompromittiert, deswegen war ich nicht darauf eingegangen. Aber in dem von dir zitierten Satz ging es ja um den erhöhten Prozeß (von dem an dieser Textstelle ausgegangen wird, daß er selbst gutartig sei), und dieser Prozeß stellt keine Risiko dar. Außerdem: Sitzt da tatsächlich ein Saboteur oder selten Dummer vor dem Rechner, so kann er als HB-Männchen genug Schaden anrichten, mithin hilft der HB-Vorschlag auch da nichts.

Übrigens, ich bin nie auf die Idee gekommen überhaupt auszuprobieren, einem Gastkonto erhöhte Privilegien mit SuRun einzuräumen und betrachte das auch als nichts, was mir auch nur Minuten Zeit zum Ausprobieren Wert ist. Wenn der Benutzer nicht einmal ein eigenes Konto hat sondern sich anonym am Rechner anmelden kann, dann ist doch schon aus dieser Definition klar, daß ich in diesem Fall beim Benutzer kein Vertrauen gewähren kann. Erhöhte Rechte ohne Vertrauen ist aber nichts anderes als der Rückfall in die Zeiten von W98.

Kay wrote:

Cosmo wrote: Und welche Prozesse startest du aus dem Update-Installer von Thunderbird (zum Beispiel)?

Das ist auch ein riesen Problem: Installer haben den "Programm jetzt starten"-Knopf, den nicht-Experten leider drücken. Das beschränkt sich nicht nur auf Mozilla-Produkte (die in Vista übrigens nach der Installation vorbildlich das Programm als nicht-Admin starten), ich sehe den Blödsinn bei fast allen. Erst wollen die einen Admin zum Installieren, dann das Programm direkt starten... Mit Vernunft und Verständnis hat das nix zu tun, es ist nur halt so.

Hier wird es wirklich spannend und da könnte man zu Recht ausgiebig darüber diskutieren. Ich möchte aber diesen Thread nicht für eine solche Diskussion benutzen, deshalb nur kurz: Wir haben hier mal einen schönen Punkt wo sich die Frage stellt, ob es richtig ist, als SuRunner alles inklusive Installationen zu machen, wozu man erhöhte Rechte braucht, oder eben - meine von Anfang an vertretene Meinung - klar zwischen Systemaufgaben und SuRunner-Funktionen zu trennen, also die Diskussion Surun / RunAs. Wobei ich noch einen Schritt weitergehe und Installationen im(!) Admin-Konto mache. Damit (das gilt natürlich auch für RunAs) wird es zumindest unmöglich, das Programm gleich für den Benutzer einrichten zu wollen, sofern die Konfigurationsdaten Benutzer-getrennt gespeichert werden.

Noch einmal zur Klarstellung: Ist die SW als vertrauenswürdig bekannt, so ist das von dir beschriebene Verhalten zwar potentiell unerwünscht, aber nicht wirklich gefährlich. Im Gegenteil: Wenn die Software erst beim ersten Start bestimmte Dateien (zum Beispiel Konfigurationsdateien) im Programmordner erstellt - und davon gibt es immer noch reichlich - so muß ich das Programm als Admin einmal starten, um die dann erstellten Dateien für Benutzer zum Schreiben freizugeben; anschließend funktionieren nach meiner Erfahrung die meisten Programme ohne erhöhte Privilegien.

Wie gesagt, daß ist ein reiches Thema, aber bitte nicht in diesem Thread.

Kay wrote:Nun aber mal zur Hauptbenutzer-Gruppe:

Ich sehe allerdings auch keine größere Gefahr, wenn man ein Programm als HB statt als Admin startet.

Sofern es sich um bereits zuvor installierte Programm handelt, gebe ich dir zu 99% recht. (Man soll niemals nie sagen.) Es wird entweder reichen oder das Programm wird nicht damit richtig funktionieren, aber es sollte meistens kein großer Schaden auftreten. Doch warum dieses, und sei es ein noch so kleines Restrisiko eingehen, wenn es dafür keinen vernünftigen Grund gibt? Ist das Programm koscher, passiert mit Admin-Rechten so wenig wie mit HB-Rechten, ist es nicht koscher ... nun, das hatten wir ja schon. Ist der Benutzer nicht koscher ... hatten wir auch.

Aber ich erinnere dich daran, daß Thomas bei seinem HB-Wunsch das Installieren von Programmen in den Vordergrund gestellt hat. Und da ist das Risiko nicht abschätzbar, wie ich IMHO ausreichend dargelegt habe.

Aber es kommt aber noch viel schlimmer und ich ärgere mich heute darüber, daß ich da nicht schon gestern darauf gekommen bin. Folgendes:

Daß das Installieren als Admin-SuRunner funktioniert, ohne das System der Kompromittierung frei zu geben, liegt bekanntlich daran, daß die Besitzer-Option aktiviert ist. Diese Einstellung ist unter XP Pro auch über die Richtlinien einstellbar. Aber - und jetzt wird es wirklich Zeit, das HB-Männchen zu Grabe zu tragen - für andere Kontentypen gibt es dort eine solche Einstellung nicht! Und ohne eine solche Einstellung bedeutet das im Klartext:

Mit dem Umsetzen von Thomas' Wunsch würde in dem Zustand, wie er ist, das gesamte Prinzip der Rechtetrennung für alle Programme unterlaufen. Es spielt danach gar keine Rolle mehr, ob der Benutzer die Programme als SuRunner ausführt oder als vermeintlich - in Wirklichkeit aber nicht mehr - eingeschränkter Benutzer. Als Besizer darf er - und was viel schlimmer ist: auch unter der Shell startende Schad-Software - ja mit den Programmdateien und mit den entsprechenden Registry-Schlüsseln machen, was immer er will. Thomas' Vorschlag, der in der wohlgemeinten Absicht, die Sicherheit zu erhöhen, entstanden ist, wäre also im Ergebnis das genaue Gegenteil. Es wäre das Unterlaufen der in modernen OS inhärenten Sicherheit durch Rechte-Trennung. (Alte Weisheit: Gut gemeint ist nicht gut gemacht.)

Mein Fehler war, daß ich das in dieser Konsequenz gestern nicht so heraus gearbeitet hatte, ansonsten hätte mein mit drittens eingeleiteter Absatz einen anderen Inhalt gehabt.

Also, bitte vergiß es. Der kastrierte Admin aka Moderator aka HB ist nicht nur ein Risiko korrumpierter Systeme wegen möglicherweise unvollständigen Installationen, wo ein Teil von Registry-Einstellungen zu anderen Teilen der Installation nicht mehr zusammen paßt, er untergräbt die Systemsicherheit grundlegend. Sollte diese Option jemals in SuRun auftauchen, so werden - Doku hin oder her - Leute mit Halbwissen das auch "ausprobieren". Auch auf die Gefahr hin, daß das folgende arrogant klingt: Ich habe 1 Tag gebraucht, um das in dieser Deutlichkeit zu sehen, die Mehrzahl der SuRun-Benutzer werden es frühestens erkennen, wenn es zu spät ist. Also wäre bereits das Angebot in SuRun ein kapitaler Fehler. (Der darüber hinaus aus genannten Gründen keine Daseinsberechtigung hat, weil die scheinbaren Vorteile auf einer Illusion beruhen.)

Das war in der Tat lang. :huh:

Die Implementation einer "Admin mit definierten Rechten"-Option in SuRun würde natürlich bedeuten, dass auch der Besitzer erstellter Objekte festgelegt werden kann. Der Token, mit dem ein Prozess gestartet wird beinhaltet u.A. die Gruppen, zu denen der Benutzer gehört, Privilegien Logon-Id usw. Da SuRun den Token selbst erstellt, kann es da auch eintragen, was es will. Das kann man also benutzen, um Programmen fast beliebige Zugehörigkeiten und Privilegien zu geben... nur komplex wäre das auch.

Ich lass es lieber weg ;-)

Ganz kurz: Bravo!

Nee, ich kann es mir doch nicht verkneifen: Der "definierte Admin" ist natürlich ein anderer Kontentyp als der HB. Mit dem "mitgelieferten" HB geht es AFAIK nicht.