1.1.0.3 Beta Kurztest!

2 Dinge vor der Veröffentlichung: Punkt 1 sollte (bitte) unbedingt noch berücksichtigt werden, Punkt 2 vielleicht erst später (?):

Punkt 1: Also, ich habe lange und genaues Hinsehen gebraucht (am Abend bei Dunkelheit), bis ich erahnen konnte, daß im Admin-Konto das Tray-Symbol orange und nicht rot ist. Ich gebe ja zu, daß an meinen nicht mehr ganz jugendlichen Augen liegt, aber es hilft nichts, so ist der Unterschied für mich nicht wirklich vorhanden. Ich hatte Kay allerdings auch so verstanden, als ob er da radioaktiv nehmen wollte und würde nach der letzten Erfahrung auch dringend dafür plädieren.

Punkt 2: Noch einmal zurück zu dem Problem, daß man mit surun ein Administrator-Konto benutzen kann, auch wenn dieses kein Paßwort hat, wie es zumindest bei dem vordefinierten Konto Administrator typischerweise der Fall ist. Dieses Problem betrifft nicht nur den Befehl "Ausführen als", wenn man surun statt des Windows-eigenen Befehls dafür verwendet, es betrifft auch das Hinzufügen des eigenen Kontos zur Surunner-Gruppe. Solange es ein einziges - vielleicht auch nur irrtümlich - nicht mit Paßwort geschütztes Konto mit Admin-Rechten gibt, kann sich jeder Benutzer hemmungsfrei zu dieser Gruppe hinzufügen und somit letztlich vollständige Kontrolle über das System erlangen und die ganze Trennung zwischen den Berechtigungen von Benutzern wird hinfällig. Deswegen sehen ich das als erhebliches Sicherheitsrisiko! Was ich vor einigen Tagen, als ich zum ersten Mal auf diese Thematik eingegangen war, völlig vergessen hatte: Mit dem Windows-eigenen Befehl "Ausführen als" ist es nicht möglich, ein Administrator-Konto zu verwenden, daß kein Paßwort besitzt; deswegen existiert dort dieses Sicherheitsloch nicht. (Man könnte(!) sogar so weit gehen, daß das ein Sicherheitsvorteil ist, denn ein nicht existierendes Paßwort kann ja auch nicht erspäht oder erraten werden.)

Konsequenz: Wenn es möglich ist, ein nicht Paßwort-geschütztes Konto nicht verwendbar zu machen, so sollte das auch bei Surun so sein. Damit wäre nicht nur diese Sicherheitslücke beseitigt, es würde auch der Zwang (den ich damals beschrieben hatte) entfallen, ein Paßwort zu setzen, das man eigentlich gar nicht setzen will. (Daß es dennoch ratsam ist, steht auf einem anderen Blatt.)

Kay wrote:SuRun müsste warnen, falls irgend ein Admin Konto im System ein leeres Kennwort hat und die "Konten: Lokale Kontenverwendung von leeren Kennwörtern auf Konsolenanmeldung beschränken" Sicherheitsrichtlinie für Admin-Konten beibehalten.

Genau so: beides: Sowohl warnen und Sicherheitsrichtlinie auswerten.

Wie ich schon schrieb: Wer Wert auf ein sicheres System legt, muß die leeren Paßwörter entfernen; das ist sinnvoller, als sich eventuell 1001 "Sicherheitsprogramme" zu installieren. Deshalb wäre - neben dem bereits beschriebenen Aspekt der Dokumentation - es sinnvoll, wenn Surun in der besagten Warnung etwa folgendes ausgeben würde: "Einige Konten (oder: betreffende Konten namentlich aufgeführt; bezogen auf Konten mit Admin-Rechten) haben kein Paßwort. Sie sollten für diese Konten ein Paßwort vergeben. Siehe dazu die Dokumentation."

Kay wrote: Mir ist nichts bekannt, wie sich ein anderer Desktop neu zeichnen lässt ohne auf ihn umzuschalten.

