Einfache Einstellungen/Nice Level für nicht-Experten

cosmo

Edit(Kay): Dieses Thema wurde hier gestartet.

So, hier einmal mein Versuch, einige Gedanken für die Frage der nice level zusammen zu tragen.

Meine Grundüberlegung ist die, mit welcher Intention wird Surun verwendet. Meiner Meinung kann man hauptsächlich 2 Gruppen von Programm-Benutzern unterscheiden:

Gruppe A sind diejenigen, die Surun als das von MS vergessene Werkzeug verstehen, um den Umgang mit dem Rechner so sicher wie möglich zu machen und dazu bereit sind, bis zu einem gewissen Maß auch einen administrativen Aufwand zu betreiben. Gruppe B sind diejenigen, die in erster Linie genervt sind, daß sie in einem eingeschränkten Konto bestimmte Programme - wozu nicht zuletzt Spiele gehören - nicht ausführen können; diese Gruppe hat zwar von der Sicherheit durch die Verwendung eines eingeschränkten Kontos gehört, ist aber nicht bereit ein solches zu verwenden, wenn es nicht so einfach anzuwenden ist wie ein Admin-Konto. Die erschreckende Mehrheit von 80% der Wilders-Mitgliedern (2 dort veröffentlichten Umfragen zufolge) gehört zu dieser Surun-Kundschaft.

Aus dieser Einteilung (die bewußt sehr einfach und folglich grob gehalten ist) ergeben sich unterschiedliche Vorgehensweisen - und auch innerhalb der Gruppen wird es Unterschied geben. Man kann wahrscheinlich sagen, daß in der Gruppe A in vielen Fällen bereits getrennte Konten mit Admin- und begrenzten Rechten existieren und Surun dazu verwendet wird, die Rechte der zu Surunnern gemachten eingeschränkten Benutzer soweit wie erforderlich zu erhöhen. In Gruppe B vermute ich mehr diejenigen, die immer mit dem Admin-Konto gearbeitet haben und nach der Surun-Installation dieses zu einem Surunner machen. Daraus folgt aber weiter, daß Gruppe A vermutlich vielfach Erfahrung hat, wo die Grenzen des eingeschränkten Kontos liegen, während Gruppe B diese Erfahrung logischerweise fehlt.

Ich zähle mich zur Gruppe A. Daraus folgt, daß ich die vollen Einstellungsmöglichkeiten von Surun benötige. Ich würde einem eingeschränkten Konto - außer dem, das ich selber verwende - niemals unbegrenzte Surun-Rechte geben, sondern dezidiert dem Benutzer die Ausführung bestimmter Programme mit erhöhten Rechten einräumen. Je nach Vertrauensverhältnis und Kenntnis des einzelnen Benutzers würde ich die Surun-Verwendung entweder völlig transparent (keine Rückfragen, folglich auch keine Hooks, kein Tray-Symbol) oder mit diesen Hinweisen (aber weiterhin ohne Hooks) einrichten. Ich habe mich mit der Option der Besitzrechte von Admins beschäftigt und stehe nach einigen Überlegungen sehr skeptisch dazu; folglich kommt Surun für mich auch nicht in Frage, um Programme zu installieren, sondern entweder RunAs oder Kontenwechsel. Das alles verlangt aber einen Anwender, der sich mit der Materie intensiver beschäftigt (und als Folge auch über die entsprechende Erfahrung verfügen wird); das volle Surun-Einstellungs-Spektrum ist hier erforderlich und trifft hier auf den geeigneten Mann oder die geeignete Frau.

Gruppe B hat andere Anforderungen: Sie wollen, daß alle Programme laufen, Installationen inklusive. Das ganze muß so einfach wie möglich gehen, kompliziertere Optionsmöglichkeiten bergen mehr Risiken der Fehlkonfiguration als die Chance eines praktischen Nutzens. Das ist also die ideale Gruppe, bei der ich alle Optionen verbergen würde, die nicht zwingend erforderlich und das Risiko bergen, daß am Ende außer falschen Beschwerden nichts herauskommt. (Das in dieser Gruppe genug Leute sind, die sich statt dessen lieber mit nervenden HIPS-Popups und -Einstellungen beschäftigen, gehört zur Schizophrenie des Lebens.)

