none
Privilegien - generelle Verständnisfrage RRS feed

  • Frage

  • Hallo zusammen,

    wer kann mir mal kurz auf die Sprünge helfen?

    Für gewisse (programmatische) Aktionen benötigt man ja gewisse Privilegien. So weit, so gut.
    Diese können (lokal) mit dem Tool "Lokale Sicherheitsrichtline" den einzelnen Benutzer bzw. Benutzergruppen vergeben werden. Ebenfalls klar.

    Wenn ich mich als (lokalen) Admin anmelde und "woami /priv" aufrufe, habe ich folgende Ausgabe:

    Berechtigungsname             Beschreibung                                    Status
    ============================= =============================================== ===========
    SeShutdownPrivilege           Herunterfahren des Systems                      Deaktiviert
    SeChangeNotifyPrivilege       Auslassen der durchsuchenden Überprüfung        Aktiviert
    SeUndockPrivilege             Entfernen des Computers von der Docking-Station Deaktiviert
    SeIncreaseWorkingSetPrivilege Arbeitssatz eines Prozesses vergrößern          Deaktiviert
    SeTimeZonePrivilege           Ändern der Zeitzone                             Deaktiviert

    Wenn ich die Eingabeaufforderung "als Administrator" starte, habe ich plötzlich mehr Privilegien!?

    Berechtigungsname                         Beschreibung                                                            Status
    ========================================= ======================================================================= ===========
    SeIncreaseQuotaPrivilege                  Anpassen von Speicherkontingenten für einen Prozess                     Deaktiviert
    SeTcbPrivilege                            Einsetzen als Teil des Betriebssystems                                  Deaktiviert
    SeSecurityPrivilege                       Verwalten von Überwachungs- und Sicherheitsprotokollen                  Deaktiviert
    SeTakeOwnershipPrivilege                  Übernehmen des Besitzes von Dateien und Objekten                        Deaktiviert
    SeLoadDriverPrivilege                     Laden und Entfernen von Gerätetreibern                                  Deaktiviert
    SeSystemProfilePrivilege                  Erstellen eines Profils der Systemleistung                              Deaktiviert
    SeSystemtimePrivilege                     Ändern der Systemzeit                                                   Deaktiviert
    SeProfileSingleProcessPrivilege           Erstellen eines Profils für einen Einzelprozess                         Deaktiviert
    SeIncreaseBasePriorityPrivilege           Anheben der Zeitplanungspriorität                                       Deaktiviert
    SeCreatePagefilePrivilege                 Erstellen einer Auslagerungsdatei                                       Deaktiviert
    SeBackupPrivilege                         Sichern von Dateien und Verzeichnissen                                  Deaktiviert
    SeRestorePrivilege                        Wiederherstellen von Dateien und Verzeichnissen                         Deaktiviert
    SeShutdownPrivilege                       Herunterfahren des Systems                                              Deaktiviert
    SeDebugPrivilege                          Debuggen von Programmen                                                 Deaktiviert
    SeSystemEnvironmentPrivilege              Verändern der Firmwareumgebungsvariablen                                Deaktiviert
    SeChangeNotifyPrivilege                   Auslassen der durchsuchenden Überprüfung                                Aktiviert
    SeRemoteShutdownPrivilege                 Erzwingen des Herunterfahrens von einem Remotesystem aus                Deaktiviert
    SeUndockPrivilege                         Entfernen des Computers von der Docking-Station                         Deaktiviert
    SeManageVolumePrivilege                   Durchführen von Volumewartungsaufgaben                                  Deaktiviert
    SeImpersonatePrivilege                    Annehmen der Clientidentität nach Authentifizierung                     Aktiviert
    SeCreateGlobalPrivilege                   Erstellen globaler Objekte                                              Aktiviert
    SeIncreaseWorkingSetPrivilege             Arbeitssatz eines Prozesses vergrößern                                  Deaktiviert
    SeTimeZonePrivilege                       Ändern der Zeitzone                                                     Deaktiviert
    SeCreateSymbolicLinkPrivilege             Erstellen symbolischer Verknüpfungen                                    Deaktiviert
    SeDelegateSessionUserImpersonatePrivilege Identitätstoken für einen anderen Benutzer in derselben Sitzung abrufen Deaktiviert

    Frage 1: Wenn ich mich als "Administrator" anmelde bin ich doch (bereits) Administrator!? Wieso habe ich trotzdem weniger Rechte als ein nochmaliges explizites starten des Prozesses als "Administrator"??

    Frage 2: Was für einen Sinn machen deaktivierte Privilegien? Ich meine, entweder habe ich ein Privileg oder nicht. Ich weiss, dass man Privilegien programmiertechnisch "aktivieren" kann. Aber wieso sind nicht alle dann gleich aktiviert? Ich meine, eine potentielle Schadsoftware könnte und würde das Privileg auch aktivieren, wenn es dieses benötigen würde.

    Frage 3: In den "Lokale Sicherheitsrichtline" wollte ich mir mal (testweise) das Recht SeTcbPrivilege zuweisen. Das müsste ja in der deutschen Übersetzung die Richtlinie "Einsetzen als Teil des Betriebssystems" sein. Allerdings besitze ich dieses Recht nicht auch nach aus- und wieder einloggen. Ist das die richtige Richtlinie?? Schade ist, dass nicht in der "Erklärung" nochmals der technische Name erwähnt wird, um auch in anderen Sprachen besser kontrollieren zu können, ob es das gewünschte Recht ist.

    Vielen Dank an alle, die sich die Mühe machen ein Feedback zu verfassen

    VG

    Samstag, 6. April 2019 11:45