Dann bitte wieder so wie vorher, da war das Flickern erträglicher...

Kay wrote: Aus dem Hook heraus kann man ExitProcess() aufrufen, das ist "lieb".

So richtig lieb aber auch nicht, da Änderungen vom Programm nicht gespeichert werden. Z. b. mal in Notepad was tippen, dann "Neustart als Admin", weg ist das getippte ;)
Wäre es nicht besser, zum Beispiel PostQuitMessage() zu nehmen? Nur ne Idee.

Kein Bug zu sehen in der letzten Beta.

Aber: Ich plädiere sehr stark dafür, die Warnung (Punkt 1 des Changlog) nur bei der Anmeldung von Administratoren zu zeigen, nicht bei der Anmeldung von Surunnern. Diese würden dadurch erst auf die Idee gebracht werden, das Konto zu okupieren (= sich dort anmelden, eigenes Paßwort vergeben und damit für den legitimen Administrator unerreichbar machen und womöglich einiges noch schlimmeres mehr). Wenn der Administrator die Warnung (warum auch immer) nicht umgesetzt hat, muß man andere nicht auch noch darauf stoßen (zumal ein Nicht-Admin legitimerweise an dem Mangelzustand eh nichts ändern kann / darf).

Kay wrote:Nicht eingeschränkte SuRunner sind quasi Administratoren.

Das würde nichts verschlimmern, oder?

Ich räume ein, daß sich dazu unterschiedliche Meinungen vorstellen lassen, dennoch sage ich dazu ganz klar: Nein.

Stellen wir uns die Fragen, was ist ein nicht eingeschränkter Surunner?

Dazu fallen mir 2 Möglichkeiten ein:
1. Das Konto, daß sich ein Administrator anlegt, um als eingeschränkter Benutzer mit der sich daraus ergebenden Sicherheit am Rechner Alltagsarbeiten durchzuführen. Für diesen Fall wäre die Antwort Ja.

2. Das Konto eines Mitbenutzers, zu dem ich als Systemadministrator das Vertrauen habe, mit dem Rechner gut und verantwortungsvoll umzugehen und das nicht etwa deswegen keinen Administrator-Status hat, weil ich diesem Mitbenutzer etwas nehmen will, sondern weil sich auf einem Rechner nur 1 Administratorkonto neben dem vordefinierten befinden soll und dieser Mitbenutzer für seine Alltagsarbeiten ja ebenso den Selbstschutz des eingeschränkten Benutzers haben soll. Dieser vertrauenswürdige Mitbenutzer hat aber das Wissen und die Qualifikation, um verantwortungsvoll selbst Programme mit erhöhten Rechten auszuführen, wenn das zur Durchführung erforderlich ist und darf sich über die surun-Verwaltung diese Rechte wo erforderlich auch selbst erweitern. Dennoch ist er nicht der Administrator des Systems. (Viele Köche verderben den Brei, wobei der eine Koch nicht unbedingt schlechter als der andere sein muß.) Hier wäre die Antwort also Nein. Denn dieser Mitbenutzer wäre ja eben ein anderer Koch. Würde er jetzt den Fehler des fehlenden Paßwortes korrigieren wollen, so würde zunächst einmal das von ihm eingerichtete Paßwort den tatsächlichen Systemadministrator an dem Zugang zu diesem Konto ausschließen; man stelle sich vor, der vertrauenswürdige Surunner setzt das fehlende Paßwort und vergißt es dem eigentlichen Administrator mitzuteilen. Nach Murphy wird das erst dann bemerkt, wenn gerade keine Möglichkeit besteht, die fehlende Information auszutauschen. Unter Umständen könnten dadurch also massive Probleme entstehen

Nein, ein nicht eingeschränkter Surunner kann / sollte an dem Fehler nichts selber korrigieren, dennoch bekommt er bis zur Korrektur jedesmal diese Meldungsbox präsentiert, die er ebenso jedesmal erst wegklicken muß; so etwas nervt auf die Dauer bekanntlich ungemein.