So eine reduzierte (aka nice) Einstellungsoption würde ich damit verbinden, auf den separaten Desktop für Surun zu verzichten (HIPS). Ebenso würde ich hier den Hook eingeschaltet lassen, denn in dieser Gruppe glaube ich, daß die Möglichkeit über Surun installieren zu können wichtiger ist; wahrscheinlich sind da auch mehr Gamer als Access-Anwender vorhanden. Für diese Gruppe ist die Vorgabe der Aktivierung der Eigentümer-Option natürlich zwingend. Zur Trennung der Optionen: Natürlich ist die Seite Surunner-Gruppe unverzichtbar. Die allgemeinen Optionen wird man für Gruppe B wohl alle vorgabegemäß aktivieren können; angezeigt werden barucht eigentlich nur die Auswahlliste, wem die Warnung über leere Paßwörter gezeigt werden soll. Von den erweiterten Optionen sehe ich nur die erste Gruppe mit den drei Optionen für Gruppe B als sinnvoll an (Vorgabe in allen Fällen aktiviert; die anderen würde ich alle vorgabegemäß für diese Gruppe deaktivieren, die Anzeige des Benutzerstatus für Benutzer wählen.

Kay

Ich hab's gestern schon gelesen... muss aber auch erst Gedanken sortieren.
Ich hoffe, heute Abend antworten zu können.
Muss erstmal das mit dem Installer testen und den WatchDog bauen.
Das mit der Desktop-Macke ist mir wichtig, schnell wegzubekommen, das mit dem Deadlock HIPS<->SuRun auch!

tlu

Cosmo:1209228096 wrote: Ich habe mich mit der Option der Besitzrechte von Admins beschäftigt und stehe nach einigen Überlegungen sehr skeptisch dazu; folglich kommt Surun für mich auch nicht in Frage, um Programme zu installieren, sondern entweder RunAs oder Kontenwechsel.

Cosmo bzw. Namensvetter, ich bin wahrscheinlich einfach zu blöd oder wir haben auf Wilders aneinander vorbeigeredet (vielleicht weil Englisch nicht unsere Muttersprache ist) ;-) . Kannst du mir noch mal auf Deutsch erklären, wie du zu dieser Meinung kommst - vielleicht verstehe ich's dann :-D . Soweit die Option Admin-Besitzrecht eingeschaltet ist, sehe ich kein Problem. Im Gegenteil sehe ich bei der Installation mancher schlecht programmierter Anwendungen über Runas oder das Admin-Konto das Problem, dass teilweise z.B. Autostarts während des Installationsprozesses ausschließlich z.B. im HKCU des Admin-Kontos gepeichert werden und der Benutzer sich nachher darüber wundert, dass die Anwendung nicht wie erwartet funktioniert. Das sollte eigentlich bei allen neueren Anwendungen nicht mehr so sein, aber manchmal kommen doch noch einige merkwürdige Dinge vor ... die bei der Installation über SuRun vermieden werden.

Über deine Vorschläge muss ich im Übrigen noch ein bisschen nachdenken ...

Gruß

Thomas

cosmo

Hallo Thomas,

also zu dem Thema, wo du mich oben zitiert hast.

Ich habe mir seit einiger Zeit die Frage gestellt, warum hat MS in XP das Besitztum für Objekte, die mit Admin-Rechten (genauer gesagt: von einem Konto, das zur Gruppe der Administratoren gehört, was bei einem Surunner ja temporär der Fall ist) erstellt worden sind, von ehemals (W2k) "Gruppe der Administratoren" auf "Ersteller" geändert und in w2k3 wieder zurück. Dazu gehört die Frage, welche Konsequenzen ergeben sich, wenn man die Einstellung - wie von Surun standardmäßig durchgeführt - ändert?

