Lücke im Rechtesystem...
Diana
eingerichtet. Mit RunAs wird die Bildschirmtastatur unter diesem Account
gestartet. Im Info Dialog gibt es einen Link, um weitere Infos von der
Micrsoft-Webseite zu erhalten. Wenn man den anklickt, startet der Internet
Explorer und versucht die Seite anzuzeigen. Wenn vorher noch kein IE
gestartet war, kommt nach einer Weile dann die Fehlermeldung "Die Webseite
kann nicht angezeigt werden.", was aber hier nebensächlich ist.
Versucht man im IE per Datei->Speichern unter... Zugriff auf die Festplatte
zu erhalten, wird wie gewünscht nichts angeboten, was einem nicht gehört.
Gibt man aber in die URL Zeile c: ein, wird ein Explorer geöffnet, der die
Rechte von dem hat, der per RunAs die Bildschirmtastatur gestartet hatte, in
diesem Fall Adminrechte. Aber genau das wollte ich mit dem RunAs verhindern.
Wenn der IE8 vorher schon unter Adminrechten getartet war, dann hat man auch
im IE im Speichern unter... Dialog schon vollen Zugriff. Nicht schön das ist.
Ist das Problem bekannt und gibt es einen Fix dafür?
Mark Heitbrink [MVP]
Am 02.12.2009 15:09, schrieb Diana:
> [runas explorer.exe] Ist das Problem bekannt und gibt es einen Fix dafür?
Bekannt und kein Fix.
Die Explorer Instanz ist das Problem. Man kann sie nicht per runas in
einem anderen Account öffnen, wenn sie oder Teile von ihr schon im
Namen eines User laufen.
Lösung:
- Arbeite als Benutzer
- passe fehlende Berechtigungen an, dann braucht es keinen runas
- oder arbeite anstelle von RunAs mit FUS, Fast User Switching.
Tschö
Mark
--
Mark Heitbrink - MVP Windows Server - Group Policy
Homepage: www.gruppenrichtlinien.de - deutsch
Discuss : www.freelists.org/list/gpupdate
Diana
> Lösung:
> - Arbeite als Benutzer
> - passe fehlende Berechtigungen an, dann braucht es keinen runas
> - oder arbeite anstelle von RunAs mit FUS, Fast User Switching.
Hmm..., sieht mir nicht nach einer Lösung aus.
Die Dateien die dem Benutzer gehören, könnten von dem Gastnutzer, der eine
Eingabe in das Programm vom Benutzer durchführen soll, zerschossen werden.
Berechtigungen können nicht angepasst werden, die vom Benutzer benötigt aber
hinterrücks dem Gast zur Verfügung gestellt werden.
Fast User Switching scheidet auch aus, weil in der Session vom Benutzer,
durch den Gast, eingaben erfolgen sollen.
Sonst noch eine Idee?
Thomas Leube
ich bin mir nicht sicher, ob ich die Situation und vor allem die
Zielstellung richtig verstanden habe.
Verstanden habe ich folgendes:
Der Admin startet die Bildschirmtastatur im Kontext von Gast (per
RunAs). Von dort aus wird der IE und von da aus der WE gestartet.
Letzterer lï¿œuft bei dir im Kontext des Admin-Kontos, du mï¿œchtest aber,
daￜ auch er im Kontext von Gast lￜuft.
Aktiviere in den Ordneroptionen Ordnerfenster im eigenen Prozeￜ zu starten.
Ob das hilft, habe ich nicht getestet, weil mir der Sinn des ganzen
nicht einleuchtet. Der Admin kann ein Explorerfenster sowieso immer im
eigenen Kontext starten. Auï¿œerdem lassen mich Sï¿œtze wie dieser
Am 02.12.2009 16:30 schrieb Diana:
> Die Dateien die dem Benutzer gehï¿œren, kï¿œnnten von dem Gastnutzer, der eine
> Eingabe in das Programm vom Benutzer durchfï¿œhren soll, zerschossen werden.
daran zweifeln, ob ich das ganze nicht doch falsch verstanden habe. Eine
genauere Beschreibung hilft dann weiter.
--
Thomas
Diana
die Aufgabe hast Du richtig verstanden.
Ordnerfenster im eigenen Prozess starten ist schon gesetzt.
Zum Hintergrund. Eine Applikation auf einer Produktionsmaschine läuft, von
der kein Zugang zum Windows vorhanden ist. In bestimmten Sondersituationen
sind Eingaben per Bildschirmtastatur nötig. Die Applikation muss in der Lage
sein, auf Ihre Dateien und Daten zuzugreifen und läuft daher auf Admin Level
(könnte auch Benutzerlevel sein, hilft hier aber nicht weiter).
Der Benutzer soll aber nicht hinterrücks über andere Wege als von der
Applikation vorgegeben, Änderungen am Dateisystem durchführen können.
Deswegen der Start der Bildschirmtastatur als Gast, was aber leider nicht
geholfen hat.
Ich meine mal irgendwo gelesen zu haben, dass man konfigurieren kann, ob der
IE auf Laufwerke bzw. WE Modus umschaltet, wenn man in die URL einen
Laufwerksbuchstaben eingibt bzw. einen Pfad auf die Festplatte. Habs aber
nicht wieder gefunden.
Uwe Schröder
> Im Info Dialog gibt es einen Link, um weitere Infos von der
> Micrsoft-Webseite zu erhalten. Wenn man den anklickt, startet der Internet
> Explorer und versucht die Seite anzuzeigen.
Es startet der auf dem System registrierte Standard-Browser. Du
k�nntest in der Registry den Eintrag f�r das http-Protokoll umbiegen
oder l�schen.
Ich wei� aber nicht, ob das zielf�hrend ist. Schlie�lich kann man auf
der Bildschirmtastatur auch einfach <Windows>+R eingeben, genau wie
auf der richtigen Tastatur auch. Die Bildschirmtastatur ist eigentlich
nicht daf�r gedacht, Eingaben zu *verhindern*.
usch
Thomas Leube
Am 03.12.2009 12:03 schrieb Diana:
> die Aufgabe hast Du richtig verstanden.
wenn ich ganz ehrlich bin, dann bin ich jetzt erstaunt.
Also so geht es nicht. Uwe hat dich ja schon darauf hingewiesen, daￜ
der, der Eingaben machen kann (ob mit physischer Tastatur oder
Software-Tastatur) auch andere Prozesse starten kann.
Du schreibst, daￜ Benutzerrechte fￜr die zu tￜtigenden Aufgaben reichen.
Warum erfolgt die Anmeldung dann nicht gleich in einem Benutzerkonto
(oder Gast)? Damit sind Rechte zum Schreiben im Windows-Ordner und im
Zweig Programme schon einmal weg.
Wenn es auch um weitere Beschrï¿œnkungen geht, kann man fï¿œr dieses Konto
fï¿œr den Root-Ordner des Laufwerkes das Recht zum Erstellen von Ordnern
noch entfernen. (Dateien kï¿œnnen Benutzer im Rootordner von vorne herein
nicht schreiben.) Damit bleibt dem Benutzer nur noch das Schreibrecht
innerhalb seines Kontos (Dokumente und Einstellungen\protect). Sollte es
noch weitere Ordner auf dem Laufwerk geben, entfernt man dort die
Schreibrechte fï¿œr das Konto komplett.
Auch im Kontopfad kï¿œnnte man eventuelle Beschrï¿œnkungen machen,
allerdings kann ich nicht mit Sicherheit sagen, ob es Nebenwirkungen
gibt, zum Beispiel, wenn auch im Benutzer-temp-Ordner nicht geschrieben
werden kann.
Andererseits wï¿œre zu prï¿œfen, was an Dateien im Benutzerkonto so
schlimmes sein kï¿œnnte, das ist von hier aus nicht zu ï¿œbersehen.
Vorstellbar wￜre, daￜ verhindert werden soll, daￜ jemand auf diesem Weg
eine ausfï¿œhrbare Datei einschmuggelt und dann ausfï¿œhrt. Fï¿œr diesen Fall
kann man aber fï¿œr dieses Konto (den oben bereits genannten Pfad,
zusï¿œtzlich auch fï¿œr das Konto All Users) das Recht zum Ausfï¿œhren von
Programmen entfernen, dann kann der hypothetische Saboteur (so klingt
das fï¿œr mich) bestenfalls nur tote Bytes ablegen. Und wenn man auch da
einen Riegel vorschieben will, setzt man eine sehr enge Kontingentierung
fï¿œr dieses Konto. - Bei dieser Lï¿œsung wï¿œre aber zu prï¿œfen, ob besagte
Applikation darauf angewiesen ist, im temp-Ordner ausfï¿œhrbare Dateien
anzulegen und auszufï¿œhren, dann wird es richtig schwierig.
--
Thomas
Diana
war mit anderen Aufgaben zugefrachtet (nächste Release), so dass ich jetzt
erst wieder dazu komme, hier anzuknüfen.
Danke für Deine ausführliche Antwort (auch an Uwe). Es wäre sicher schon mal
ein Vorteil, nur als Benutzer angemeldet zu sein, weil dann das Windows
Verzeichnis geschützt wäre und auf andere Laufwerke könnte man ebenfalls den
Schutz erhöhen.
Ein zu lösendes Problem dabei ist, dass für Updates, Admin Rechte benötigt
werden und die Applikation nicht dafür geschrieben ist, mit verschiedenen
(Admin/Benutzer) Levels zu arbeiten, ohne Frage ein Designfehler.
Es bleibt dennoch das Problem, dass die Applikation Ihre eigenen Daten
normalerweise geordnet und sicher über das GUI der Applikation bearbeitet und
der Benutzer sich nicht über die Bildschirmtastatur zugang dazu verschaffen
können soll.
Da wir unsere eigene Shell haben, kann man z.B. Windows+R nicht ausführen.
Aber mit Ctrl+Shift+ESC bekommt man den Taskmanager, womit das dann doch
wieder geht.
Der Vorschlag von Uwe den Standardpfad für den Browser zu löschen oder zu
verbiegen, hilft auch nicht direkt weiter, weil für Service Zwecke (z.B.
Einsicht in Service Dokus) der Browser auch noch zum Einsatz kommen soll und
das Problem wieder da ist.
Im Moment sehe ich noch keine befriedigende Lösung.
Heute habe ich allerdings etwas neues festgestellt. Wenn ich das Gastkonto
freischalte und mit RunAs als Gast die Bildschirmtastur starte, dann habe ich
wie gewünscht auf C gar keine Schreib-/Löschberechtigung.
Wohl aber auf D, obwohl dort für Guest nur Lesen\Ausführen erlaubt ist.
Schänke ich jedoch die Benutzer auch auf Lesen\Ausführen ein, dann habe ich
eigentlich das, was ich wollte, tja, wenn mir wie oben beschrieben der
Taskmanager nicht dazischen funken würde aber dessen Startmöglichkeit kann
man sicher unterbinden oder?
Es muss zwar noch irgendwie eine Lücke im System geben, sonst hätte ich
letztens nicht auf C löschen können, aber im Moment kann ich die nicht
reproduzieren.
Thomas Leube
mir fï¿œllt es weiterhin schwer zu erkennen, was im Einzelnen du
beschreibst. Zum Beispiel hier:
Am 10.12.2009 16:23 schrieb Diana:
> Ein zu lï¿œsendes Problem dabei ist, dass fï¿œr Updates, Admin Rechte benï¿œtigt
Von welchen Updates ist die Rede: Windows oder besagte Applikation?
Windows-Updates kï¿œnnen ï¿œber Auto-Updates installiert werden, dafï¿œr
braucht es keine Anmeldung im Admin-Konto. Applikation: Wie oft kommt
das vor? Klar, daￜ dafￜr die Applikation mit administrativen Rechten
oder im Admin-Konto ausgefￜhrt werden muￜ, das ist aber bei jedem
Programm der Fall, also keine Besonderheit.
> werden und die Applikation nicht dafï¿œr geschrieben ist, mit verschiedenen
> (Admin/Benutzer) Levels zu arbeiten, ohne Frage ein Designfehler.
Ich kenne das Programm nicht und nur aus diesem Grund sage ich nicht
sofort: Stimmt nicht. Ich sage aber: Das glaube ich nicht. Ich kann mir
gut vorstellen, daￜ das Programm es nicht erlaubt, mit mehreren
Instanzen gleichzeitig ausgefï¿œhrt zu werden, zum Beispiel einmal normal
im Kontext des angemeldeten Benutzers und ein weiteres mal ï¿œber RunAS;
daￜ es mit RunAs grundsￜtzlich nicht gehen soll, wage ich zu bezweifeln.
Sollte ich falsch liegen, so mￜￜtest du mitteilen, warum nicht, also was
dann passiert oder nicht passiert.
Warum aber soll es notwendig sein, das Programm mit zwei Instanzen
gleichzeitig auszufï¿œhren, oder mit anderen Worten: Worin besteht
diesbezï¿œglich die Einschrï¿œnkung?
> Es bleibt dennoch das Problem, dass die Applikation Ihre eigenen Daten
> normalerweise geordnet und sicher ï¿œber das GUI der Applikation bearbeitet und
> der Benutzer sich nicht ï¿œber die Bildschirmtastatur zugang dazu verschaffen
> kï¿œnnen soll.
Wieso ist die Bildschirmtatstatur plï¿œtzlich ein Problem, wenn im OP
beschrieben worden ist, daￜ diese eingesetzt wird. Und wenn es denn so
ist, so lï¿œsche die osk.exe einfach (oder benenne sie zu
osk.exe.Umbenannt um).
> Da wir unsere eigene Shell haben, kann man z.B. Windows+R nicht ausfï¿œhren.
> Aber mit Ctrl+Shift+ESC bekommt man den Taskmanager, womit das dann doch
> wieder geht.
Verstehe ich ebensowenig. Es ging doch um das Verhindern, daￜ Programme
mit erhï¿œhten Rechten (die durch Vererbung aus einem erhï¿œht gestarteten
Prozeￜ entstehen) gestartet werden. Was hat der Task Manager damit zu
tun? Ein eingeschrï¿œnkter Benutzer kann aus dem im eigenen Kontext
gestarteten Manager nichts erhï¿œht aufrufen, zumindest nicht, solange er
das Admin-Paï¿œwort nicht kennt - was ich voraussetze.
> Der Vorschlag von Uwe den Standardpfad fï¿œr den Browser zu lï¿œschen oder zu
> verbiegen, hilft auch nicht direkt weiter, weil fï¿œr Service Zwecke (z.B.
> Einsicht in Service Dokus) der Browser auch noch zum Einsatz kommen soll und
> das Problem wieder da ist.
Unter Servicezwecke verstehe ich administrative Aufgaben. Also nimm dem
Benutzerkonto das Recht zum Ausfï¿œhren, der Browser bleibt fï¿œr andere
Konten dadurch unverï¿œndert verfï¿œgbar.
> Heute habe ich allerdings etwas neues festgestellt. Wenn ich das Gastkonto
> freischalte und mit RunAs als Gast die Bildschirmtastur starte, dann habe ich
> wie gewï¿œnscht auf C gar keine Schreib-/Lï¿œschberechtigung.
Noch einmal: Ich habe verstanden und auch geschrieben, daￜ die
Applikation per se keine erhï¿œhten Rechte braucht, dem hast du nicht
widersprochen. Wozu wird jetzt die mit erhï¿œhten Rechten gestartet
Bildschirmtatstatur denn nun wirklich benï¿œtigt? Und: Das geht ja nur,
wenn der Benutzer (oder Gast) das Admin-Kennwort kennt. Da ihr
anscheinend sehr miï¿œtrauisch seit, kann ich die Weitergabe des
Kennwortes nun gar nicht mehr nachvollziehen. Wer das Kennwort kennt,
den kannst du an gar nichts hindern.
Falls du an dieser Stelle immer noch den Aufruf aus dem Admin-Konto mit
RunAs als Gast meinst: Wir waren schon so weit, daￜ das nicht zum Ziel
fï¿œhren *kann*. Und erste recht gilt hier: Wer Zugang zum Admin-Konto
hat, den kannst du an gar nichts hindern, der Ansatz ist von vorne
herein falsch und zum scheitern verurteilt.
> Wohl aber auf D, obwohl dort fï¿œr Guest nur Lesen\Ausfï¿œhren erlaubt ist.
> Schï¿œnke ich jedoch die Benutzer auch auf Lesen\Ausfï¿œhren ein, dann habe ich
> eigentlich das, was ich wollte, tja, wenn mir wie oben beschrieben der
> Taskmanager nicht dazischen funken wï¿œrde aber dessen Startmï¿œglichkeit kann
> man sicher unterbinden oder?
s.o. Entweder ist deine Beschreibung miï¿œverstï¿œndlich - dann kann ich
zumindest dir auch keinen Rat geben - oder du muￜt dich davon lￜsen, daￜ
sich der Bediener im Admin-Konto anmeldet.
--
Thomas
Diana
hatte einige Tracker zu bearbeiten. Sorry, dass das hier so zögerlich geht.
Muss vielleicht doch noch mal auf das Umfeld eingehen, damit das Problem
klarer wird.
Es geht hier um eine Produktionsmaschine (Maschinenbau), auf der ein PC
Board installiert ist, mit XP Embedded als OS. Die Windows Shell ist durch
eine eigene ersetzt, zu der der Kunde aber kein Zugang hat, beim Start wird
gleich unsere Appl. gestartet. Über unsere Bedieneroberfläche kann man
Updates sowohl von der Applikation einspielen als auch wenn nötig, Windows
Komponenten austauschen, wofür Admin Rechte gebraucht werden. Es wird nicht
der Windows Update Mechanismus verwendet. Die Maschinen sind auch nicht immer
vernetzt.
Die Maschinen sind deswegen geschützt, weil es immer wieder vorkam, das
Schichtarbeiter die Platte zerschossen oder für die lange Nachtschicht Spiele
aufgespielt haben und es daher immer wieder ärger gab. C ist zudem mit einem
EWF Filter geschützt.
Die Applikation läuft auf Admin Level, was besagte Probleme aufwirft, wenn
es einem gelingt am Appl. GUI vorbei zu kommen. Die Anmeldung erfolgt per
AutoLogin. Aber gehen wir mal davon aus, dass man nur als Benutzer angemeldet
wird und somit die Applikation auf Benutzerlevel läuft, an dem man aber
dennoch über das OSK vorbei kommen kann und Zugriff auf den Datenbestand des
Benutzers hat (natürlich nur auf Benutzerlevel).
Das OSK wird nur ganz selten benötigt. In der Regel wird die Maschine über
einen Touch bedient. Für Eingaben kann aber auch eine Tastatur angeschlossen
sein und falls die fehlt gibt es zur Not das OSK.
Benötigt wird das OSK als Notbehelf, wenn man auf die Serviceebene gelangen
will (mit zusätzlichem Passwort geschützt) oder Eingaben in externe Programme
(Browser, Bluetooth Konfiguration...) nötig sind aber keine USB Tastatur
angestöpselt ist.
Wenn die Applikation auf Benutzerlevel läuft und per RunAs das KeyBoard auf
Gast Level, dann sollte es nicht möglich sein, über den Explorer den
Datenbestand vom Benutzer zu ändern, darum geht es. Das Programm samt Daten
sollen nur über das Appl. GUI geändert werden, dass dazu auf Benutzerlevel
läuft. Ein 'unerlaubt' gestarteter Explorer auf Benutzerlevel würde
Veränderungen am Datenbestand erlauben, was unterbunden werden soll. Programm
und Daten befinden sich auf Laufwerk D.
Die Aufgabe ist es zu verhindern, dass der Schichtarbeiter unerlaubte
Änderungen am Plattenstand vornimmt.
Zur Lücke Task Manager: Den kann man per Registry sperren, so dass er nicht
per Hot Key (Ctrl-Shift-Esc) startbar ist.
Thomas Leube
ich glaube nicht, daￜ ich aus der Entfernung noch weiter fￜhrende Tips
geben kann, dafï¿œr scheint die Situation zu speziell.
Vielleicht hilft es, das OSK mit einem Programm wie Protect EXE (zum
Beispiel hier: http://download.chip.eu/de/Protect-Exe-0.4_597302.html)
oder ï¿œhnlichem abzusichern.
--
Thomas
Diana
> Vielleicht hilft es, das OSK mit einem Programm wie Protect EXE (zum
> Beispiel hier: http://download.chip.eu/de/Protect-Exe-0.4_597302.html)
> oder ähnlichem abzusichern.
Das hilft leider nicht, der Anwender soll das OSK ja beutzen können und der
Passwortschutz ändert an den erworbenen Rechten nichts.
An dem was ich will, bin ich aber relativ dicht dran. Habe die Lücke
gefunden, weiss aber noch nicht wie man die sinnvoll schliesst.
Wenn ich das Gast Konto freischalte oder auch ein neues Anlege und osk per
runas darunter laufen lasse, ist Laufwerk D ungeschützt. Erst wenn ich von
der Users Gruppe die Schreib- und Löschrechte wegnehme, dann hat das
Gastkonto auch keine Schreib\Lösch-Berechtigung auf D.
Das ist leider unabhängig davon, wie ich die Rechte vom Guest einschränke.
Es wirken die von der Usergruppe. Kannst Du mir da weiter helfen?
Gruß
Diana
PS: Bin nur noch heute da und dann ab 11.01.10 wieder. Danke an Dich und die
Anderen für die unermüdliche Unterstützung, frohe Weihnachten und einen guten
Rutsch.