Ein anderes Beispiel ist ein Testrechner, wie ich ihn auch einsetze. Das System ist völlig isoliert, es hat keinen Netzwerkzugang (und kann somit darüber keinen anderen Rechner schaden, aber auch keine Daten heimlich über das Internet verteilen), es befinden sich keine Daten darauf, die es zu schützen gäbe; mit anderen Worten: Der Schutzbedarf für diesen Rechner liegt um Größenordnungen unter dem von Produktivsystemen. Somit ist es durchaus in Ordnung, wenn ich dort das Administrator (vordefiniert)-Paßwort nicht setze. Surun würde mich aber, wenn ich dort in dem Konto des nicht eingeschränkten Surunners arbeite, mich bei jeder Anmeldung (und wie ich gesehen habe auch bei der Rückkehr unter Verwendung der Schnellen Benutzerumschaltung) jedesmal einfach nur nerven, weil ich die Meldung wegklicken muß.

Uff, sollte eigentlich gar nicht so lang werden, aber je länger ich darüber nachdenke, desto entschiedener ist meine Meinung.

Kay wrote: Auf ein hoffentlich letztes: :-D
* SuRun setzt "Ordnerfenster in einem eigenen Prozess starten" wieder zurück (siehe hier)
* Die "Admin hat leeres Kennwort"-Box ist nur für uneingeschränkte SuRunner und Administratoren zu sehen
* Der IAT-Hook ist per default AN

Kay

Hallo Kai,

ich habe massive Probleme mit den SuRun-Versionen von gestern (Montag) abend und heute vormittag
(zumindest hier auf meinem Dienst-PC, WIndows XP Pro SP3 RC2 refresh):

sobald SuRUn einmal einen sicheren Desktop erstellt hat (z.B. um die SuRun-Präferenzen zu edieren), produziert es bei folgenden Versuchen, eine Anwendung mi Admin-Rechte4n zu starten ein PopUp mit der Meldung:

Abbruch! Sicherer Desktop konnte nicht erstellt werden.

und danach der MEldung dass die fragliche, als Admin versuchte Anwendung nicht gestartet werden konnte.

EIn echter Show-Stopper... werde mal noch die Version von Sonntag probieren und sehen, ob die das auch macht...

- Clemens

Edit: auch die zweite (neukompilierte) Version vom Sonntag den 6.4.08 hat dieses Problem... probiere jetzt noch schnell die Version vom 3.4.08

Kay wrote: Hi Clemens,

ist das Problem weg, wenn Du den abgedunkelten Benutzer-Desktop als Hintergrund abschaltest?

Kay

muss ich probieren... komme aber erst am frühen nachmittag dazu...

haste mein Edit der vorangegangenen mail gesehen?

mit automagisch gestarteten Anwendungen mit Admin-Rechten gibt es anscheinend keine Probleme...

- Clemens

Kay wrote: Hi Clemens,