Nun, zunächst einmal scheint das für Admins keinen Effekt zu haben, denn Besitzer und Admins haben immer Vollzugriff, und infolgedessen spielt es für Admins keine Rolle, ob sie nun auch die Besitzer sind oder nicht. Wenn ein Surunner (gleichbedeutend mit temporär im Zusammenhang mit bestimmten Anwendungen zum Admin erhobenen Benutzer) Dateien erzeugt, muß man 3 Fälle unterscheiden:

Fall 1: Der Surunner installiert ein Programm. In diesem Fall ist es obligatorisch, das der Surunner nicht der Besitzer wird, sonst wäre das ganze Prinzip der unterschiedlichen Rechte im Dateisystem und Registrierung unterminiert. Für diesen Fall ist die von Surun standardmäßig geänderte Besitztum-Option (die XP sich wie w2k und w2k3 verhalten läßt) nicht nur richtig, sondern gar notwendig.

Fall 2: Der Surunner startet ein Programm, daß mit eingeschränkten Rechten nicht (fehlerfrei) funktioniert. Da ich kein Spieler bin, denke ich hierbei vor allem an Programme, die irgendwelche Dokumente (im weitesten Sinne) erstellen. Standardmäßig werden diese wohl irgendwo im eigenen Profilordner gespeichert werden. Hier nun verhält es sich für LUA genauso wie für Admins im gesamten System: Im Profilordner hat der Benutzer Vollzugriff, unabhängig davon, ob er der Besitzer ist oder nicht.[1] Insofern könnte man die Tatsache, daß der Benutzer mit der Surun-Standardeinstellung nicht der Besitzer der Dokumente wird (das ist dann eben auch die Gruppe der Administratoren) noch abtun. Besitz ist aber ein Attribut, daß man im NTFS-System auch für andere Zwecke (zum Beispiel Suche) benutzen kann. Unter Umständen können hier also Probleme entstehen. - Nun besteht die Festplatte aber nicht nur aus den Ordnerzweigen Windows, Programme und "Dokumente und Einstellungen". Wird ein Dokument nun - warum auch immer - an eine andere Stelle außerhalb des eigenen Profils verschoben (zum Beispiel als Backup), so bleibt der Besitzer der verschobenen Datei unverändert. Folge: Der Benutzer kann diese Datei nicht mehr verändern (zum Beispiel nicht durch Überschreiben updaten), obwohl er rein inhaltlich zweifelsfrei das tun können sollte und auch keine Sicherheitsgründe dagegen sprechen. Zumindest kann er das nicht mit den Rechten eines LUA; folglich müßte er einen Dateimanager oder den Windows Explorer als Admin starten. Doch ein als Admin gestarteter Dateimanager ist fast so mächtig wie ein völlig uneingeschränktes System. Will ich als Administrator aber meinen Surunnern nur den privilegierten Start solcher Programme erlauben, bei denen das zur Durchführung der vorgesehenen Aufgaben unvermeidlich ist, kommt ein Dateimanager nicht in Frage. Die einzige vernünftige Lösung besteht also darin, daß der Ersteller auch tatsächlich zum Besitzer wird.

Fall 3 ist eine Verschärfung von Fall 2: Her wird das Dokument sofort in einen Ordner außerhalb des Profils gespeichert. Außer Lesen kann der Benutzer nun überhaupt nichts mehr damit anfangen. Soll die Datei zum Beispiel durch ein anderes Programm, das zur Durchführung keine erweiterten Rechte benötigt, weiter bearbeitet werden, so muß er die Datei zuerst einmal kopieren (die Kopie hat den Ersteller als Besitzer). Nicht nur, daß der Aufwand steigt, sondern es werden auch mehrere Kopien von einer Datei erzeugt, obwohl man aus inhaltlichen Gründen nur eine Version haben möchte und die Verwirrung nach einiger Zeit, welche Datei ist denn nun die "richtige" (was sich nicht immer aus dem Dateidatum beantworten läßt) nimmt zu. Ferner kann ein Benutzer von einer solchen Datei kein Backup nach den Regeln effektiven Backups durchführen, denn dazu gehört, daß das Backup-Programm das Archiv-Attribut beim Sichern löschen darf; aber auch das kann der LUA nicht (es sei denn, man würde mehr oder weniger aufwendig die Rechte nachträglich immer wieder anpassen).