Alle Antworten

  • Nun, die UAC kann man zwar auch abschalten, allerdings können dann die sog. "App's", wie z.B. "Microsoft Store", "Taschenrechner" u.ä. nicht mehr gestartet werden da die UAC hierfür Voraussetzung ist.

    Das gemeine an "Ausführen als Admin" ist, dass ein Prozess, der zwar so gestartet wurde, keine "Kind"-Prozesse mit denselben Rechten starten kann.
    Beispiel Installer: Startet als "Admin", entpackt seine Dokumente, ruft den eigentlichen Setup auf und schwups, schlägt die UAC vielleicht wieder zu.
    Das "Vielleicht" liegt in der Startvoraussetzung. Ist diese beim Installer "als Admin" nicht gegeben, startet der Prozess ohne Admin und scheitert dann gerne bei der Installation.
    In solchen Fällen muss man die UAC temporär leider abstellen, dann installieren und wieder einschalten.

    Sonntag, 7. April 2019 08:48
  • das Stichwort heißt "User Account Control", guckst Du hier: https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works

    UAC war mir schon ein Begriff. Aber üben diesen Artikel bin ich noch gar nicht gestolpert. Ist eigentlich ganz gut nochmals alles zusammengefasst dort. Vielen Dank schon mal dafür!

    Der Artikel beantwortet dann schon mal Frage 1.

    Was ich aber immer in diesen "overviews" Artikeln vermisse sind die konkreten best-practice Vorgehensweisen für eine maximale Kompatibilität mit Windows - heute - 10. Speziell gerade um diese Dinge wie die Shield-Icons auf den Buttons zu realisieren.
    Was muss der Entwickler dafür tun, damit diese angezeigt werden? Was muss dann, nach einem Klick, im Hintergrund passieren? Gibt es API-Funktionen, die man verwenden kann damit der UAC kommt oder (wenn ich den Artikel korrekt verstanden habe) gibt es keine andere Möglichkeit außer einen neuen Prozess zu starten (der erhöhte Rechte benötigt) und den alten Prozess zu beenden?

    Sonntag, 7. April 2019 10:00
  • Moin,

    ich bin jetzt kein Entwickler, aber soweit ich verstanden habe, kann man seiner Applikation (bzw. dem Installer) ein Manifest mitgeben, wo die Privilegien aufgelistet sind, die sie (er) meint zu benötigen. Kommt da irgendwas vor, was erhöhte Rechte erfordert, gibt's ein Schildchen und einen Prompt beim Aufrufen.

    Apropos Prompt: Der Administrator "Administrator" ist speziell, bei dem gibt es normalerweise nie einen Prompt (wohl aber das Schildchen), außer man schraubt UAC gaaanz nach oben.


    Evgenij Smirnov

    http://evgenij.smirnov.de


    Sonntag, 7. April 2019 12:47
  • Das ist nicht Sache des Entwicklers sondern der UAC.
    Fordert eine Anwendung Adminrechte erfolgt dies durch die rechteverwaltung.
    In .Net gibt es dafür z.B. die System.Security-Assembly um z.B. ein Admin-Token anzufordern.
    In diesem Fall schlägt dann noch die UAC zu, bevor das Progrmm weitermachen darf.
    https://docs.microsoft.com/de-de/dotnet/api/system.security.principal.windowsidentity.impersonate?view=netframework-4.7.2

    Um den Shieldbutton zu setzen, musst du das dann selber tun, da die UAC ja noch nichts davon weiß, dass ein Button, Link, oder eine komplizierte Tastenfolge den Adminmode anfordert.

    https://www.codeproject.com/Articles/18509/Add-a-UAC-shield-to-a-button-when-elevation-is-req

    Für andere Programmiersprachen kannst du das Icon ja einfach kopieren (Screencopy) oder aus der user32.dll extrahieren oder dir auch was eigenes ausdenken um den User da auf erhöhte Rechte einzustimmen.
    Die UAC macht da gar nichts.

    Sonntag, 7. April 2019 14:57
  • Um den Shieldbutton zu setzen, musst du das dann selber tun, da die UAC ja noch nichts davon weiß, dass ein Button, Link, oder eine komplizierte Tastenfolge den Adminmode anfordert.

    https://www.codeproject.com/Articles/18509/Add-a-UAC-shield-to-a-button-when-elevation-is-req

    Ja, as habe ich wohl falsch verstanden. Ich dachte, dem TO ging es darum, dass bereits *das Desktop-Icon* für sein Programm das Schildchen bekommt, weil das Programm so viele Rechte braucht bzw. meint zu brauchen.

    Und "die UAC macht da gar nichts" ist eine sehr gewagte Aussage. Wenn ein C++- oder Assembler-Programm Privilegien anfordert, die einen Admin-Token erfordern, schlägt UAC genau so zu wie bei einer .NET-Assembly.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Sonntag, 7. April 2019 17:02
  • @Evgeni Smirnov
    Richtig. Durch das Manifest kann man hinterlegen, dass die Applikation erhöhte Rechte benötigt und sobald das Executable ausgeführt wird, schlägt der UAC zu.
    Aber mir geht es mehr um den Use Case, dass das Programm zuerst "normal" gestartet wird, dann der Benutzer eine Operation machen will, für die erhöhte Rechte benötigt wird (wie z.B. das Ändern der Uhrzeit in Ihrem Link).

    @bfuerchau
    Ein Shield-Icon im Programm zu hinterlegen und anzuzeigen ist natürlich manuell immer möglich. Allerdings bevorzuge ich (sofern es passende API gibt) das immer von Windows selbst machen zu lassen bzw. anzufordern. Dann ist auch ein einheitliches Look&Feel sichergestellt. Auch über die nächste Windowsversion hinaus. Vor allem hat man dann auch jeden erdenklichen Fall (hoffentlich) berücksichtigt. Beispielsweise war mir bis heute auch noch nicht bewusst, dass es sogar unterschiedliche Shield-Icons gibt (ist mir ehrlich gesagt noch gar nie aufgefallen bzw. begegnet). Habe ich heute auch erst durch den Link von Evgenij erfahren. Aber Dein Link war auch hilfreich, da in diesem Beispiel die Button Message BCM_SETSHIELD verwendet wird. Genau das meine ich und suchte ich.
    Mit Impersonation habe ich schon "rumgespielt" (allerdings C++). Aber was noch zu XP Zeiten noch funktionierte (oder auch noch vielleicht noch heute bei ausgeschalteter UAC), geht heute leider nicht mehr, da hierfür der Benutzer wieder ein besonderes Recht benötigt, das ein normaler Benutzer normalerweise nicht hat (SeTcbPrivilege | siehe oben). Hatte gehofft, dass SspiPromptForCredentials den Secure Desktop ebenfalls innerhalb eines bereits gestarteten Programms aufruft und das zurückgegebene (Admin-)Token für die Impersionation verwendet werden kann. Leider nicht der Fall. Oder ich hab etwas falsch gemacht. :/

    Auch hier würde ich wieder Abstand nehmen einen Logon-Screen selbst zu entwerden, da ja nicht immer nur aus Benutzername und Passwort besteht (Stichwort Fingerprint, Smart Cards, etc.).


    Sonntag, 7. April 2019 19:00
  • Ich schrieb ja z.B. .Net."In diesem Fall schlägt dann noch die UAC zu, bevor das Progrmm weitermachen darf."
    Das schließt natürlich andere Programmiersprachen nicht aus.

    Die UAC ist keine Präventivsoftware, die das Aufrufen eines Programmes verhindert wie z.B. ein Virenscanner.

    Allerdings pappt die UAC keine Icons auf irgend welche Anwendungen (wie das Link-Icon bei Links).
    Da muss ich dann schon selber ein App-Icon mit dem Shieldsymbol entwickeln.

    Montag, 8. April 2019 08:55
  • Nur wenn man Anwendungen ohne Windows-GDI (z.B. mit WPF) erstellt, kann man keine Button-Messages mehr versenden, da es keine Buttons mehr gibt.
    Montag, 8. April 2019 08:57