Ich hatte das auch mal, aber nach Abmelden/Neustart war es weg und kam nie wieder :-(
Ist das Problem weg, wenn Du den abgedunkelten Benutzer-Desktop als Hintergrund abschaltest?

Kay

ja nach einem Neustart habe ich jeweils einen Versuch mit Abdunkeln frei und danach werden abgesicherte Starts mit Abdunkeln abgebrochen...

- Clemens

Widerspruch:

Kay wrote:Der Normalfall ist wahrscheinlich der:
Admin installiert SuRun auf frischem Heim-System und wird zum SuRunner.

Nein, nach meinem Verständnis ist das nicht der Normalfall und sollte es auch auf keinem Fall sein; Gefahr für das System! Denn jetzt wäre de Folge, daß es typischerweise nur noch ein Konto mit Admin-Rechten gibt. Sollte das beschädigt werden, ist das System in der Regel nicht mehr reparierbar. Das vordefinierte und versteckte Administrator-Konto ist nichts anderes als ein Backup, um gegebenenfalls ein neues Administratorkonto zu erstellen, wenn das aktuelle beschädigt ist. Zu mehr sollte es nicht verwendet werden, damit dieses immer verwendbar bleibt. Der Normalfall ist für mich, daß das individuelle Administrator-Konto eben das bleibt und Benutzerkonten nach Bedarf zu Surunnern gemacht werden!

Kay wrote:Im Deinem zweiten Fall wird das System bewusst administriert und der Admin hat hoffentlich kein leeres Kennwort. Wenn doch, meldet er sich sicher vor dem SuRunner wieder an, bekommt die Nervbox, behebt das Problem.

Nein, der vertrauenswürdige Benutzer ist eben kein Administrator und soll auch keine Administrator-Aufgaben übernehmen; das würde nur nur zu Mißverständnissen führen. Er ist aber vertrauenswürdig und erhält deswegen das Recht, seine surun-Einstellungen selber verwalten zu können. BTW, normalerweise wäre es ein unverzeihlicher Leichtsinn, einem Surunner nicht einzuschränken. Denn solange er nicht eingeschränkt ist, kann er letztlich alles machen, inklusive den Administrator aus dem Rechner auszusperren.

Kay wrote:Für das "offline"-Testsystem braucht man eigentlich kein SuRun, aber da würde die Box natürlich nerven!

Doch, braucht man. Das Testsystem dient für mich beispielsweise dazu um festzustellen, ob ein neues Programm uneingeschränkt mit eingeschränkten Benutzerrechten funktioniert oder welche Änderungen gegebenenfalls erforderlich sind, damit es funktioniert. (Bei vielen Programmen reicht es aus, Benutzern das Recht zum Schreiben der INI-Datei im Programmordner zu erteilen.) Surun ist hier sehr hilfreich, weil ich solche Tests durchführen kann, ohne zum Ändern der Dateirechte jedesmal ins Admin-Konto wechseln zu müssen. (WinSUDO hat meistens den gleichen Nutzen, weil es für solche Änderungen am Dateisystem auf den Benutzerkontext nicht ankommt.)

Kay wrote:Also sollte die Box evtl. abschaltbar gemacht werden.

Aber nur für Nicht-Admins. Der Administrator soll nicht der Gefahr unterliegen, wegen abgeschaltetem Dialog das Problem zu übersehen.

Nachdem ich mir nunmehr die neuste Beta von heute angesehen habe, habe ich festgestellt, daß die Umsetzung zur Trennung zwischen eingeschränkten und nicht eingeschränkten Surunnern leider nicht gelungen ist. Ich hatte bei meinem vorigen Posting angenommen, daß das Kriterium für eingeschränkt / nicht eingeschränkt in der Option, die Surunner-Einstellugen ändern zu dürfen besteht. Nun sehe ich aber, daß du das Kriterium in der Option, nur festgelegte Programme als Surunner verwenden zu dürfen, gelegt hast. Sorry, aber das ist doch zimelich sinnfrei: Wenn der Surunner die Surunner-Einstellungen ändern darf, kann er diese Option jederzeit umstellen; also was bringt es dann? Man kann sich sogar die Frage stellen, ob die Trennung zwischen die beiden Rechten in den Surunner-Einstellungen überhaupt Sinn macht. Doch, sie macht, aber eigentlich nur, um bestimmte Einstellungen zu testen.


@cmb:
ich habe versucht, dein Problem nachzustellen, bin aber nicht fündig geworden. Will sagen, daß ich den von dir beschrieben Fehler nicht nachstellen kann. Vieleicht eine Frage des OS? Ich habe XP SP2

Kay wrote: Hi Clemens,

ich habe ein Plapper-SuRun gebastelt.
Das erzählt DbgView, warum der Desktop nicht erstellt werden kann.
Probierst Du das bitte mal aus?

Danke,

Kay

mach ich, sobald ich dazu komme... vermutlich nicht vor heute abend...

die Version vom 3.4.08 (17:24 (Datum der Installrun.exe) läuft übrigens ohne Probleme... alle späteren Versionen machen --- bei unveränderten Einstellungen --- die beschriebenen Schwierigkeiten

- Clemens