Zurück zu der Frage, warum hat MS bei w2k3 wieder die Version von w2k gewählt? Ich weiß es nicht, habe aber folgende Vermutung: w2k3 ist ein Serverbetriebssystem, das primär nicht dafür konzipiert ist (wenngleich technisch möglich), daß hier Benutzer lokal am Rechner arbeiten. Es wird folglich in den meisten Fällen keine Dokumenten-Dateien geben. Was auf dem Server liegt, sind - soweit lokal erzeugt - Teile des Betriebssystems und Programme; der Rest sind über das Netzwerk zugespielte Daten. XP ist aber ein System, wo Benutzer körperlich vor dem Rechner arbeiten und eben auch Dokumente erstellen. Nach den Vorstellungen von MS - die ich diesbezüglich teile - sollen Anwender sich nicht als Admins anmelden, um mit dem Rechner zu arbeiten; wenn ein Admin aber dennoch einmal Dokumente erstellt (zum Beispiel um bestimmte Konfigurationen zu dokumentieren), so wird aus dem Besitzstatus klar, von wem das stammt. Wie ich schon einmal schrieb, hat MS die Surun-Variante zum temporären Erhöhen eines LUA anscheinend vergessen und nicht bedacht (obwohl das beim Blick in die Unix-Welt klar geworden wäre), daß RunAs alleine nicht ausreicht. Durch dieses Versäumnis ist das Problem mit der Möglichkeit, daß ein (für MS nicht bekannter) Surunner ein Programm installieren und damit dessen Besitzer werden könnte, gar nicht erst in Erwägung gezogen worden. Bei RunAs spielt diese Besitztumsfrage keine Rolle, denn damit wird im Zweifelsfall ein Admin zum Besitzer - unter Sicherheitsaspekten kein Problem.

Wenn ich also einige Postings zuvor geschrieben habe, daß für die dort genannte Gruppe B die aktuelle Besitzoption on Surun bleiben sollte wie sie ist, so habe ich dabei an Leute wie unserem Freund Easter gedacht, aber auch an die Leute, die Kay überhaupt dazu gebracht hatten, Surun zu schreiben; Leute also, bei denen im Zweifelsfall nach der Surun-.Installation das Admin-Konto zum Surunner downgegradet wird. (Kay hatte die "Geschichte" der Entstehung von Surun vor kurzem in einer Antwort an mich kurz skizziert - ich glaube es war im Beta-Forum zur letzten Version 1.1.0.3.) Gruppe A sind nach meiner einfachen Einteilung die Profis, deren Ansprüche höher sind. Hier sehe ich die richtige Vorgehensweise so, daß man Surun dort (und nur dort) einsetzt, wo es um Programme geht, die im eigenen Kontext laufen müssen(!), für andere Aufgaben (Installation, Systempflege) ist RunAs (oder von mir eingesetzt: WinSUDO) der richtige Weg. Wenn man das richtig trennt, braucht man die Standardeinstellung von XP bezüglich des Besitzes der von Admins erzeugten Objekte nicht zu trennen und erspart sich unter Umständen eine Menge Probleme, die daraus folgen.

P.S. Die oben beschriebenen Gedankengänge sind das Ergebnis längerer Überlegungen und Tests. Ich habe versucht, meine Schlußfolgerungen durch die Beschreibungen anderer zu überprüfen, doch ich habe dazu im Internet nichts gefunden; auch der dir ja auch bekannte Blog von Margosis tut das Thema recht lapidar ab und geht auf die Aspekte und Konsequenzen im Einzelnen nicht ein. Ich wäre also aus diesem Grund für andere Meinungen - auch gegenteilige - dankbar, weil sie mir die Gelegenheit gegebene würde, meine Überlegungen entweder zu korrigieren oder zu bestätigen beziehungsweise zu verfeinern.

[Fußnote 1]: Das kann aber auch schon mal versagen: Verschiebt(!) ein Admin eine eigene Datei in das Profil des Benutzers, so habe ich schon wiederholt erlebt, daß der Benutzer nicht den Vollzugriff hatte, also Handarbeit an den Rechten erforderlich wurde.

Kay

Ok, zurück zu den SuRun Nice-Level-Einstellungen.

@COSMO:
Danke für die klare und strukturierte Auflistung :-)

Ich denke, es gibt noch mehr SuRun-Benutzertypen.

Ich zum Beispiel benutze ein eingeschränktes Konto, um ohne Virenscanner oder HIPS arbeiten zu können.
Ich mag kein gebremstes Sytem.
Wenn mein System befallen wird, kann ich es aus einem echten Admin Konto wieder reparieren.
Wird Schadware entdeckt, (ist noch nie passiert btw.) ziehe ich den Netzwerkstecker, logge mich als echter Admin ein und aus die Maus. Ansonsten ist mir die richtige Administration des Systems völlig wurscht. Ich benutze meinen Rechner als Rechenknecht und Arbeitspferd, mehr nicht.
Aber: Ich passe in Deine Gruppe A. Benutzer, die (meistens) wissen, was sie tun oder mit dem Resultat klar kommen.

Meine Frau und meine Mutter zum Beispiel haben auch eigene Rechner und die wären ein anderer Nutzertyp.
Sie würden auf jeden Fall mit eingeschränkten Rechten arbeiten, einen Virenscanner einsetzen und andere Notwendigkeiten auf sich nehmen, um nicht vor einem kaputten System zu stehen.
Am besten wäre, sie hätten einen Administrator, den haben sie aber nicht (immer).
Für diese Benutzer bietet SuRun die Sicherheit, dass gefragt wird, bevor sich etwas Systemweit installieren kann.
Sie verstehen aber nicht, wie das alles zusammenhängt, was Administratoren und Desktops sind.
Die bräuchten nur (und einfache) SuRun-Einstellungen, falls etwas nicht funktioniert.

Dann gibt es noch Eltern-Kind-Szenarien, bei denen die Eltern den Rechner nicht verstehen, aber dem Kind nur eingeschränkte Rechte geben wollen. Die brauchen einfachere Einstellungsmöglichkeiten.

...Aber vielleicht kann man das alles ja tatsächlich über nur zwei Nice-Level handhaben...

Erstmal zu den vorgeschlagenen Optionen:

So eine reduzierte (aka nice) Einstellungsoption würde ich damit verbinden, auf den separaten Desktop für Surun zu verzichten (HIPS).

Gerade den würde ich immer an lassen, das ist die Sicherung gegen Keylogger und Fernsteuerer...
Mhhh! Mal sehen, ob der WatchDog bei den "Wilders Leuten" läuft.

Ebenso würde ich hier den Hook eingeschaltet lassen, denn in dieser Gruppe glaube ich, daß die Möglichkeit über Surun installieren zu können wichtiger ist; wahrscheinlich sind da auch mehr Gamer als Access-Anwender vorhanden. Für diese Gruppe ist die Vorgabe der Aktivierung der Eigentümer-Option natürlich zwingend.

Jepp, sehe ich ähnlich.
Die Hooks würde ich jedoch als eine (An/Aus) Option gestalten...
Nur einen Namen "mit Äpfeln und Birnen erklärt" dafür habe ich noch nicht.

Zur Trennung der Optionen: Natürlich ist die Seite Surunner-Gruppe unverzichtbar. Die allgemeinen Optionen wird man für Gruppe B wohl alle vorgabegemäß aktivieren können;

100% ja! :-)

angezeigt werden barucht eigentlich nur die Auswahlliste, wem die Warnung über leere Paßwörter gezeigt werden soll.

Das kann IMO auch auf Standard bleiben, es gibt in solchen Systemen eh' keinen Admin mit Plan.
Für Eltern/Kind-Szenarien kann das Kind beschränkt werden und sieht "leeres Kennwort" per Voreinstellung nicht.

Von den erweiterten Optionen sehe ich nur die erste Gruppe mit den drei Optionen für Gruppe B als sinnvoll an (Vorgabe in allen Fällen aktiviert; die anderen würde ich alle vorgabegemäß für diese Gruppe deaktivieren, die Anzeige des Benutzerstatus für Benutzer wählen.

Paßt! :-)

Mein Vorschlag:
---------
Seite Allgemein: fliegt komplett raus, per Voreinstellung ist alles an, unbeschränkte SuRunner und Administratoren sehen die "leeres Kennwort"-Warnung

Seite SuRunners Gruppe: bleibt, wie sie ist.

Seite Erweitert: Nur eine Option "Versuche bestimmte Programme AUTOMAGISCH mit gehobenen Rechten zu starten" An(default)/Aus; setzt alle drei Haken der ersten Gruppe; Alles andere ist aus.

Alles schön in eine einzelne Dialogseite gepackt und einen "Experte"-Knopf dazu.
Wenn man den Expertenmodus verlassen will (Knopf z.B. "Leicht"), warnt SuRun, dass bestimmte Optionen auf Voreinstellungen gesetzt werden.

Passt das so?

cosmo

Da sind wir doch sehr nahe beieinander. Ich hatte die Gruppierung ganz bewußt sehr einfach gehalten, weil ich zwar in der Lage wäre, mir noch die eine oder andere Gruppe auszudenken, aber inwieweit diese zusätzlichen Gruppen dann im richtigen Leben auch vorkommen und für Surun benötigt werden, ist eine andere Frage. Wenn es sich zeigt, daß man mehr Gruppen benötigt, kann man sie immer noch definieren, anstatt im Vorfeld sich kunstvolle Gruppen auszudenken und anschließend festzustellen, daß die Überlegungen für die Katz waren.

In einem Punkt bin ich nicht ganz deiner Meinung: Die Option, wem die Warnung bezüglich leerer Paßwörter angezeigt werden soll, habe ich bewußt für den nice level vorgeschlagen, weil ich mir vorstellen kann, daß der eine andere der Gruppe B das (warum auch immer) nicht ändern will, auf die Dauer diese Warnung dann aber nervt. Die Warnung für Gruppe B von vorneherein auszuschalten halte ich nun allerdings für den ganz falschen Weg (ich war ja wesentlich daran beteiligt, daß Surun die Warnung anzeigt). Natürlich würde für die Gruppe B ein einfacher Ein-/Ausschalter wahrscheinlich reichen; ich wollte aber die Sache auch für dich so einfach wie möglich halten und daraus folgte meine Idee, diese Option auch im nice level so wie sie ist anzuzeigen.

Was die Namensgebung für die Hooks anbetrifft (insbesondere für Gruppe B und insbesondere alle nicht-englisch-kundigen Benutzer ist Hook etwas nicht wirklich faßbares (Gab es da nicht einmal einen Film namens Captain Hook?), wie wäre es denn mit etwas wie diesem: "Automatische Erkennung, wenn ein Programm erweiterte Rechte benötigt"?

Kay

Cosmo wrote: weil ich mir vorstellen kann, daß der eine andere der Gruppe B das (warum auch immer) nicht ändern will, auf die Dauer diese Warnung dann aber nervt.

Stimmt auffallend... Dann mache ich das so. :-)

Cosmo wrote: wie wäre es denn mit etwas wie diesem: "Automatische Erkennung, wenn ein Programm erweiterte Rechte benötigt"?

Gar nicht schlecht! Besser, als das bisher in SuRun existierende "Versuche bestimmte Programme AUTOMAGISCH mit gehobenen Rechten zu starten" ist das auf jeden Fall. :-)

Muss die nächsten Tage aber erstmal die Doku anpassen (Watchdog) und endlich englische Website und Doku machen...

Mit dem EZ-Setup, dass wird sich also noch etwas ziehen.

BTW: Habe gerade 1.1.0.6 frei gelassen. Hoffentlich benimmt sich das besser, als 1.1.0.5. ;-)