Terminal: [Frage] Windows-Terminalprofil so konfigurieren, dass es immer mit erhöhten Rechten gestartet wird

Da ist nicht. Ich glaube nicht, dass wir planen, Tabs mit erhöhten und nicht erhöhten Tabs zu unterstützen, da dies eine Art Sicherheitslücke darstellt.

Ja, ich weiß, dass sudo eine Sache ist, aber wir hatten viele Diskussionen mit dem Sicherheitsteam über die Erstellung eines sudo für Windows. Das Hauptproblem liegt in der Tatsache, dass alle nicht erhöhten Prozesse Tastenanschläge an andere nicht erhöhte Fenster senden können.

Wenn Sie eine Befehlszeile mit erhöhten Rechten in einem Fenster ohne erhöhte Rechte ausgeführt haben, könnte ein nicht vertrauenswürdiger Angreifer einen Angriff mit erhöhter Berechtigung ausführen, indem er die nicht erhöhten Fenster ansteuert, auf denen die erhöhte Befehlszeile ausgeführt wird.

(wegen der Verlinkung verwandter Threads, #146)

BEARBEITEN (14. Februar 2020)
Okay, dieser Kommentar ist also nicht besonders gut gealtert. Ursprünglich gab es _keinen_ Plan, dies zu unterstützen, da es mit der einzelnen HWND , die wir hatten, nicht funktionieren würde. Wir arbeiten daran, eine Lösung zu entwerfen, die dies in Zukunft _möglicherweise_ unterstützt, aber wir können uns zu nichts verpflichten, bis wir sicher sind, dass wir eine angemessen sichere Lösung finden können, die sicherstellt, dass ein Prozess mit niedrigeren Privilegien dies nicht kann Fahren Sie ein Terminal mit höheren Privilegien.

Scheint vernünftig. Ich denke, so etwas wie eine Kombination aus #576 (Als Admin öffnen in der Sprungliste) und vielleicht eine Art Hotkey zum Starten einer Admin-Sitzung des Terminals zu haben, würde die meisten meiner Probleme hier lösen.

Wie wäre es, wenn ein Standard- und ein erhöhtes Terminal in einem einzigen Fenster, aber separaten Registerkarten geöffnet sind?

@mdtauk Ich denke, das fällt leider in die gleiche Kategorie. Da sich alle Registerkarten unter demselben HWND befinden, müsste der Stamm-HWND erhöht werden, um zu verhindern, dass nicht erhöhte Apps das Fenster steuern.

Aus Sicherheitssicht (Ignorieren des Designs von Windows Terminal, Single-Root-HWND usw.) wie „weniger sicher“ ist Terminal, das Registerkarten mit gemischten Höhen ausführt, im Vergleich zum Ausführen von beispielsweise einer PowerShell-Instanz mit erhöhten Rechten neben einer nicht erhöhten in der aktuellen UX ? Die Tatsache, dass die Konsolen-Apps in Terminal-Registerkarten gehostet werden, macht für mich keinen Unterschied ...

In ähnlicher Weise: Wie ist es sicherer, ein nicht erhöhtes Fenster zu haben, selbst wenn ich eine Remote-PS-Sitzung öffne, in der ich jetzt möglicherweise Administratorrechte auf einem Remote-Server habe, den ein nicht erhöhtes Fenster jetzt fahren könnte? Für mich scheint dies viel schlimmer zu sein, als lokalen Administratorzugriff zu erhalten, daher glaube ich nicht, dass das Ausführen einer Registerkarte als Administrator etwas anderes ist als das Remoting / SSH-ing auf andere Server. In beiden Fällen muss ich mich mit meinem System wohl genug fühlen, um es zu tun. Es ist eine "Ich bin alt genug und ich verstehe die Risiken"-Sache.

Immer wenn ich versuche, die Terminal-App mit einem Administratorkonto auszuführen, klicken Sie mit der rechten Maustaste -> Als Administrator ausführen, die Benutzerkontensteuerung wird zweimal angezeigt und es wird ein Fehler angezeigt:
"Windows kann (Pfad\WindowsTerminal.exe) nicht finden Stellen Sie sicher, dass Sie ... eingegeben haben".

Der Pfad ist vorhanden und die App funktioniert ordnungsgemäß für den Benutzer ohne Administratorberechtigung, der die App erstellt hat, aber der andere Administratorbenutzer kann sie nicht ausführen.
Wenn ich mich beim Admin-Benutzer anmelde, ist die Terminal-App weder in den Einstellungen noch im Startmenü vorhanden, als wäre sie nie auf dem System installiert worden.

Gibt es eine Möglichkeit, die App so zu erstellen, dass sie für alle Benutzer installiert wird? Oder muss sich das Stammverzeichnis des Projekts in einem nicht benutzerspezifischen Verzeichnis befinden?

@

Immer wenn ich versuche, die Terminal-App mit einem Administratorkonto auszuführen, klicken Sie mit der rechten Maustaste -> Als Administrator ausführen, die Benutzerkontensteuerung wird zweimal angezeigt und es wird ein Fehler angezeigt:
"Windows kann (Pfad\WindowsTerminal.exe) nicht finden Stellen Sie sicher, dass Sie ... eingegeben haben".

Der Pfad ist vorhanden und die App funktioniert ordnungsgemäß für den Benutzer ohne Administratorberechtigung, der die App erstellt hat, aber der andere Administratorbenutzer kann sie nicht ausführen.
Wenn ich mich beim Admin-Benutzer anmelde, ist die Terminal-App weder in den Einstellungen noch im Startmenü vorhanden, als wäre sie nie auf dem System installiert worden.

Gibt es eine Möglichkeit, die App so zu erstellen, dass sie für alle Benutzer installiert wird? Oder muss sich das Stammverzeichnis des Projekts in einem nicht benutzerspezifischen Verzeichnis befinden?

Ich sehe das gleiche Problem auch.

Windows-Version 18922.1000

Richtig, das Ausführen von Store-Apps als Administrator oder anderer Benutzer funktioniert nicht (by design BTW). Viele von uns sind (am PC) als normales Konto ohne erhöhte Rechte angemeldet. Wir führen powershell/cmd/etc als Administrator aus, um bestimmte Aufgaben zu erledigen.

Wenn die endgültige Wahl für die Bereitstellung dieser App der Windows Store ist, ist es für mich nutzlos, ohne eine Möglichkeit, erhöhte Registerkarten zu öffnen. Meine 2 Cent.

"Useless" ist vielleicht ein bisschen hart, aber wir brauchen tatsächlich eine Möglichkeit, das neue Terminal sowohl für nicht erhöhte als auch für erhöhte Konsolen-Apps / Shells zu verwenden. Und für mich wäre die beste UX, eine Mischung aus erhöhten und nicht erhöhten Registerkarten in derselben Windows Terminal-Instanz zu unterstützen. Weniger bevorzugt: Unterstützung von null bis vielen (normalerweise einer) erhöhten Instanzen (jede mit einer bis vielen Registerkarten) neben null bis vielen (normalerweise einer) nicht erhöhten Instanzen.

ConEmu kann erhöhte und nicht erhöhte Tabs im selben Fenster mischen. Kann man sowas hier nicht machen?

Könnten wir ein erhöhtes Terminal haben, das nicht erhöhte Registerkarten startet? Ich muss immer noch mit erhöhten Rechten starten, ABER ich kann eine neue Registerkarte öffnen, die "geschützt" ist.

Wenn wir sehr Windows-spezifisch vorgehen und andere Plattformen ignorieren möchten, auf denen möglicherweise Terminal angezeigt wird, könnte die Verwendung von Windows-Containern oder virtualisierten Prozessen bei einigen diesen Problempunkt lösen. Ich persönlich bin mit der aktuellen Lösung einverstanden, aber es wäre aus Sicherheitsgründen keine so schlechte Idee, Konsolen-Apps standardmäßig als isolierte Prozesse auszuführen.

Mischansicht in einem Fenster ist ein Muss, zumindest für mich.
Könnte es eine optionale Funktion sein, die in den Einstellungen umgeschaltet werden kann?

@pratnala Mit ConEmu _sieht_ es nur so aus, aber es tut es überhaupt nicht. Die erhöhten und nicht erhöhten "Tabs" sind nur Ansichten in zwei völlig separate, isolierte Root-Fenster/Prozesse. Dies geschieht unter anderem durch Scraping des Fensterinhalts und von Proxy-/Broker-Erhöhungshelfern usw. Sicher, es ist technisch möglich, aber was ConEmu tut, ist eigentlich ziemlich unsicher. Es ist eine Sache für ein Drittprogramm, dies zu tun und Leute dazu zu bringen, das Risiko einzugehen, indem sie ConEmu herunterladen, aber eine ganz andere für Microsoft, dies offiziell zu unterstützen, indem sie dies selbst tun. Wenn ich meine Haustürschlüssel unter der Fußmatte verstecken will, dann gut - das ist mein dummes Risiko. Aber was wäre, wenn bei jeder gekauften Tür ein Schlüsselbund unter die Fußmatte gelegt würde?

Aber sehen Sie, ich entwickle in C++ (und C#, PowerShell, Ruby, Python, GoLang, so ziemlich alles, was mir in den Weg kommt.) Ich habe ConEmu und TakeCommand installiert, zusammen mit mingw. Ich weiß, wie ich die Schere beim Laufen halten muss.

PowerShell _ist_ eine Sicherheitslücke. Ein sehr nützliches Automatisierungstool, das alle möglichen unerwarteten Zugriffe ermöglicht. Und was wir verlangen (gemischte Modi) ist sicherlich sicherer als die Alternative (alle erhöhten.) Wirklich, dieses (Terminal) ist ein Power-Tool für Power-User, von denen die meisten die Sicherheitslandschaft wahrscheinlich sehr gut verstehen ... und verstehen Pragmatischer Kompromiss.

Zero-Trust funktioniert nur, wenn es nicht schwächt.

@robomac Wenn wir das Sicherheitsteam davon überzeugen könnten (das uns mehrfach gesagt hat, dass wir uns nicht einmal annähernd in die Nähe einer gemischten Höhe wagen sollen), dass nur Leute, die wissen, wie man ihre Schere richtig hält, und nicht damit laufen, dieses Projekt _benutzen_ würden, wir würden es wahrscheinlich tun. Ich weiß nicht, ob ich es selbst glaube. Hier ist der Grund:

Wenn Terminal in gemischter Höhe ausgeführt wird (von einem Host mit mittlerer IL zu einem Client mit hoher IL), kann es immer noch gezwungen werden, Eingaben von irgendetwas anderem zu erhalten, das als dieser Benutzer ausgeführt wird. Selbst wenn die Person hinter der Tastatur ein Heiliger ist und nur für die zehn Sekunden heraufgesetzt wird, die sie dafür benötigt, kann _jede Anwendung, die unter ihrem Benutzerkonto ausgeführt wird, sich als Administrator ausgeben, ohne dass eine zusätzliche Eingabeaufforderung für die Heraufsetzung_ erforderlich ist. Wahrscheinlich sogar völlig unentdeckt.

@DHowett-MSFT Ich danke Ihnen für die Antwort. Sie gehen davon aus, dass wir die Ausführung bösartiger Prozesse sowieso zulassen. Wir schränken die Berechtigungen aus „Best Practices“-Mantras ein, die wir jeden Morgen mit unserer Pose des herabblickenden Hundes machen, aber wenn Sie wirklich befürchten, dass selbst ein paar Stunden erhöhter Terminalzugriff Sie in Gefahr bringen, _auf Ihrem eigenen System das du entwickelst on_ ...

1. Sie sollten Terminal und nicht ausführen
2. Sie sollten wischen und von vorne beginnen.

Ich gebe Ihnen zu, dass ein (Computer-)Virenforscher dies nicht in einem Vektorpfad riskieren sollte ... aber schon früh haben wir sie in VMs in einer Sandbox untergebracht. Aber "Terminal" ist nichts für Ihre ungeschickten Verwandten; es ist ein Elektrowerkzeug.

Es gibt eine Standardmethode für den Umgang mit dem Risiko. Präsentiert von der Browser-Welt. Wenn Sie zu den erweiterten Flaggen gehen, erhalten Sie eine Warnung von ungefähr "Here be dragons". (Ich denke, es ist genau das in Pale Moon ... dem ernsthaften Hardcore-Sicherheitsbrowser.) Fügen Sie die (nicht-UAC, zusätzliche) Warnung hinzu, aber lassen Sie den Benutzer entscheiden.

Eine andere Frage: Würden sich zwei unterschiedliche Sitzungen von Terminal, eine erhöhte, eine nicht, wie erwartet verhalten? Oder wären beide Vektoren für irgendwelche Sitzungen?

Ich bin nicht dagegen, dass die Leute in der Lage sein sollten, sich für so etwas zu entscheiden. :Lächeln:

zwei getrennte Sitzungen

Oh, ja, das sollte heute absolut funktionieren – und kein Vektor sein (der erhöhte läuft vollständig auf der High-IL-Seite der Welt und kann nicht von einem anderen Medium-IL-Prozess angetrieben werden)

das sollte heute unbedingt funktionieren

Können nicht im gleichen Sinne 2 Registerkarten in verschiedenen Prozessen ausgeführt werden und somit eine gemischte Anzeige im selben Fenster ermöglichen?

@DHowett-MSFT Warum können die beiden unterschiedlichen Sitzungen nicht in der übergreifenden App gehostet werden? Es ist wirklich nicht schwer zu tun.

Ich glaube, ich verstehe die Auswirkungen auf die Sicherheit, wenn Konsolen-Apps mit erhöhten Rechten überhaupt vorhanden sind, aber was ich nicht verstehe, ist, warum es _risikoreicher_ wäre, zwei Arten von Registerkarten (erhöhte und nicht erhöhte) in Windows Terminal zu haben als das, was Windows unterstützt seit Ewigkeiten, dh erhöhte und nicht erhöhte CMDs / PowerShells nebeneinander. Kann jemand etwas Licht ins Dunkel bringen?

@robomac
[1] Es ist trivial, wenn Sie traditionelle Fenster mit traditionellen Fenstergriffen hosten. Das funktioniert sehr gut im Conemu-Fall oder im Tabbed-Shell-Fall, wo Sie ein Fenster in einer erhöhten Sitzung übernehmen und es unter einem Fenster in einer nicht erhöhten Sitzung neu überlagern können.

Wenn Sie das tun, gibt es ein paar Sicherheitsfunktionen, auf die ich in [2] eingehen werde. Aus diesem Grund können Sie es erziehen, aber Sie können es nicht wirklich zwingen, etwas zu tun.

Es gibt jedoch ein Problem. Das Terminal ist nicht als eine Sammlung von neu zuordenbaren Fenstern konzipiert. Beispielsweise führt es keinen Konsolenhost aus und verschiebt sein Fenster in eine Registerkarte. Es wurde entwickelt, um eine „Verbindung“ zu unterstützen – etwas, das Text lesen und schreiben kann. Es ist ein Grundelement auf niedrigerer Ebene als ein Fenster. Wir erkannten den Fehler unserer Wege und entschieden, dass das UNIX-Modell die ganze Zeit richtig war, und Pipes, Text und Streams sind _wo es ist._

Angesichts der Tatsache, dass wir Xaml-Inseln verwenden, um eine moderne Benutzeroberfläche zu hosten und eine DirectX-Oberfläche darin einzufügen, sind wir ohnehin weit über die Welt der Standardfenstergriffe hinaus. Xaml-Inseln sind vollständig zu einem einzigen HWND zusammengesetzt, ähnlich wie Chrome und Firefox und die Bandbreite von DirectX/OpenGL/SDL-Spielen. Wir haben keine Komponenten, die in einem Prozess (erhöht) ausgeführt und in einem anderen (nicht erhöht) gehostet werden können, die nicht die oben genannten „Verbindungen“ sind.

Nun ist die offensichtliche Folgefrage _"Warum können Sie nicht eine erhöhte Verbindung in einem Tab neben einer nicht erhöhten Verbindung haben?"_ Hier sollte @sba923 mit dem Lesen beginnen (:smile:). Ich werde wahrscheinlich einige Dinge behandeln, die Sie (@robomac) bereits wissen.

[2] Wenn Sie zwei Fenster auf demselben Desktop in derselben Fensterstation haben, können sie miteinander kommunizieren. Ich kann SendKeys einfach über WScript.Shell verwenden, um Tastatureingaben an jedes Fenster zu senden, das die Shell sehen kann.

Das Ausführen eines Prozesses erhöhte _severs_ diese Verbindung. Die Shell kann das erhöhte Fenster nicht sehen. Kein anderes Programm auf derselben Integritätsebene wie die Shell kann das erhöhte Fenster sehen. Auch wenn es seinen Fenstergriff hat, kann es nicht wirklich damit interagieren. Aus diesem Grund können Sie auch nicht aus dem Explorer in den Editor ziehen und dort ablegen, wenn der Editor mit erhöhten Rechten ausgeführt wird. Nur ein anderer erhöhter Prozess kann mit einem anderen erhöhten Fenster interagieren.

Dieses "Sicherheits"-Feature (nennen Sie es wie Sie wollen, es war wahrscheinlich früher einmal als Sicherheitsfeature gedacht) existiert nur für einige wenige sitzungsglobale Objekttypen. Windows ist einer von ihnen. Pfeifen gehören nicht wirklich dazu.

Aus diesem Grund ist es trivial, diese Sicherheit zu brechen. Nehmen Sie das Terminal als Beispiel dafür. Wenn wir eine Verbindung mit erhöhten Rechten starten und sie in einem _nicht erhöhten_ Fenster hosten, haben wir plötzlich eine Leitung durch diese Sicherheitsgrenze geschaffen. Das erhöhte Ding am anderen Ende ist kein Fenster, sondern nur eine Anwendung im Textmodus. Es führt sofort das Bieten des nicht erhöhten Hosts aus.

Jeder, der den nicht erhöhten Host (wie WScript.Shell::SendKeys ) _kontrollieren_ kann, bekommt _auch_ eine sofortige Leitung durch die Höhengrenze. Plötzlich kann jede Anwendung mit mittlerer Integrität auf Ihrem System einen Prozess mit hoher Integrität steuern. Dies könnte Ihr Browser oder der Bitcoin-Miner sein, der mit dem left-pad -Paket von NPM installiert wurde, oder wirklich eine Reihe von Dingen.

Es ist ein kleines Risiko, aber es _ist_ ein Risiko.

Andere Plattformen haben dieses Risiko zugunsten der Benutzerfreundlichkeit in Kauf genommen. Sie haben damit nicht unrecht, aber ich denke, dass Microsoft Dinge wie „das Akzeptieren von Risiken für die Benutzerfreundlichkeit“ weniger „weitergibt“. Windows 9x war eine uneingeschränkte Sicherheitskatastrophe, und begrenzte Benutzerkonten und Eingabeaufforderungen für erhöhte Rechte und Sicherheit auf Kernel-Ebene für die Fensterverwaltung waren die Antwort auf diese Dinge. Sie sind keine Schlösser, die leicht gelockert werden sollten.

@DHowett-MSFT Vielen Dank für die Klarstellung. Ich denke, wir müssen uns daran gewöhnen, eine erhöhte Instanz von Windows Terminal und eine nicht erhöhte Instanz nebeneinander auszuführen, ähnlich wie wir es heutzutage mit Konsolen-Apps tun.

Faszinierend. Danke. Terminal, das eher ein Verbindungsrenderer als ein Fenster ist, macht Sinn. Gibt das PowerShell, das bereits eher auf Pipes/Verbindungen ausgerichtet ist, eine zusätzliche Kontrolle über zuvor in einer Fensterkonsole?

Sind separate Terminalsitzungen vollständig voneinander isoliert?

Ich wäre völlig zufrieden damit, nur einen Hinweis darauf zu haben, dass ich mich in einer erhöhten Sitzung befinde. Wie "Administrator: \ Das vermisse ich gerade ziemlich.

???

"Als anderer Benutzer ausführen" ist eine Sache, die alle Windows-Administratoren brauchen! Dies wäre sehr hilfreich, wenn es verfügbar ist. Die beste Option wäre, es mit einem Flag in der Konfiguration für jedes Profil zu haben.

Apropos Fensterisolierung, lassen Sie mich übrigens den neuesten ctfmon-Schwachstellenbericht zitieren

Der offensichtliche Angriff besteht darin, dass ein nicht privilegierter Benutzer Befehle in die Konsolensitzung eines Administrators einfügt oder Passwörter liest, während sich Benutzer anmelden. Selbst AppContainer-Prozesse in einer Sandbox können denselben Angriff ausführen.

@ecki Das ist schon eine ziemlich beunruhigende Neuigkeit. Ich bin mir sicher, dass Tavis danach heute Abend feiern geht.

@DHDHowett-MSFT
Wie viele hier geschrieben haben, wenn das neue Terminal nicht mit der Option „Als anderer Benutzer ausführen“ gestartet werden kann, ist es für eine große Anzahl von Benutzern nicht sehr brauchbar, auch ist es nicht kompatibel mit Microsofts „Active Directory-Verwaltungsebenenmodell“. wenn Sie beispielsweise einen AD-Benutzer mit Standardrechten haben und PS-Skripte mit einem Admin-Benutzer auf einem Domänencontroller ausführen.

Ich habe nicht viele Fälle, in denen ich ein Terminal mit meinem derzeit eingeloggten Benutzer starte… also frage ich Sie, was ist der Anwendungsfall dieses Terminals? Ping, nslookup usw., wenn das die Absicht ist, warum steckst du dann so viel Arbeit in all das?

Mit „Als Administrator ausführen“ haben Sie einige gültige Punkte, aber warum unterstützen andere Konsolen wie (PS6/7) diese Funktionen noch, wenn es so unsicher ist?

Ich dachte immer, die neue Terminal-App würde alle separaten cmd/PS/…-Fenster ersetzen, aber wie es scheint, ist sie in vielen Szenarien der realen Welt nicht verwendbar. Das ist irgendwie traurig, tbh ...

@Fisico Ihre Erfahrung ist nicht universell, und ich möchte Sie ermutigen, dies zu berücksichtigen, wenn Sie jemanden bitten, die Existenz seines Projekts zu rechtfertigen.

Zu Ihrem übergreifenden Punkt zu "Als anderer Benutzer ausführen", der nicht existiert/funktioniert nicht: Das ist eine Plattformbeschränkung, die wir versuchen aufzuheben. Es ist nicht aus Bosheit oder Inkompetenz, dass wir es nicht unterstützen.

Warum andere Konsolenanwendungen dies _do_ unterstützen, ist nicht unsicher, wenn sie dies tun, weil sie ausdrücklich nicht unterschiedliche Höhenstufen im selben Fenster hosten. Das ist das Kernproblem hier. Da sie in eigenständigen Prozessen mit eigenständigen Fenstern gehostet werden, sind sie frei von der Einschränkung einer Manipulation über Integritätsebenen hinweg.

@DHowett-MSFT
Entschuldigung, wenn ich Sie mit meinem Post beleidigt habe, es war nicht meine Absicht, ich habe zu viel Emotion hineingesteckt.
Ich denke, das Terminal ist eine großartige Idee und hat ein sehr großes Potenzial, und ich bin froh, dass Sie es mit der Community entwickeln, um das Beste daraus zu machen.

An diesem Punkt gibt es so viel Verwirrung darüber, was implementiert wird und was nicht.
„Als Administrator ausführen“ für die gesamte App funktioniert im Moment, soll das bleiben?

Soweit ich weiß, möchten Sie „Als Administrator ausführen“ für jede Registerkarte/jedes Profil nicht implementieren. Ich denke, das ist für die meisten von uns in Ordnung.

„Als anderer Benutzer ausführen“ ist nicht möglich, weil Windows es für Apps nicht unterstützt, und Sie/Wir müssen warten, bis Windows es unterstützt? Wenn ja, sprechen wir von Jahren?

„Als anderer Benutzer ausführen“ pro Tab/Profil ist auch etwas, das Sie nicht implementieren möchten?

@DHDHowett-MSFT
Wie viele hier geschrieben haben, wenn das neue Terminal nicht mit der Option "Als anderer Benutzer ausführen" gestartet werden kann
als für eine große Anzahl von Benutzern ist es nicht sehr brauchbar, ... Ich dachte immer, die neue Terminal-App wird es tun
Ersetzen Sie alle separaten cmd/PS/…-Fenster, aber wie es scheint, ist es in vielen Szenarien der realen Welt nicht verwendbar. Das ist irgendwie traurig, tbh ...

Ich bin nicht einverstanden. Dies ist ein großer Fortschritt gegenüber dem, was wir zuvor hatten. Unglücklicherweise haben sich die meisten von uns wahrscheinlich angewöhnt, ihre Granaten erhöht laufen zu lassen, weil es an einem granulareren Ansatz mangelt … und wir können es immer noch. Wir können sie nicht _mischen_, aber wir haben es nie getan. Im Ernst, bei den _letzten drei_ Unternehmen, bei denen ich war, hat das Entwickler-Wiki alle Builds/Tests in einer erhöhten VS-Eingabeaufforderung durchgeführt. Wir implementieren Sicherheit durch Echtzeit-Scans, aggressive aktive Firewalls und wissen, dass unsere Entwickler selten Fehler machen. Die _Nicht-Entwickler_ laufen niemals erhöht, weil (1) wir ihnen nicht vertrauen können und (2) sie es nicht müssen.

Ich jedenfalls bin dankbar für dieses neue Terminal. Es ist nicht perfekt, aber Take Command / TCC auch nicht. Das ist zumindest Standard.

@DHDHowett-MSFT
Wie viele hier geschrieben haben, wenn das neue Terminal nicht mit der Option "Als anderer Benutzer ausführen" gestartet werden kann
als für eine große Anzahl von Benutzern ist es nicht sehr brauchbar, ... Ich dachte immer, die neue Terminal-App wird es tun
Ersetzen Sie alle separaten cmd/PS/…-Fenster, aber wie es scheint, ist es in vielen Szenarien der realen Welt nicht verwendbar. Das ist irgendwie traurig, tbh ...

Ich bin nicht einverstanden. Dies ist ein großer Fortschritt gegenüber dem, was wir zuvor hatten. Unglücklicherweise haben sich die meisten von uns wahrscheinlich angewöhnt, ihre Granaten erhöht laufen zu lassen, weil es an einem granulareren Ansatz mangelt … und wir können es immer noch. Wir können sie nicht _mischen_, aber wir haben es nie getan. Im Ernst, bei den _letzten drei_ Unternehmen, bei denen ich war, hat das Entwickler-Wiki alle Builds/Tests in einer erhöhten VS-Eingabeaufforderung durchgeführt. Wir implementieren Sicherheit durch Echtzeit-Scans, aggressive aktive Firewalls und wissen, dass unsere Entwickler selten Fehler machen. Die _Nicht-Entwickler_ laufen niemals erhöht, weil (1) wir ihnen nicht vertrauen können und (2) sie es nicht müssen.

Ich jedenfalls bin dankbar für dieses neue Terminal. Es ist nicht perfekt, aber Take Command / TCC auch nicht. Das ist zumindest Standard.

Erhöht != Als anderer Benutzer ausführen.
Ich führe PowerShell mehr mit anderen AD-Benutzern aus, als mit meinem eigenen.
Ich bin bei Ihnen, dass Sie oft ein cmd oder PS als Administrator ausführen, auch wenn Sie es nicht müssen, aber es gibt so viele Fälle, in denen Sie es als Administrator ausführen müssen. Die meisten Sysadmin-Aufgaben erfordern Administratorrechte oder einen anderen Benutzer mit bestimmten Berechtigungen.
Sicher, wenn Sie cmds im Benutzerkontext ausführen müssen, ist alles in Ordnung.

Ich verstehe, dass "erhöht! = als anderer Benutzer ausführen". Ich glaube nur nicht, dass "Als anderer Benutzer ausführen" annähernd so verbreitet ist, wie Sie behaupten.

Ich verstehe, dass "erhöht! = als anderer Benutzer ausführen". Ich glaube nur nicht, dass "Als anderer Benutzer ausführen" annähernd so verbreitet ist, wie Sie behaupten.

Wenn Sie etwas mit dem Microsoft-Universum zu tun haben, dann brauchen Sie es unbedingt.
Es ist beispielsweise nicht die beste Idee, sich mit Domänenadministratorrechten bei Windows-Computern anzumelden.
Das Ausführen von PS-Skripts mit einem Benutzer, der über Domänenadministratorrechte oder einige andere Rechte verfügt, ist weit verbreitet.

@Fisico, warum dann nicht den Befehl New-PSSession verwenden?

Automatisierte Skripts, die eine bestimmte Art von Erhöhung für einen Dienst erfordern, erfordern normalerweise „Als anderer Benutzer ausführen“. Ob das für Terminal gilt, ist eine andere Geschichte. Sie können Ihr Login jederzeit einmal in einer CMD- oder PS-Sitzung mit dem Befehl runas ändern. Dies würde den Höhenstatus der Registerkarte nicht ändern, da sie die zugrunde liegende Anmeldung verwendet, die Ihr normaler Benutzer ist. Auch für alle Skripts, die Sie mit dem Taskplaner oder einem Cron-Job ausführen würden, muss Terminal nicht ausgeführt werden, es sei denn, Sie verwenden es, um eine Funktionalität zu erhalten, die in einer normalen Konsolensitzung irgendwie nicht vorhanden ist. Wenn dies der Fall ist, wäre die Verwendung von Parametern zum Ausführen dieses Skripts mit Terminal, das als Hintergrundprozess gestartet wird, die Lösung.

Daher ist eine gemischte Ansicht für Registerkarten nicht erforderlich. Wir haben eine Problemumgehung und es ist einfach genug, die spezifischen runas-Befehle, die Sie benötigen, in eine txt-Datei zu kopieren, die Sie kopieren/in das Terminal einfügen und dann Ihr Passwort eingeben können (Sie sollten Ihr Passwort niemals in etwas unverschlüsseltem speichern).

@ Samuel Englard
Ich möchte keine Verbindung zu einem Remote-Host herstellen, um ein Skript auszuführen.

@WSLUser Ja, es ist eine Option, Runas zu verwenden, aber es ist viel bequemer, das Terminal oder PS einfach als ein anderer Benutzer auszuführen. Ich verstehe nicht, warum das ein Problem sein sollte.

@Fisico New-PSSession muss keine Verbindung zu einem Remote-Computer herstellen, siehe den zweiten ersten Syntaxeintrag.

@ Samuel Englard
Ich möchte keine Verbindung zu einem Remote-Host herstellen, um ein Skript auszuführen.

@WSLUser Ja, es ist eine Option, Runas zu verwenden, aber es ist viel bequemer, das Terminal oder PS einfach als ein anderer Benutzer auszuführen. Ich verstehe nicht, warum das ein Problem sein sollte.

Es ist ein ziemlich normaler Vorgang für einen Benutzer, PowerShell an die Taskleiste anzuheften und mit der rechten Maustaste zu klicken, um als Administrator ausgeführt zu werden, oder in einigen Umgebungen RunAs OtherUser, da ein Konto mit erhöhten Rechten zum Ausführen eines Skripts auf Unternehmensebene erforderlich ist. Zu sagen, dass es für das Terminal nicht möglich ist, ist wie die Umgebungen, die PSLockDown nutzen und RunAs Admin zwingen, nur die Shell oder VSCode zu laden
meiner bescheidenen Meinung nach

Wenn Sie wirklich einen Tab haben müssen, der als ein anderer Benutzer ausgeführt wird, können Sie ein Profil haben, das beim Start New-PSSession -Credential | Enter-PSSession ausführt.

HAFTUNGSAUSSCHLUSS : Ich übernehme keine Verantwortung für Computer, die dadurch beschädigt werden.

Wenn Sie wirklich einen Tab haben müssen, der als ein anderer Benutzer ausgeführt wird, können Sie ein Profil haben, das beim Start New-PSSession -Credential | Enter-PSSession ausführt.

> HAFTUNGSAUSSCHLUSS : Ich übernehme keine Verantwortung für Computer, die dadurch beschädigt werden.

Sicher, oder die hier stehende "Sicherheit" könnte überdacht werden. Wieder hefte ich PowerShell an meine Taskleiste an, von dort aus kann ich PowerShell ohne erhöhte Rechte starten; Ich kann mit der rechten Maustaste darauf klicken und „Als Administrator ausführen“ auswählen. Wenn ich in einer Unternehmensumgebung mit der rechten Maustaste auf das Symbol klicke, dann mit der rechten Maustaste auf „Windows PowerShell“ klicken und „Als anderer Benutzer ausführen“ auswählen, um PowerShell zu starten mit alternativen Ausweisen. Keine Sitzungen, kein RDP zu einem anderen Host, um diese Credentials zu erhalten.

Sicher, oder die hier stehende "Sicherheit" könnte überdacht werden. Wieder hefte ich PowerShell an meine Taskleiste an, von dort aus kann ich PowerShell ohne erhöhte Rechte starten; Ich kann mit der rechten Maustaste darauf klicken und „Als Administrator ausführen“ auswählen. Wenn ich in einer Unternehmensumgebung mit der rechten Maustaste auf das Symbol klicke, dann mit der rechten Maustaste auf „Windows PowerShell“ klicken und „Als anderer Benutzer ausführen“ auswählen, um PowerShell zu starten mit alternativen Ausweisen. Keine Sitzungen, kein RDP zu einem anderen Host, um diese Credentials zu erhalten.

Ja, und das kann ich auch mit Windows Terminal. Einverstanden. Ich sehe nicht, wie das denen hilft, die eine Mischung aus Registerkarten haben möchten, die als unterschiedliche Benutzer (oder unterschiedliche Höhen) ausgeführt werden.

Abgesehen von "gemischten Registerkarten" möchte ich nur klarstellen, dass Sie dies mit (der veröffentlichten Vorschau) Windows Terminal aufgrund des Designs von Windows Store-Apps NICHT tun können. Sie können nur als der Benutzer ausgeführt werden, der diese App installiert und sich als derselbe Benutzer angemeldet hat.

Alles, was ich will, ist in der Lage zu sein, das zu tun, was ich heute tue, mich als normaler Benutzer am PC anzumelden und erhöhte Shells auszuführen. Wenn Windows Terminal so veröffentlicht wird, wie es ist, nützt es mir wenig.

Sehr guter Punkt. Diese Einschränkung besteht nicht bei privaten (Nicht-Store-)Builds von Windows Terminal.

Abgesehen von "gemischten Registerkarten" möchte ich nur klarstellen, dass Sie dies mit (der veröffentlichten Vorschau) Windows Terminal aufgrund des Designs von Windows Store-Apps NICHT tun können. Sie können nur als der Benutzer ausgeführt werden, der diese App installiert und sich als derselbe Benutzer angemeldet hat.

Alles, was ich will, ist in der Lage zu sein, das zu tun, was ich heute tue, mich als normaler Benutzer am PC anzumelden und erhöhte Shells auszuführen. Wenn Windows Terminal so veröffentlicht wird, wie es ist, nützt es mir wenig.

Ich habe gerade zwei Instanzen des Store-Builds von Windows Terminal geöffnet - eine mit erhöhten Rechten und eine ohne. Also ich weiß nicht warum es bei dir nicht funktioniert.

Ok, ich muss glauben, dass Sie ein lokaler Administrator auf Ihrem PC sind. Um es klar zu sagen, vielleicht sollte ich das klarstellen. Ich bin nie ein lokaler Administrator auf meiner Workstation. Wenn ich also auf "Als Administrator ausführen" gehe, werde ich nach Benutzer/Passwort gefragt.

Das von mir verwendete „Admin“-Konto unterscheidet sich von meinem normalen Malware-/E-Mail-Lesekonto. Technisch gesehen führe ich also als anderer Benutzer aus. Dies ist die Einschränkung der Windows Store-App. Die Lösung (und vielleicht werden sie dies tun) besteht darin, dies als Windows-Komponente zu veröffentlichen, die diese Einschränkungen nicht hat.

* [DRINGEND] ALLES, ICH HABE EINE LÖSUNG FÜR DIESES PROBLEM GEFUNDEN! * *

Indem Sie dieser Anleitung folgen
https://www.maketecheasier.com/access-windowsapps-folder-windows-10/
Sie können den Windows-App-Ordner zu Ihrem eigenen machen!

Sobald Sie dies getan haben, können Sie den Ordner Microsoft.WindowsTerminal._blahblahYourVersion_ finden. Sobald Sie drinnen sind, suchen Sie die unten gezeigte WindowsTerminal.exe

Sobald Sie es gefunden haben, erstellen Sie eine Verknüpfung dieser Datei und platzieren Sie sie an einer beliebigen Stelle. Danach stellen Sie es so ein, dass es als Administrator ausgeführt wird. Sie können dies tun, indem Sie mit der rechten Maustaste klicken und zu _Eigenschaften>Erweitert>Als Administrator ausführen_ gehen. Danach klicken Sie auf OK und Sie sind fertig!

Persönlich brauchte ich das, weil ich die Verknüpfung in meiner Taskleiste verwende, damit ich einfach _Windows + 1_ drücken kann, um es als Administrator zu starten. Nicht der lange Weg, durch mein Startmenü zu navigieren, um es korrekt auszuführen.

Sie können auch einfach das Paket entpacken, das wir auf der Veröffentlichungsseite bereitgestellt haben. Es ist nur eine ZIP-Datei. Bitte beachten Sie, dass wir die unverpackte Ausführung _nicht offiziell unterstützen_!

Aber das bedeutet immer noch, dass es keine _unterstützte_ Möglichkeit gibt, erhöht zu laufen! Ich denke, das ist ein Must-Have-Feature.

In der Tat stehe ich korrigiert.

Was _fehlt_ ist der Eintrag "Als Administrator ausführen" im Kontextmenü der Taskleistenverknüpfung.

Habe gestern bei einem Meetup mit ein paar Leuten gesprochen und ein paar Leute sagten, sie starten Powershell hauptsächlich mit Windows+X und würden gerne Terminal / Terminal als Admin dort haben.

Sehr guter Punkt!

Das ist genau mein Punkt! Dies ist die Lösung, um es über die Taskleiste auszuführen
mit Adminrechten!

Am So, 25. August 2019, 1:08 Uhr Stéphane BARIZIEN [email protected]
schrieb:

Sehr guter Punkt!

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/microsoft/terminal/issues/632?email_source=notifications&email_token=AKO4CP6JWWDNLGCHWNIJGFTQGIOULA5CNFSM4HL5EE72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CNA6Q#issuecomment-524603514 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AKO4CPZ6YRX5V3ERW4L2GWLQGIOULANCNFSM4HL5EE7Q
.

In der Tat stehe ich korrigiert.

Was _fehlt_ ist der Eintrag "Als Administrator ausführen" im Kontextmenü der Taskleistenverknüpfung.

Klicken Sie in der Taskleiste zweimal mit der rechten Maustaste. Einmal auf das Symbol, damit das Kontextmenü erscheint, dann ein zweites Mal auf den App-Namen. zB "Windows Terminal (Vorschau)" und wählen Sie "Als Administrator ausführen"

Ich bin verwirrt.

Erröten.

Beschämt.

Wie kommt es, dass ich nicht daran gedacht habe?

Danke trotzdem fürs Teilen mit uns allen!

Betrachten wir das Problem von der anderen Seite...
Windows lässt nicht erhöhte Prozesse andere nicht erhöhte Prozesse steuern, Tastenanschläge senden, ihre Benutzeroberfläche erfassen usw., verhindert jedoch, dass nicht erhöhte Prozesse dies für ein Fenster eines erhöhten Prozesses tun.
Das Windows-Terminal ist so konzipiert, dass es auch zur Verwaltung von Remote-Servern über ssh, PowerShell-Remoting usw. verwendet werden kann.
Das bedeutet, dass das Windows Terminal zu einer Sicherheitslücke wird, sobald es für die Verwaltung verwendet wird, da eine lokale Malware auf eine Windows Terminal-Sitzung warten könnte, um das Verhalten des Benutzers auszuspionieren, und sobald es eine Remote-Shell erkennt, dies versucht inject-Befehle, um den Server mit Administratorrechten zu infizieren.

Das Verhindern, dass das Windows-Terminal als Administrator ausgeführt wird, scheint überhaupt keine Sicherheitsverbesserung zu sein, da die Ausführung als Administrator den Benutzer stattdessen vor nicht erhöhten Prozessen schützen würde, die ihre Remote-Shell-Sitzungen entführen. Es sollte dem Benutzer empfohlen werden, es als Administrator auszuführen, wenn er ein Tool verwendet, das ihm lokal oder remote eine Eingabeaufforderung mit erhöhten Rechten gibt.

Und bezüglich sudo für Windows, weist das Ausführen des sshd-Dienstes und das anschließende Herstellen einer Verbindung mit localhost von einer Shell ohne erhöhte Rechte nicht das gleiche Sicherheitsproblem auf?

Das bedeutet, dass das Windows Terminal zu einer Sicherheitslücke wird, sobald es für die Verwaltung verwendet wird, da eine lokale Malware auf eine Windows Terminal-Sitzung warten könnte, um das Verhalten des Benutzers auszuspionieren, und sobald es eine Remote-Shell erkennt, dies versucht inject-Befehle, um den Server mit Administratorrechten zu infizieren.

Es stimmt zwar, dass das entfernte System infiziert werden könnte (vorausgesetzt, der entfernte Prozess hat Administratorrechte), aber das bedeutet nicht, dass wir ihn auch das lokale System infizieren lassen sollten.

Das Verhindern, dass das Windows-Terminal als Administrator ausgeführt wird, scheint überhaupt keine Sicherheitsverbesserung zu sein, da die Ausführung als Administrator den Benutzer stattdessen vor nicht erhöhten Prozessen schützen würde, die ihre Remote-Shell-Sitzungen entführen. Es sollte dem Benutzer empfohlen werden, es als Administrator auszuführen, wenn er ein Tool verwendet, das ihm lokal oder remote eine Eingabeaufforderung mit erhöhten Rechten gibt.

Nichts hindert Sie daran, das Windows-Terminal jetzt mit Administratorrechten auszuführen. Das vorliegende Problem besteht darin, Tabs mit erhöhten und nicht erhöhten Tabs gemischt zu haben.

@SamuelEnglard treffend auf die Antwort.

Außerdem versuchen wir, das Hinzufügen von _neuen_ Sicherheitslücken zu vermeiden. Die ursprüngliche Konsole hatte die gleichen Probleme bei der Remote-Serververwaltung. Dagegen können wir leider nichts machen. Benutzer, die Remote-Serververwaltung durchführen, führen ihre Konsolen/Terminals immer erhöht aus, und das gibt ihnen zusätzliche Sicherheit (obwohl ich kein Sicherheitsexperte bin und diese Aussage nicht als Rat auffassen würde).

Idee für den Fortschritt bei diesem Problem: Versuchen Sie, die gesamte _app_ mit erhöhten Rechten auszuführen, und wenn dies gelingt, fügen Sie neben jeder „Öffnen“-Schaltfläche eine Schaltfläche mit dem Symbol eines UAC-Schildes hinzu und fügen Sie eine Präfix-Tastenkombination zum Öffnen einer Registerkarte mit erhöhten Rechten hinzu: Strg Umschalt E . (Ich habe überprüft und dies war ungebunden.) Es funktioniert nur für die nächste geöffnete Registerkarte.

Wie auch immer, die geöffneten Registerkarten haben ein UAC-Symbol vor ihrem normalen Symbol und werden als Administrator ausgeführt. (Denken Sie daran, dass Programme diese Schlüssel nicht mehr senden können. Wir haben die App als Administrator ausgeführt.)

Die App sollte versuchen, automatisch zu erhöhen, und wenn dies fehlschlägt, normal ausgeführt werden und diesen gesamten Thread ignorieren.

In der Tat stehe ich korrigiert.
Was _fehlt_ ist der Eintrag "Als Administrator ausführen" im Kontextmenü der Taskleistenverknüpfung.

Klicken Sie in der Taskleiste zweimal mit der rechten Maustaste. Einmal auf das Symbol, damit das Kontextmenü erscheint, dann ein zweites Mal auf den App-Namen. zB "Windows Terminal (Vorschau)" und wählen Sie "Als Administrator ausführen"

Ich habe gerade bemerkt, dass die UAC-Eingabeaufforderung, die man in diesem Fall erhält, "Unbekanntes Programm" lautet.

Eher unerwartet, wenn Sie mich fragen ...

@sba923 das ist #2289 :smile:

@DHowett-MSFT danke für die Info; Gut zu wissen, dass das (bereits) verfolgt wird.

Die beste Antwort darauf, die ich mir vorstellen kann, ist die Option, ein Profil zu haben, das erhöht werden muss, und wenn das aktuelle Fenster nicht erhöht ist, starten Sie eine neue Instanz mit erhöhten Rechten mit diesem Profil. (Überlegen Sie, wie private Browsersitzungen funktionieren)

Sehr gute Idee

Ich habe diese Methode verwendet, um das Terminal im Win+X-Menü hinzuzufügen:
Erstellen Sie eine neue Verknüpfung mit dem Ziel:
C:\Windows\explorer.exe shell:appsFolder\Microsoft.WindowsTerminal_xxxxxxxxxxxx!App
bearbeiten:
Tut mir leid, das funktioniert nicht, wenn Sie die App als Administrator ausführen möchten.
Stattdessen können Sie nircmd verwenden und eine Verknüpfung mit erstellen
cmd.exe /q /c nircmd elevate "shell:appsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App"

(den korrekten Pfad für „Microsoft.WindowsTerminal_xxxxxxxxxxxx“ kann man mit dem PS-Befehl „Get-appxpackage *WindowsTerminal*“ ermitteln, dazu den Eintrag in PackageFamilyName verwenden)

Diese Verknüpfung kann verwendet werden, um das Terminal mit Administratorrechten mit einem einfachen Doppelklick zu starten und mit WinXEditor im Win+X-Menü hinzuzufügen.
Hinweis: Das Terminal muss auch im Administratorkonto installiert werden.

Ist die Idee alle Profile als Administrator zu laden oder nur bestimmte? Am liebsten hätte ich es per individuellem Profil. Vielleicht eine Eigenschaft, die das Konto "runas" ist und eine andere als "iselevated"?

Wie in diesem Thread ausführlich besprochen, können Sie in derselben Instanz von Windows Terminal keine Mischung aus erhöht und nicht erhöht haben, und dies wird nicht hinzugefügt.

In der Tat stehe ich korrigiert.
Was _fehlt_ ist der Eintrag "Als Administrator ausführen" im Kontextmenü der Taskleistenverknüpfung.

Klicken Sie in der Taskleiste zweimal mit der rechten Maustaste. Einmal auf das Symbol, damit das Kontextmenü erscheint, dann ein zweites Mal auf den App-Namen. zB "Windows Terminal (Vorschau)" und wählen Sie "Als Administrator ausführen"

FWIW, ich habe gerade Umschalt- und Rechtsklick getestet, wodurch die Option "Als Administrator ausführen" sofort angezeigt wird - nur geringfügig schneller als die Option mit zwei Rechtsklicks, die zuvor meine erste Wahl war.

Hey Leute, habt ihr die UAC vergessen? Die Anwendung kann auf dem sicheren Desktop nicht auf Dinge klicken.

FWIW, ich habe gerade Umschalt- und Rechtsklick getestet, wodurch die Option "Als Administrator ausführen" sofort angezeigt wird - nur geringfügig schneller als die Option mit zwei Rechtsklicks, die zuvor meine erste Wahl war.

Sie können auch Strg + Umschalttaste + Linksklick auf das Symbol drücken, um die Benutzerkontensteuerung sofort aufzurufen.

Super, vielen Dank! Wie viele Abkürzungen müssen wir uns merken? ;-)

Zu Ihrem übergreifenden Punkt zu "Als anderer Benutzer ausführen", der nicht existiert/funktioniert nicht: Das ist eine Plattformbeschränkung, die wir versuchen aufzuheben. Es ist nicht aus Bosheit oder Inkompetenz, dass wir es nicht unterstützen.

Warum andere Konsolenanwendungen dies _do_ unterstützen, ist nicht unsicher, wenn sie dies tun, weil sie ausdrücklich nicht unterschiedliche Höhenstufen im selben Fenster hosten. Das ist das Kernproblem hier. Da sie in eigenständigen Prozessen mit eigenständigen Fenstern gehostet werden, sind sie frei von der Einschränkung einer Manipulation über Integritätsebenen hinweg.

Ich hoffe auf jeden Fall, dass das Ausführen als ein anderer Benutzer irgendwann kommt. Obwohl dies nicht der Großteil meiner täglichen Aktivitäten ist, erfordern einige Powershell-Cmdlets eine Erhöhung (und ich führe sie mit verschiedenen Benutzern aus, denken Sie an einen geschützten Benutzeradministrator).

Es ist nicht das Ende der Welt, aber es wird sicherlich ärgerlich sein, auf die alten Shells zurückgreifen zu müssen.

Mit der Zeit, schätze ich!

Es gibt absolut kein Problem / keine Einschränkung bei der Verwendung von Windows Terminal mit erhöhten Rechten, sodass Sie sich nicht an die „Legacy-Shells“ halten müssen (oder genauer gesagt: an den Legacy-Konsolenhost).

Es ist nur so, dass Sie erhöhte und nicht erhöhte nicht in derselben Instanz (in verschiedenen Registerkarten) mischen können.

Es gibt absolut kein Problem / keine Einschränkung bei der Verwendung von Windows Terminal mit erhöhten Rechten, sodass Sie sich nicht an die „Legacy-Shells“ halten müssen (oder genauer gesagt: an den Legacy-Konsolenhost).

Es ist nur so, dass Sie erhöhte und nicht erhöhte nicht in derselben Instanz (in verschiedenen Registerkarten) mischen können.

Ich denke, ich habe das Obige möglicherweise falsch interpretiert, aber es gibt eine Plattformbeschränkung, wenn das Terminal unter einem anderen Benutzerkontext ausgeführt wird als dem, was ich lese.

Ich denke, ich habe das Obige möglicherweise falsch interpretiert, aber es gibt eine Plattformbeschränkung, wenn das Terminal unter einem anderen Benutzerkontext ausgeführt wird als dem, was ich lese.

Yah, dieser Thread war an diesem Punkt überall. Ich bin kein Administrator auf meinen Workstations, daher fordert mich „Als Administrator ausführen“ lediglich auf, meine „erhöhten Creds“ einzugeben.

Wir sollten wahrscheinlich einfach einen neuen Thread zu diesem Anwendungsfall aufmachen.

Um es klar zu sagen, was ich meine (und ich denke, dass viele „Administratoren“ es brauchen) ist die Möglichkeit, als normaler Benutzer an unserer Workstation angemeldet zu sein. Führen Sie dann "irgendeine Shell" als Benutzer mit erhöhten Rechten aus, z. B. als Domänenadministrator, um AD-Arbeiten zu erledigen.

Richtig oder falsch, das ist es, was einige von uns tun und brauchen. Alle Tricks zur Installation der Konsole aus dem Store als dieser Benutzer und die Entwicklung cleverer Verknüpfungen haben bei mir nicht wirklich funktioniert.

Und ja, ich kann dies auf verschiedene Arten tun, und vielleicht sollte ich einige dieser Aktivitäten auf eine geschützte Workstation beschränken, aber die Realität ist, dass ich als normaler Benutzer im Allgemeinen keine Shell benötige.

IMVHO, die Verwirrung rührt von der Tatsache her, dass die Leute die Begriffe „erhöht“ und „als anderer [Domain] [Admin]-Benutzer“ mehr oder weniger austauschbar verwenden (Halten Sie fest, dass die Vor-Vista-Gewohnheiten schwer sterben).

Das Ausführen als ein anderer Benutzer ist nicht dasselbe wie das Ausführen erhöhter Benutzerrechte.

1. Einige der Personen in diesem Thread müssen, wenn sie als Administratorbenutzer angemeldet sind, Windows Terminal-Workloads mit erhöhten Rechten ausführen.

2. Einige andere Personen müssen, wenn sie als normaler Benutzer (oder Nicht-Domänenadministrator) angemeldet sind, Windows Terminal-Workloads als einen anderen Administratorbenutzer ausführen, normalerweise mit Anhebung.

3. Man könnte auch den Fall in Betracht ziehen, in dem Personen als normaler Benutzer A angemeldet sind und Windows Terminal-Workloads als Benutzer B ohne Erhöhung ausführen möchten.

In Nr. 2 und Nr. 3 macht die Windows Store-basierte Bereitstellung die Geschichte komplexer, da Windows Terminal nicht als angemeldeter Benutzer ausgeführt wird, wo die „Store-Apps“ für diesen Benutzer bereitgestellt werden.

Hoffe ich verstehe die Situation richtig. Wenn ja, hoffe ich, dass dies die Angelegenheit ein wenig klärt.

Du hast es genau richtig getroffen.

Nur zu Ihrer Information, genau dieses Problem, das nicht in der Lage ist, die Höhe zu erhöhen ("Als Administrator ausführen", im Gegensatz zur Ausführung als anderer Administrator, "Als anderer Benutzer ausführen"), wenn das Konto, mit dem Sie angemeldet sind, kein lokaler Administrator auf dem System ist. gemäß Best Practices), wurde kurz in einer anderen Ausgabe behandelt: https://github.com/microsoft/terminal/issues/1538 . Das wurde mit einer Erklärung geschlossen, dass es sich um ein Windows-Problem handelt, nicht um ein Terminal-Problem, da es sich anscheinend um eine Einschränkung von Store-Apps handelt.

Ohne in eine Debatte darüber zu geraten, ob dies als MSI-Installation hätte veröffentlicht werden sollen, anstatt den Store zu verwenden, gibt es in diesem Thread, den ich verwendet habe, eine Problemumgehung. Melden Sie sich kurz mit Ihrem Admin-Konto an, installieren Sie die App aus dem Store und melden Sie sich dann wieder ab. Als Administrator ausführen funktionierte dann für mein normales Benutzerkonto (bis zum nächsten Update, wenn es wieder gemacht werden muss).

Ja, es sollte ein MSI verfügbar sein. Mein neuer Arbeitgeber verbietet (öffentliche) Store-Installationen, sodass ich Windows Terminal nur verwenden kann, wenn ich aus dem Quellcode baue ...

Enttäuscht zu sehen, dass Sie Windows Terminal nicht "als Administrator" ohne Fehler ausführen können und dann eine Problemumgehung implementieren müssen. Ich würde sagen, dass viele Unternehmen einen Ansatz zur Trennung von Privilegien für Identitäten implementieren (wobei ICT-Mitarbeiter ein privilegiertes und ein nicht privilegiertes Konto haben). In der Lage zu sein, diese Anforderung durch Bereitstellung einer optionalen MSI-Bereitstellung gemäß dem Vorschlag von @ sba923 zu erfüllen, wäre also ein ordentlicher Ansatz, bis gebündelte Apps in dieser Zeit mit der Privilegientrennung fertig werden?

Dies ist eine VORSCHAU, nicht einmal 1.0-Version ...

Ich habe das Gefühl, dass dieses Thema an dieser Stelle ziemlich gut diskutiert wurde, aber es gibt eine Perspektive, die ich noch nicht verstanden habe: Warum können wir keine Windows-Verknüpfung zu dieser App erstellen? Das ist die typische Problemumgehung für „Immer als Administrator starten“ – die typische Problemumgehung besteht darin, eine Verknüpfung zu erstellen und die Verknüpfung so zu ändern, dass sie standardmäßig erhöhten Zugriff verwendet.

Kann mir bitte jemand erklären, warum wir keine Verknüpfung zu dieser App erstellen können? Dies hängt wahrscheinlich mehr mit dem Innenleben von Windows als mit dem Innenleben von Terminal zusammen, aber ich habe das Gefühl, dass wir um den heißen Brei herumreden, wenn ich es nicht direkt frage.

Danke.

Ich bewahre nircmd zusammen mit vielen anderen häufig verwendeten Tools in meinem Ordner c:\utils auf.
Ich habe ein Profil hinzugefügt, das so aussieht:

        {
            "name": "Admin Terminal",
            "startingDirectory": "c:\\utils\\",
            "commandline": "cmd.exe /q /c nircmd elevate \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
            "hidden": false
        },

Es ruft eine UAC-Erhöhungsanforderung auf und öffnet dann eine Administratorinstanz von Windows Terminal. Es ist eine anständige Problemumgehung für den Moment.

Ich hätte kein Problem damit, Sitzungen als erhöht zu kennzeichnen und sie ehrlich gesagt in einem neuen Fenster öffnen zu lassen.

Ich bin hierher gekommen, um nach einer ordentlichen Lösung zu suchen, aber da es anscheinend nicht existiert, werde ich nur meine hackige Lösung teilen. Ich habe ein Profil zum Ausführen von Powershell mit erhöhten Rechten hinzugefügt:

{
...
  "commandline" : "powershell.exe -Command \"Start-Process PowerShell -Verb RunAs\"",
...
}

Es erscheint in einem separaten Fenster, aber es erledigt die Arbeit.

Ich habe das Gefühl, dass dieses Thema an dieser Stelle ziemlich gut diskutiert wurde, aber es gibt eine Perspektive, die ich noch nicht verstanden habe: Warum können wir keine Windows-Verknüpfung zu dieser App erstellen? Das ist die typische Problemumgehung für „Immer als Administrator starten“ – die typische Problemumgehung besteht darin, eine Verknüpfung zu erstellen und die Verknüpfung so zu ändern, dass sie standardmäßig erhöhten Zugriff verwendet.

Kann mir bitte jemand erklären, warum wir keine Verknüpfung zu dieser App erstellen können? Dies hängt wahrscheinlich mehr mit dem Innenleben von Windows als mit dem Innenleben von Terminal zusammen, aber ich habe das Gefühl, dass wir um den heißen Brei herumreden, wenn ich es nicht direkt frage.

Danke.

@aaronsteers , du hast Recht, dass es mehr um Windows als um Terminal geht. Das Hauptproblem hier ist, dass wir als „modernes Anwendungspaket“ vertrieben und installiert werden. Sie haben eine Reihe von Einschränkungen und zufälligen Einschränkungen im Vergleich zu nativen Anwendungen, aber es ist für Terminal notwendig, weil es auch die am wenigsten schwierige Möglichkeit ist, Komponenten der „modernen Windows-API“ (WinRT) zu verwenden. Es ist fast immer für alle im Team furchtbar frustrierend. :Lächeln:

Wir versuchen, diese Frustration und die Frustration der Community in Fortschritte für die Plattform umzuwandeln. Ich werde mich jedoch entschuldigen, dass diese Änderung hier in Windows nicht schnell ist!

@DHowett Ich versuche wirklich zu verstehen, weil ich 2/3 Terminal mag, aber es macht nicht einige Grundlagen, an die ich von TakeCommand oder ConEmu usw. gewöhnt bin.

Ich kann Höhen in den verschiedenen Registerkarten nicht mischen. Wenn ich das verstehe, liegt das daran, dass Sie eine andere Art von App sind und die Shell nicht wirklich hosten?

Der Scrollback-Puffer wird in keiner der drei Umgebungen (cmd, PowerShell, wsl bash) gelöscht. In meinen normalen Shells ist dies der Fall. Wieder wegen der Art und Weise, wie es gehostet wird?

Und es wäre ganz nett, ein Kontext- oder Dropdown-Menü zu haben, das besser zugänglich ist. Zum Beispiel, um diesen Scrollback zu löschen, wenn man bedenkt, dass selbst der Konsolen-Escape-Trick bei mir nicht funktioniert hat.

Die Integration der Umgebungen und wie gut WSL-Linux-Shells aufgenommen werden, ist wirklich nett. Aber es kostet viel Benutzerfreundlichkeit durch die Höhen- und Scrollback-Probleme, also benutze ich es selten.

@robomac Hier gibt es einen großartigen Beitrag von @DHowett- MSFT , der erklärt, warum wir erhöhte und nicht erhöhte Tabs nicht in demselben nicht erhöhten Fenster mischen können.

Das tl;dr lautet: Wenn wir Benutzern erlauben, sich von einem nicht erhöhten Terminalfenster aus mit erhöhten Befehlszeilen zu verbinden, dann entsteht eine riesige Sicherheitslücke, durch die andere nicht erhöhte Anwendungen den erhöhten Prozess effektiv über das Terminalfenster steuern könnten.

Ich weiß nicht, wie ConEmu dieses Risiko mindert, wenn überhaupt. Es ist durchaus möglich, dass es sich um eine Sicherheitslücke handelt, die conemu erstellt und die wir nicht gerne als Teil des Windows-Terminals versenden.

Der Rest Ihrer Bedenken sind alle Probleme, die an anderer Stelle in diesem Repo verfolgt werden. Ich schlage vor, nach ihnen zu suchen, um ihren Fortschritt einzeln zu verfolgen. Wir würden diesen Thread lieber mit dem einzelnen Thema "gemischte Erhöhung von Tabs"/"ein Profil haben, das erhöht gestartet wird" belassen.

Zum Thema: Ich möchte mit der Route „Eine andere Instanz mit erhöhten Rechten starten“ für „erhöhte“ Profile experimentieren. Wenn die Benutzererfahrung nicht allzu schlecht ist, ist dies zumindest als Option ein möglicher Weg nach vorne.

ConEmu mindert dieses Risiko nicht. Sie geben dieses Risiko an ihre Benutzer weiter. (Ich bin nicht einmal sicher, ob sie dieses Risiko dokumentieren.)

Zum Thema „Eine andere Instanz mit erhöhten Rechten starten“: Ich hätte nichts gegen dieses Verhalten, solange es dieselbe erhöhte Instanz von Terminal für diese Registerkarten verwenden kann und nicht jedes Mal eine neue Instanz startet, wenn ich ein „erhöhtes“ Profil aufrufe.

Meiner Meinung nach ist die "Riesigkeit" dieser Sicherheitslücke etwas übertrieben. Es ist nicht normal, eine Malware auf dem eigenen Computer zu haben, die auf eine Chance wartet, hochgeladen zu werden, daher fühlt es sich nicht richtig an, den Komfort für die Sicherheit zu opfern.

Wenn andererseits das Endziel darin besteht, WT als Standardterminal mit Windows auszuliefern, würde dies die Angriffsfläche dramatisch vergrößern. Aber auch in diesem Fall würde ich persönlich ein Risiko mindern, indem ich eine unpopuläre Alternative verwende, die wahrscheinlich kein Ziel für einen solchen Angriff ist und die erforderliche Bequemlichkeit bietet (vorausgesetzt, das Erkennen des Vorhandenseins eines erhöhten Tabs in einem Terminal ist nicht trivial genug terminalspezifisch sein).

Einiges davon ist tl;dr für mich, aber wenn Sie das Paket nehmen und ausgeben, können Sie wt außerhalb von Sandboxing ausführen, was eine Erhöhung bedeutet, und ohne Probleme ausgeführt werden, wenn ein anderer Benutzer arbeitet. Ich hatte bei ignite mit MSFT darüber gesprochen und wurde aufgefordert, eine Pull-Anfrage einzureichen, aber meine VS-Kenntnisse sind ziemlich schwach. Was einfach genug wäre, wäre, es richtig zu signieren (muss dies mit meiner eigenen internen pki tun, damit ich auf Applocker laufen kann) und es in ein verteilbares MSI- oder MSIX-Format zu bringen. Es gibt hier oder da den einen oder anderen Fehler, der spezifisch für die Ausführung auf diese Weise sein kann, aber insgesamt funktioniert es wirklich gut. Im Moment habe ich nur eine Funktion zum Extrahieren, Signieren und Ersetzen / Aktualisieren einer auf Programmdateien basierenden Version aus der Store-basierten Version.

Ich verstehe das Risiko dieser Funktion, erhöhte Tabs in einen nicht erhöhten Prozess zu "stecken", aber ist es nicht möglich, umgekehrt vorzugehen?
Meine Meinung für Leute, die das brauchen, lassen Sie das Terminal selbst auch als erhöht laufen und erlauben Sie, nicht erhöhte Tabs zu starten?
Das hat natürlich andere Nachteile, aber für mich (und ich denke auch für andere) sind sie akzeptabel.
(Sicher, das könnte "interessant" sein, da das Terminal eine Windows Store App ist, nicht sicher, ob das funktioniert)

PS. Entschuldigung für die Wiedereröffnung dieses Problems (auch wenn eine andere Person diesen Vorschlag bereits gemacht hat und ich das "übergelesen" habe).

Dank @EmTschi habe ich eine einfache und 100% bequeme Lösung gefunden
Es verwendet ein Kontextmenü und verhält sich ziemlich genauso wie PowerShell 7
https://github.com/nt4f04uNd/wt-contextmenu
Dort finden Sie eine Anleitung zur Implementierung und alle benötigten Dateien

Danke für den Tipp, das werde ich später mal ausprobieren.
Derzeit arbeite ich mit zwei Verknüpfungen auf meinem Desktop, die den Tasten Strg + Alt + T und Strg + Alt + Umschalt + T für ein erhöhtes Terminal zugeordnet sind. Als Problemumgehung ist es auch in Ordnung, aber ... nicht so schön wie es sein könnte und meilenweit entfernt von so etwas wie sudo.

@

Immer wenn ich versuche, die Terminal-App mit einem Administratorkonto auszuführen, klicken Sie mit der rechten Maustaste -> Als Administrator ausführen, die Benutzerkontensteuerung wird zweimal angezeigt und es wird ein Fehler angezeigt:
"Windows kann (Pfad\WindowsTerminal.exe) nicht finden Stellen Sie sicher, dass Sie ... eingegeben haben".
Der Pfad ist vorhanden und die App funktioniert ordnungsgemäß für den Benutzer ohne Administratorberechtigung, der die App erstellt hat, aber der andere Administratorbenutzer kann sie nicht ausführen.
Wenn ich mich beim Admin-Benutzer anmelde, ist die Terminal-App weder in den Einstellungen noch im Startmenü vorhanden, als wäre sie nie auf dem System installiert worden.
Gibt es eine Möglichkeit, die App so zu erstellen, dass sie für alle Benutzer installiert wird? Oder muss sich das Stammverzeichnis des Projekts in einem nicht benutzerspezifischen Verzeichnis befinden?

Ich sehe das gleiche Problem auch.

Windows-Version 18922.1000

Gerade auf Win10 Update 1909 installiert, und ich habe das gleiche Problem beim Versuch, als Administrator auszuführen

Selbes Problem hier. Ich kann Windows Terminal jetzt nicht verwenden, weil ich immer Docker ausführen muss und dann immer Admin im Terminal sein muss ...

Ich habe eine Hack-Around-Lösung für alle, die es wollen:

1. Laden Sie das msixbundle von der Release-Seite herunter
2. Entpacken Sie das, finden Sie dort die msix, die für Ihre Plattform ist (normalerweise die x64-Version).
3. Entpacken Sie das in einen Ordner irgendwo
4. Kopieren Sie diesen Ordner, wohin Sie möchten, und führen Sie WindowsTerminal.exe mit erhöhten Rechten oder wie Sie möchten aus

Ein Großteil dieses Versagens scheint auf die Bequemlichkeit zurückzuführen zu sein, dies als Store-App zu haben. Es gibt eine Diskussion darüber auf #1386 und jemand dort hat vielleicht die Installation mit Scoop erwähnt, was den obigen Extraktionsprozess automatisiert.

Es wäre schön, wenn als Bürger erster Klasse behandelt würden:

1. Portable Installationen (zip-Dateien – auch wenn die Konfiguration noch nicht portabel ist, da sie sich unter AppData\Local befindet, wenn der Windows Store-Installationsbereich verlassen wird)
2. Ein normales altes .exe-Installationsprogramm (oder, falls erforderlich, .msi) für Personen, die den Store nicht möchten oder das Store-Installationsprogramm verwenden möchten

Beide sind aus dem aktuellen Build-Verfahren nicht so schwierig zu implementieren, wie die Scoop-Automatisierung zeigt. Und jetzt, da Windows Terminal wirklich ziemlich gut wird, möchte ich es wie jedes andere Terminal verwenden können.

Wo wir gerade dabei sind: Sofern es keine API-Inkompatibilitäten gibt, wäre es großartig, die Option zu haben, Windows Terminal ohne den Store (sogar auf die „portable“ Art) auf früheren Versionen von Windows 10 zu installieren (mein Arbeitgeber blockiert uns unter 1809/ RS5, und die Installation aus dem Store ist blockiert).

@sba923 Wenn wir uns nicht auf APIs verlassen würden, die nur 1903 existieren, würden wir 1903 nicht benötigen.

Klar... war meine Vermutung 😜

Wird sich unternehmensweit für ein Upgrade einsetzen müssen, wird wahrscheinlich an eine Wand stoßen ...

Das ist so bescheuert.

Lassen Sie uns ein neues einheitliches Terminal für die Eingabeaufforderung, Powershell und Bash für Windows erstellen.
Kann ich cmd.exe als Administrator ausführen?
Nein.

Ich schätze, ich werde einfach meine cmd.exe- und Powershell-Symbole so voreinstellen, dass sie dann auf unbestimmte Zeit als Administrator in meiner Taskleiste ausgeführt werden.

Dummes Zeug wie dieses ist der Grund, warum meine Hauptarbeitsmaschine immer noch ein Macbook ist.

Das ist so bescheuert.

Lassen Sie uns ein neues einheitliches Terminal für die Eingabeaufforderung, Powershell und Bash für Windows erstellen.
Kann ich cmd.exe als Administrator ausführen?
Nein.

Ich schätze, ich werde einfach meine cmd.exe- und Powershell-Symbole so voreinstellen, dass sie dann auf unbestimmte Zeit als Administrator in meiner Taskleiste ausgeführt werden.

Dummes Zeug wie dieses ist der Grund, warum meine Hauptarbeitsmaschine immer noch ein Macbook ist.

Ich stimme in diesem Fall zu. Ich möchte ein einzelnes Windows Terminal-Fenster, das alle Terminal-Registerkarten enthält, die ich benötige, wobei jede Terminal-Registerkarte einer der mehreren installierten Terminal-Hosts sein und erhöht werden kann oder nicht.

Es scheint wirklich so, als ob diese gemischte Höhenfunktion durch die Entscheidung des technischen Designs, alle Registerkarten auf einem einzigen HWND-Handle zu hosten, zurückgehalten wird.

1) Können Sie das neue Terminal als Admin ausführen? JA (Es gibt Probleme dabei, je nachdem, wie Sie es installiert/gestartet haben, aber es besteht kein Wunsch, dass dies nicht funktioniert). (Wenn Sie nicht wissen, wie das geht, finden Sie in mehreren Beiträgen oben Informationen dazu, wie.

2) Können Sie eine Registerkarte mit erhöhten Rechten haben, während eine andere nicht? Nein . Siehe https://github.com/microsoft/terminal/issues/632#issuecomment -519375707 für den Grund.

Können sich die Leute bitte daran erinnern, dass es in dieser Ausgabe um gemischte Höhenregisterkarten geht?!? Wenn Sie den gesamten Prozess mit erhöhten Rechten starten möchten und dies nicht können, öffnen Sie bitte ein neues Problem.

@DHowett-MSFT Könnten wir dieses Problem so umbenennen, dass es sich um gemischte Höhenregisterkarten handelt?

Unabhängig davon, wie dies gehandhabt wird oder nicht, sollten erhöhte Terminals oder Registerkarten eine Art Indikator haben. Wenn ich jetzt ein neues Terminal mit Als Administrator ausführen starte, kann ich nicht einfach feststellen, dass meine cmd-Registerkarten im Vergleich zu denen im nächsten Fenster einen erhöhten Zugriff haben.

BEARBEITEN nach dem Kommentar von @SamuelEnglard : Offensichtlich habe ich cmd voreilig als schlechtes Beispiel ausgewählt. Ja, cmd zeigt 'Administrator:' im Tab-Titel. Aber WSL Ubuntu Bash auf meinem Standard-Tab überschreibt alles, was in seinem Tab-Titel stehen könnte. Ich schätze, bash weiß (oder kümmert sich nicht einmal darum) um die Erhöhung von Windows Terminal, sodass Informationen nicht verwendet werden können, wenn Titel innerhalb von bash aktualisiert werden (es gibt natürlich sudo -Situation, aber das ist eine andere Sache).

In Terminals profiles.json gibt es
"showTabsInTitlebar": false
aber mit dieser Einstellung signalisiert die Titelleiste des Terminals nicht die Höhe.

@janilahti sehen erhöhte CMD-Tabs nicht so aus
für dich?

Sicherheit ist ein strittiger Punkt, wenn niemand Ihr Tool verwenden möchte ...

Sie sollten einfach einen sudo-Befehl für Windows erstellen, der sowohl in cmd.exe als auch in Powershell funktioniert. Das würde mir die Mühe ersparen, eine Verknüpfung für beide so einzustellen, dass sie als Administrator ausgeführt werden.

Zu Ihrer Information, ich habe ein sudo for windows mit dem Namen gsudo geschrieben: https://github.com/gerardog/gsudo

Es unterstützt die Erhöhung cmd / powershell / pwsh Befehlen oder der gesamten Shell. Es ist einfach zu installieren und zu verwenden und sollte dem originalen *nix sudo ähneln. Es gibt andere sudo -Implementierungen in freier Wildbahn, aber meiner Meinung nach ist gsudo die vielseitigste und am einfachsten zu verwendende.

Sie können damit beispielsweise ein WT-Profil erstellen, das gsudo cmd / gsudo pwsh oder gsudo WhateverShell aufruft, um erhöhte Tabs zu starten. Installieren Sie gsudo und fügen Sie ein WT-Profil hinzu:

    {
      "hidden": false,
      "name": "PowerShell Core elevated",
      "commandline": "gsudo.exe pwsh"
    }

Es handelt sich um eine C#-Client-Server-App, die als Client fungiert, wenn sie nicht erhöht ist, und sich selbst als Server mit erhöhten Rechten startet. Beide Instanzen kommunizieren über gesicherte Named Pipes. Andere Windows-Sudos in freier Wildbahn sind meistens wie PowerShell-Runas-Skripte, die ein neues Fenster öffnen, aber als vollständige App konnte ich weit mehr Funktionen hinzufügen.

Ich habe den Thread gelesen und die Sicherheit eines sudo-Befehls wurde diskutiert und einige gültige Punkte wurden gemacht. Ich habe alle Sicherheitsmaßnahmen getroffen, die mir eingefallen sind, und ich bin offen (und plane), weitere davon einzuführen. An diesem Punkt sollte es so sicher/unsicher sein, als ob Sie eine Remote-Admin-PS-Sitzung öffnen oder ssh root@server von einer nicht erhöhten Konsole aus ausführen. (z. B. anfällig für Tastenanschläge oder Bildschirmabbruch, und korrigieren Sie mich, wenn ich falsch liege, aber ich verstehe, dass * nix sudo auf diese Weise auch anfällig ist). Es gibt auch den Cache für Anmeldeinformationen, der die Anzahl der UAC-Popups während einer 5-minütigen Sitzung reduziert (inspiriert von * nix sudo), was eindeutig ein Angriffsvektor ist, der über die Konfiguration deaktiviert werden kann. Für diejenigen, die sich Sorgen um die Sicherheit machen, plane ich, eine sehr einfache Möglichkeit hinzuzufügen, sie (durch Deaktivieren von Funktionen wie dem Cache für Anmeldeinformationen) mit einem einfachen Befehl oder über eine Unternehmensgruppenrichtlinie / Registrierungseinstellung zu verschärfen.

Ein interessanter Punkt in diesem Kommentar ist, dass Microsoft es sich nicht leisten kann, „ein Risiko für die Benutzerfreundlichkeit zu akzeptieren“. Wenn dies das letzte Wort von MS ist, dann sieht dies zumindest nach einer anständigen (voll funktionsfähigen) Problemumgehung aus, und alle Rückmeldungen/ Probleme oder Ideen zur Verbesserung der Sicherheit sind willkommen.

Kann nicht etwas sein, das ich installieren muss, das nicht offiziell unterstützt wird. Beendet jede Fähigkeit, es in einer Unternehmensumgebung zu verwenden.

Dann @hparadiz müssten Sie warten, bis eine neue Version von Windows mit einem neuen Sicherheitsdesign veröffentlicht wird, das ein offizielles Sudo (oder gemischte Registerkarten mit Höhen) ohne Sicherheitsrisiken zulässt. Sieht so aus, als würde es nicht bald passieren. Am besten warten Sie, bis das gesamte WT als Administrator gestartet werden kann, verfolgt in #4217, wahrscheinlich früher veröffentlicht.

Habe einen netten Hack aus einem Blog gefunden:

http://nuts4.net/post/windows-terminal-run-as-admin

@gerardog hast du einen Schaufeleimer für gsudo ? oder ist es in einem der bekannten? Ich bin derzeit auf einer Linux-Box, kann also nicht nachsehen.

@fluffynuts Es ist im Hauptrepo von Scoop. Also einfach 'scoop install gsudo'. Auch andere Installationsmethoden sind in https://github.com/gerardog/gsudo aufgelistet. Aber lasst uns diese Diskussion beim Wachtturm-Thema belassen. 😉

Offene Frage: Wenn es ein Sicherheitsrisiko darstellt, erhöhte und nicht erhöhte Tabs zu mischen, besteht dieses Risiko dann in ConEmu ? Denn genau das kann es. Oder implementiert ConEmu diese Funktion anders als in Terminal? Und im weiteren Sinne möchte ich anmerken, dass viele der hier angeforderten Funktionen (in diesem Thread und anderen) bereits in anderen Terminals vorhanden sind, ConEmu ist nur ein Beispiel, wenn Terminal-Entwickler also vorschlagen, dass diese Funktionen entweder nie implementiert oder nicht implementiert würden für eine sehr lange Zeit, Sie bestätigen implizit nur, dass wir Terminal nicht verwenden sollten.

Wenn wir uns nicht auf APIs verlassen würden, die nur 1903 existieren, würden wir 1903 nicht benötigen.

@DHowett-MSFT Gibt es eine öffentliche Dokumentation darüber, welche APIs dies sind und warum sie notwendig sind? Weil ich als externer Beobachter, wenn ich diese Entscheidung und die Entscheidung, UWP zu verwenden, sehe, keinen Mehrwert sehe. Ich sehe nur Hindernisse, wenn es darum geht, das hinzuzufügen, was viele Unternehmensbenutzer als grundlegende Funktionalität betrachten.

@dadpolice Siehe https://github.com/microsoft/terminal/issues/632#issuecomment -518888895 für die Aufgaben von ComEmu.

Ich dachte, "UAC ist laut Microsoft keine Sicherheitsbarriere"? Es wurde wie eines in Vista behandelt. Dann wurde uns gesagt, dass es keiner war und alle Probleme wie dieses waren ein Witz in Windows 7. Jetzt ist es heute wieder einer?

Möglicherweise müssen Sie in diesem Fall das Design des Datei-Explorers und der UAC-Whitelist überprüfen. :)

Oder hängt es nur davon ab, ob es eine Ausrede ist, eine Abkürzung zu nehmen, um etwas zu entwerfen, was normale Entwickler nicht dürfen (Datei-Explorer) oder eine wesentliche Funktion nicht zu implementieren (in diesem Fall)?

ein wesentliches Feature nicht implementieren (in diesem Fall)?

Ich möchte es klarstellen - wir versuchen nicht, diese Funktion _nicht_ zu implementieren. Es ist sicherlich ein wichtiges Feature, das wir implementieren _wollen_. Es ist etwas, dem ich gerade täglich begegne – ein zweites erhöhtes Fenster zu haben ist _okay_, aber es ist nicht _gut_.

Es wird nur eine Weile dauern, bis wir in der Lage sind, eine angemessen sichere Lösung zu entwerfen und dann auch den Engineering-Aufwand zu leisten, um sie tatsächlich zu implementieren. Es ist etwas, das wir diese Woche sogar für eine Weile mit dem Whiteboard versehen haben.

@zadjii-msft

[...]
Ich glaube nicht, dass wir planen, Tabs mit erhöhten und nicht erhöhten Tabs zu unterstützen, da dies eine Art Sicherheitslücke darstellt.
[...]

(wegen der Verlinkung verwandter Threads, #146)

Seltsam, dass die Leute den Eindruck hatten, dass das Feature nicht implementiert wird. Sarkasmus-Zeichen

@kort3x Es gibt einen Unterschied zwischen "No Plan" (auch bekannt als wir es nicht versprechen) und nicht wollen und tun, was sie tun können, um einen Weg zu finden, es umzusetzen.

Wie @zadjii-msft es ausdrückte:

Es wird nur eine Weile dauern, bis wir in der Lage sind, eine angemessen sichere Lösung zu entwerfen und dann auch den Engineering-Aufwand zu leisten, um sie tatsächlich zu implementieren. Es ist etwas, das wir diese Woche sogar für eine Weile mit dem Whiteboard versehen haben.

Solange sie keine sichere Lösung haben, werden sie nicht planen (auch bekannt als Versprechen), gemischte Höhenregisterkarten zu unterstützen. Ich bin bereit zu sein, dass die Sekunde, die eine sichere Lösung hat, sie dem Plan hinzufügen wird (obwohl ich nichts versprechen kann).

Ich dachte, "UAC ist laut Microsoft keine Sicherheitsbarriere"? Es wurde wie eines in Vista behandelt. Dann wurde uns gesagt, dass es keiner war und alle Probleme wie dieses waren ein Witz in Windows 7. Jetzt ist es heute wieder einer?

Soweit ich weiß, ist es eine Sicherheitsbarriere, wenn es als "Immer benachrichtigen" konfiguriert ist, andernfalls nicht.

Nun, das ist enttäuschend. Ich mag das Terminal (was viel aussagt, da ich im Allgemeinen ziemlich verliebt in Nicht-MS-Tools bin), aber die Unfähigkeit, reibungslos zu erhöhen, ist ein echtes Hindernis für mich, mehr Arbeit an diesem Betriebssystem zu leisten.

LOL okay ja, ich kann verstehen, wie verwirrend das ist. Ich habe diesen Kommentar ursprünglich Tage nach unserer ersten Ankündigung geschrieben, als es noch keinen Plan gab. Nach einigen Monaten der Diskussion bin ich sicherlich auf die Idee gekommen, dass dies mit mehr Aufwand möglich sein könnte. Ich werde den Kommentar aktualisieren, um dies widerzuspiegeln. @SamuelEnglard hat jedoch Recht, es ist schwer, sich dazu _zu verpflichten_, bis wir _wissen_, dass es möglich ist, es richtig zu machen.

Das ist ermutigend zu hören. Ist es möglich, diese Begeisterung auf andere Teams auszudehnen, sodass #3581 tatsächlich behoben werden kann?

Es wäre schön, wenn die Tabs von vornherein unterschiedliche Prozesse sein dürften (ähnlich wie Chrome es verwaltet), denn dann müsste ich nicht alle Tabs neu starten, nachdem ich sie schön gruppiert habe, nur um eine aktualisierte Umgebung in einem einzigen zu erhalten cmd-Registerkarte ...
Sobald das Windows-Terminal nur noch ein Manager ist, könnte es in einem nicht erhöhten Modus ausgeführt werden, während es weiterhin erhöhte Eingabeaufforderungen enthält. Das wäre nett. (Nun, das Wt erhöht laufen zu lassen, während nicht erhöhte Terminals gehalten werden, wäre auch für mich in Ordnung)

@ Rapus95 technisch gesehen sind die Registerkarten, dass die "Konsole" ein anderer Prozess ist. Windows Terminal ist bereits nur ein Manager

BEARBEITEN (14. Februar 2020)
Okay, dieser Kommentar ist also nicht besonders gut gealtert. Ursprünglich gab es _keinen_ Plan, dies zu unterstützen, da es mit der einzigen HWND , die wir hatten, nicht funktionieren würde. Wir arbeiten daran, eine Lösung zu entwerfen, die dies in Zukunft _möglicherweise_ unterstützt, aber wir können uns zu nichts verpflichten, bis wir sicher sind, dass wir eine angemessen sichere Lösung finden können, die sicherstellt, dass ein Prozess mit niedrigeren Privilegien dies nicht kann Fahren Sie ein Terminal mit höheren Privilegien.

Abgesehen von einigen anderen Punkten ist das der Hauptgrund, warum ich immer noch ConEmu verwende. Und ich wette, ich werde es jemals tun.
https://conemu.github.io/ @Maximus5

Das ist so bescheuert.

Lassen Sie uns ein neues einheitliches Terminal für die Eingabeaufforderung, Powershell und Bash für Windows erstellen.
Kann ich cmd.exe als Administrator ausführen?
Nein.

Dummes Zeug wie dieses ist der Grund, warum meine Hauptarbeitsmaschine immer noch ein Macbook ist.

@hparadiz Werfen Sie einen Blick auf ConEmu :-D Keine Probleme beim Ausführen mehrerer Shells als Registerkarten in EINEM Fenster; sogar das Ausführen erhöhter Powershell- und cmd.exe-Sitzungen neben nicht erhöhten Sitzungen.

@tmeckel sind wir sicher, dass conemu nicht die Sicherheitslücken hat, über die sich das Terminal-Team Sorgen macht? Benutzer wählen oft weniger sichere Software, weil sie tut, was sie wollen, aber auf eigene Gefahr.

@drdamour @tmeckel Das tut es. Ich habe die gleiche Frage oben gestellt, sie wird in einem anderen Thread beantwortet: https://github.com/microsoft/terminal/issues/632#issuecomment -518888895

Ich habe Terminal bisher ziemlich kritisch gesehen, aber um fair zu sein, gibt es bereits ConEmu und ConsoleZ und andere ähnliche Tools. Es hat wenig Wert, wenn Microsoft sie einfach kopiert, aber es ist von großem Wert, diese Funktionen auf sichere Weise neu zu erstellen. Trotzdem halte ich es immer noch für sehr dumm, einen Terminalemulator als reine Store-UWP-App zu erstellen, insbesondere jetzt, da Microsoft sich von UWP zu entfernen scheint (z. B. der neue Edge ist eine Win32-App).

Trotzdem halte ich es immer noch für sehr dumm, einen Terminalemulator als reine Store-UWP-App zu erstellen, insbesondere jetzt, da Microsoft sich von UWP zu entfernen scheint (z. B. der neue Edge ist eine Win32-App).

Um es klar zu sagen, das Terminal ist weder Store-only ( hier sind .msix-Dateien verfügbar ) noch eine UWP-Anwendung. Es handelt sich um eine Win32-Anwendung, die UWP XAML als UI-Framework verwendet.

@ Rapus95 technisch gesehen sind die Registerkarten, dass die "Konsole" ein anderer Prozess ist. Windows Terminal ist bereits nur ein Manager

Warum wird die Umgebung dann nicht für eine neue cmd-Instanz aktualisiert? Ich muss immer ein neues Windows-Terminal öffnen, was in gewisser Weise die allgemeine Benutzerfreundlichkeit von mehreren Registerkarten verringert ...

@ Rapus95, obwohl ich nicht sicher bin (ich müsste den Code durchsuchen), bin ich mir ziemlich sicher, dass jeder Unterprozess mit der Umgebung seines übergeordneten Elements gestartet wird, nicht mit einer neuen.

das scheint für einen Terminalmanager keinen Sinn zu machen 🤔

@rapus95 Es ist eigentlich ein Fehler, den wir hier verfolgen: #1125

Um es klar zu sagen, das Terminal ist weder Store-only ( hier sind .msix-Dateien verfügbar ) noch eine UWP-Anwendung. Es handelt sich um eine Win32-Anwendung, die UWP XAML als UI-Framework verwendet.

Das klingt einfach nach UWP mit zusätzlichen Schritten. Was auch immer dazu führt, dass ich nicht mit der rechten Maustaste auf Terminal klicken und es als ein anderer Benutzer ausführen kann, wie ich es mit jeder normalen Win32-Anwendung kann, das war eine seltsame Wahl.

Es ist weder eine UWP-App noch eine reine Store-App.
Es kommt einfach vor, dass eine der Verteilungsmethoden der Store ist, der ein UWP-Paket erfordert.
Nur diejenigen, die es über den Store installiert haben, können nicht Right click -> Run As Admin .
Deinstallieren und verwenden Sie msix oder via Scoop

Deinstallieren und verwenden Sie die msix oder via Scoop

Oder chocolatey .

@gerardog Ich habe nicht gesagt, als Administrator ausführen, sondern als anderer Benutzer ausführen.

Funktioniert Shift + Right Click nicht für Sie?

(Bitte beachten Sie, dass ich mit scoop installiert habe)

Nein. Ich habe mit dem msix-Paket installiert und diese Option ist nicht vorhanden.

Ich habe es als Chocolatey installiert und auch nicht als Admin ausgeführt

Um es klar zu sagen, das Terminal ist weder Store-only ( hier sind .msix-Dateien verfügbar ) noch eine UWP-Anwendung. Es handelt sich um eine Win32-Anwendung, die UWP XAML als UI-Framework verwendet.

Das klingt einfach nach UWP mit zusätzlichen Schritten. Was auch immer dazu führt, dass ich nicht mit der rechten Maustaste auf Terminal klicken und es als ein anderer Benutzer ausführen kann, wie ich es mit jeder normalen Win32-Anwendung kann, das war eine seltsame Wahl.

Auch hier habe ich sowohl msix als auch Store App ausprobiert. Ich habe immer noch nicht die Option "Als anderer Benutzer ausführen".

Wie wäre es damit, die Hintergrundfarbe aller erhöhten Tabs rot zu machen, damit es offensichtlich ist, dass sie erhöht sind?

Ich hätte lieber dies konfigurierbar: Hintergrundfarbe, Tab-Titel ...

https://github.com/gerardog/gsudo funktioniert gut als vorübergehende Lösung

Implementieren Sie vielleicht etwas wie wt elevated , das ein neues erhöhtes Fenster mit der aktuellen Shell mit derselben Umgebung öffnet.
EDIT: oder #3158 aber als neues Fenster und erhöht

Ich verstehe nicht, warum Sie nicht so kopieren sollten, wie Linux es tut.

Nach meinem Verständnis oder der Linux-Welt (korrigieren Sie mich, wenn ich falsch liege) müssen die Terminal-Apps (gnome-terminal, mate-terminal ...) nicht erhöht werden, selbst wenn Sie su oder sudo eingeben und den Befehl als ausführen Root-Benutzer. Die einzige Aufgabe der Terminal-App besteht darin, eine Shell in einem anderen Prozess (bash, ksh ...) auszuführen, der erhöht oder nicht erhöht ist, und die Shell-Eingabe und -Ausgabe umzuleiten, damit wir mit der Shell interagieren können.

Wenn Sie in einem Linux-Terminal "su" eingeben oder einen Befehl mit "sudo" beginnen, wird kein anderes Fenster geöffnet.

@gabsoftware Ich bin mir über die Sicherheit selbst unter Linux nicht sicher. Es ist auch unter Linux möglich, Tastenanschläge an X-Windows zu senden, und ich vermute, dass es möglich ist, Tastenanschläge an Terminal-Clients zu senden, die in einem X-Fenster ausgeführt werden, selbst wenn das laufende Terminal mit sudo oder su erhöht ist. Es kann sogar möglich sein, Tastenanschläge an erhöhte X-Fenster zu senden, aber ich weiß es wirklich nicht genau.

Um es klar zu sagen, das Terminal ist weder Store-only ( hier sind .msix-Dateien verfügbar ) noch eine UWP-Anwendung. Es handelt sich um eine Win32-Anwendung, die UWP XAML als UI-Framework verwendet.

Das klingt einfach nach UWP mit zusätzlichen Schritten. Was auch immer dazu führt, dass ich nicht mit der rechten Maustaste auf Terminal klicken und es als ein anderer Benutzer ausführen kann, wie ich es mit jeder normalen Win32-Anwendung kann, das war eine seltsame Wahl.

Auch hier habe ich sowohl msix als auch Store App ausprobiert. Ich habe immer noch nicht die Option "Als anderer Benutzer ausführen".

Ich kann nicht „Als anderer Benutzer ausführen“, indem ich mit der rechten Maustaste auf die Kachel im Startmenü klicke, aber ich kann, wenn ich mit der rechten Maustaste auf WindowsTerminal.exe klicke

@gabsoftware Ich bin mir über die Sicherheit selbst unter Linux nicht sicher. Es ist auch unter Linux möglich, Tastenanschläge an X-Windows zu senden, und ich vermute, dass es möglich ist, Tastenanschläge an Terminal-Clients zu senden, die in einem X-Fenster ausgeführt werden, selbst wenn das laufende Terminal mit sudo oder su erhöht ist. Es kann sogar möglich sein, Tastenanschläge an erhöhte X-Fenster zu senden, aber ich weiß es wirklich nicht genau.

Ich habe einige Experimente durchgeführt und bin mir jetzt ziemlich sicher, dass dies unter Linux unsicher ist. Ich bin kein Sicherheitsexperte, daher bin ich mir über die Auswirkungen nicht sicher (jemand?). Es stellt sich heraus, dass es wirklich einfach ist, Tastenanschläge an X-Windows zu senden, die gerade sudo ausgeführt haben und offen für neue sudo-Befehle sind, ohne nach einem Passwort zu fragen. Blogpost hier , Entschuldigung für den beschämenden Plug ...

Meine Schlussfolgerung wäre, dass dies nur als Option für Benutzer implementiert werden sollte, die bereit sind, das Risiko zu akzeptieren (große, fette Warnzeichen usw.), es sei denn, es gibt eine Möglichkeit, das Senden von Tastenanschlägen an Fenster mit gemischten Höhen zu verbieten.

Nebenbei bemerkt, wie sendet die Bildschirmtastatur von Windows Tastenanschläge an erhöhte Fenster?

Ich habe gsudo v0.7 veröffentlicht und ist für diesen Thread relevant:

BEARBEITEN: Für den Kontext: gsudo ist ein sudo für Windows und ermöglicht es, einen einfachen Befehl oder eine Shell in der aktuellen Konsole zu erhöhen. Wenn es von einem Cmd/Pwsh innerhalb von WT aufgerufen wird, erhöht es die Registerkarte. Außerdem können Sie Ihr Profil bearbeiten, es „Elevated Powershell“ nennen und Ihren Befehl in gsudo Powershell ändern und voilá, Sie haben ein erhöhtes Tab-Profil. Siehe hier .

Aber da gsudo oder jedes sudo für Windows die UAC-Isolation überspringt, wurde es als „unsicher“ gekennzeichnet. Was folgt, ist eine kompliziertere Problemumgehung, die es Ihnen ermöglicht, gemischte Ansichten von Registerkarten zu erstellen und gleichzeitig die Sicherheit zu wahren. /BEARBEITUNG BEENDEN

gsudo kann jetzt Anwendungen mit jeder Integritätsstufe starten. Zum Beispiel können wir Windows Terminal mit dem Integritätslevel MediumPlus starten , das bedeutet einen „semi-erhöhten“ Modus: keine Administratorrechte, aber isoliert, unerreichbar von anderen regulären Prozessen (mittlere Integrität). (ein UAC-Popup wird angezeigt)

Der erste Schritt sollte also sein, WT immer zu starten mit: gsudo -i MediumPlus WT
(Sie können Ihre WT-Verknüpfung ändern). Dies schützt WT vor bösartigen Prozessen, Screen-Scrapping, Sendkeys, DLL-Injection usw.
(BEARBEITEN: Wenn es nicht funktioniert, verwenden Sie: gsudo -n -i MediumPlus cmd /c cmd /c start wt )

Dann können Sie gsudo innerhalb von WT sicher verwenden, um Befehle zu erhöhen, oder sogar ein Profil mit erhöhten Rechten erstellen mit: "commandline": "gsudo cmd.exe" in profiles.json

Meine Schlussfolgerung wäre, dass dies nur als Option für Benutzer implementiert werden sollte, die bereit sind, das Risiko zu akzeptieren (große, fette Warnzeichen usw.), es sei denn, es gibt eine Möglichkeit, das Senden von Tastenanschlägen an Fenster mit gemischten Höhen zu verbieten.

Gemacht und gemacht. (Ich habe gsudo Sicherheitswarnungen hinzugefügt).

Da ich außerdem gelernt habe, dass, wenn der Benutzer gsudo von einem regulären/mittleren Integritätsprozess aus aufruft, der Cache für Anmeldeinformationen von gsudo (die Funktion zum Anzeigen von weniger UAC-Popups) niemals vollständig geschützt werden kann ... Also, jetzt die Anmeldeinformationen Cache muss explizit über gsudo cache on/off oder gsudo config cachemode auto aktiviert werden.

Es stellt sich heraus, dass "Changing your WT shortcut" überhaupt nicht trivial ist: Angesichts des MSIX/AppStore-Modells sind Sie auf #4217 und #4459 gestoßen.

Das folgende Powershell-Skript umgeht diese Probleme, indem es eine Windows Terminal-Verknüpfung auf dem Desktop erstellt und sie mit der Tastenkombination Strg+Alt+T verknüpft:

$shortcutPath = [Environment]::GetFolderPath("Desktop") + "\Windows Terminal Isolated.lnk"

# Use this if installed via Scoop. 
$wtPath = "$home\scoop\apps\windows-terminal\current\WindowsTerminal.exe"

# Use this if installed via Chocolatey or Ms Store
$wtPath = (Get-Command 'wt.exe').Path

$cmdPath = (Get-Command 'cmd.exe').Path
$gsudoPath = (Get-Command 'gsudo.exe').Path

$WshShell = New-Object -comObject WScript.Shell
$link = $WshShell.CreateShortcut($shortcutPath)
$link.TargetPath = $gsudoPath
$link.Arguments = "-n -i MediumPlus cmd /c cmd /c start $wtPath"

#Optional, set global Keyboard Hotkey
$link.Hotkey="Alt+Ctrl+T"

# Optional, download icon.
$icoPath = [IO.Path]::GetDirectoryName($wtPath) + "\wt.ico"
Invoke-RestMethod -Method Get -Uri "https://raw.githubusercontent.com/microsoft/terminal/master/res/terminal.ico" -OutFile $icoPath
$link.IconLocation="$icoPath,0"

$link.Save()

Sobald Sie WT als MediumPlus (dh Strg+Alt+T) gestartet haben, können Sie gsudo wie oben erwähnt (https://github.com/microsoft/terminal/issues/632#issuecomment-613751789) verwenden, um Befehle zu erhöhen in was AFAIK sicher sein sollte.

Meine Problemumgehung hierfür ist die Verwendung von Luke Samsons _Sudo für Windows_ . Profilkonfiguration ist:
"commandline": "pwsh.exe -Command sudo.ps1 pwsh.exe",
Wenn Sie eine neue Registerkarte mit diesem Profil starten, wird UAC angezeigt, und Sie landen in einem erhöhten Powershell-Kern. Funktioniert auch mit jedem anderen Endgerät.
"commandline": "powershell.exe -Command sudo.ps1 powershell.exe",
"commandline": "powershell.exe -Command sudo.ps1 cmd.exe",
Wenn Sie scoop nicht verwenden, bin ich sicher, dass das Konzept extrahiert und unabhängig verwendet werden kann. Sehen Sie sich den Quellcode hier an: https://github.com/lukesampson/psutils/blob/master/sudo.ps1

Ich verwende die schtasks-Problemumgehung, um Windows Terminal als Administrator auszuführen und UAC zu umgehen:

1. Starten Sie den Taskplaner.
2. Erstellen Sie eine neue Aufgabe. Geben Sie ihm einen Namen und aktivieren Sie das Kontrollkästchen "Mit höchsten Rechten ausführen".
   

3. Wählen Sie auf der Registerkarte Aktionen aus, um ein Programm zu starten: wt

4. Stellen Sie auf der Registerkarte „Einstellungen“ sicher, dass „Ausführen der Aufgabe bei Bedarf zulassen“ aktiviert ist, und deaktivieren Sie das Kontrollkästchen „Aufgabe beenden, wenn sie länger als ausgeführt wird“.

5. Erstellen Sie eine Verknüpfung, indem Sie mit der rechten Maustaste auf den Desktop klicken und Neu -> Verknüpfung auswählen und schtasks.exe /run /TN "{task name}"
   
6. Ändern Sie optional das Verknüpfungssymbol und ziehen Sie es in die Taskleiste.

Sieht so aus, als müsste ich bei cmder bleiben, bis dies behoben ist.

Jetzt, wo es angeblich eine Ahnung von einem Plan gibt, können wir die Dokumente bekommen
aktualisiert, um nicht mehr zu sagen, dass es keinen aktuellen Plan gibt?

https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md#starting-a-new-powershell-tab-with-admin-privilege

@drdamour Sobald es einen Plan gibt, würde ich diesen Abschnitt gerne entfernen. Im Moment gibt es jedoch nur einen Plan, um einen Weg zu finden, einen Plan zu erstellen. Sobald es einen richtigen Plan gibt und einen Weg, wie wir ihn sicher umsetzen können, werde ich diesen Abschnitt entfernen.

Die von @KMoraz beschriebene Methode funktioniert vorerst hervorragend als Workaround. Vielen Dank, dass Sie dies gepostet haben.

Hallo Leute,

Ich habe ConsoleZ verwendet, bis ich gestern dieses entdeckt habe.
ConsoleZ hat einige Funktionen und eine besteht darin, einen neuen Tab als Administrator mit UAC zu starten (es öffnet den Dialog von UAC).
Ich finde es sehr nützlich, weil Sie nicht die Hände von der Tastatur nehmen müssen, um eine neue Registerkarte mit erhöhten Rechten zu öffnen.

Was wäre, wenn es sich um eine Konfiguration innerhalb der Profilkonfiguration handeln würde? So wird es in ConsoleZ gemacht.

Hallo alle,

Ich habe eine weitere Shortcut-Problemumgehung gefunden, die einfach ist und sich hervorragend für diejenigen eignet, die lokale Administratoranmeldeinformationen eingeben müssen, wenn sie etwas als Administrator ausführen.

Dieser Link erklärt, benötigt aber einen vollständigen Pfad für die wt.exe-Referenz:
http://nuts4.net/post/windows-terminal-run-as-admin

Mein vollständiger Shortcut-String ist: C:\Windows\System32\cmd.exe /c start /b C:\Users\myUserName\AppData\Local\Microsoft\WindowsApps\wt.exe

UPDATE 21. Mai 2020:
Das obige hat vor Version 1.0.1401.0 funktioniert.

Siehe auch diese neue Ausgabe: https://github.com/microsoft/terminal/issues/6013

Jetzt funktioniert der Strg-Umschalt-Klick auch NICHT, wenn Sie mit einem lokalen Administratorkonto erhöhen müssen.

Sehen Sie sich den folgenden Fehler-Screenshot an, den ich erhalte, nachdem ich zweimal zur Erhöhung der Berechtigungen aufgefordert wurde:

Zur Information ist imho gsudo perfekt dafür, danke https://github.com/microsoft/terminal/issues/632#issuecomment -613751789

Meine Konfiguration hat nur dieses Profil, um Privilegien zu erhalten:

            {
                "name": "Admin Powershell",
                "commandline": "cmd.exe /c gsudo powershell.exe",
        "titleText": "Admin Powershell",
                "icon": "ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png"
            },

Für mich ist der einfachste Weg, Windows Terminal als Administrator zu öffnen, es als erstes Element in der Taskleiste anzuheften. Dann Win+Ctrl+Shift+1 öffnet es als Admin

Für mich ist der einfachste Weg, Windows Terminal als Administrator zu öffnen, es als erstes Element in der Taskleiste anzuheften. Dann Win+Ctrl+Shift+1 öffnet es als Admin

In der Tat sehr praktisch, aber das funktioniert nur für Konten, die Mitglieder der Gruppe Administratoren sind.

Wenn Sie als Administrator für eine andere Person fungieren, können Sie Windows Terminal nicht als Ihr (Administrator-)Benutzer von ihrem Konto aus ausführen.

Ich denke, es wäre schön, ein Tab-Setup zu haben, um cmd als Administrator auszuführen, nicht alles.

Ich denke, es wäre schön, ein Tab-Setup zu haben, um cmd als Administrator auszuführen, nicht alles.

Wie an anderer Stelle hier erläutert, ist dies mit dem aktuellen Design nicht möglich.

Gibt es ein Flag, das verwendet werden kann, um als Administrator ausgeführt zu werden? Dann könnten wir einfach eine Verknüpfung dafür erstellen.

Wenn Sie Windows Terminal an die Taskleiste anheften, können Sie es _erhöht_ mit Strg+Umschalt+Klick starten.

Dies geschieht genauso wie ein Rechtsklick auf das Symbol, ein Rechtsklick auf „Windows Terminal“, gefolgt von „Als Administrator ausführen“.

Hinweis: Da Windows Terminal eine Store-App ist, können Sie es nicht als _anderer Benutzer_ ausführen.

Ich würde gerne die Möglichkeit sehen, "Registerkarten mit gemischten Integritätsebenen" in Windows Terminal zu haben, wobei die Integritätsebene in jedem Profil als Option verfügbar ist. Dies dient hauptsächlich als Bequemlichkeit bei meiner normalen Sysadmin/Devops-Arbeit, um Arbeitsablaufunterbrechungen und Kontextwechsel zu minimieren.

Ich habe eine einfache Alternative gefunden, die für mich vorerst funktioniert. Dies betrifft nicht alle Szenarien, die hier von anderen Benutzern vorgestellt werden. Es hängt nicht von Drittanbieter-Apps, Verknüpfungsdateien, Tastenkombinationen oder geplanten Aufgaben ab. Es ist nicht erforderlich, den Speicherort der ausführbaren Windows Terminal-Datei zu identifizieren. Es wird lediglich ein separater Eintrag in der Windows Terminal-Profilliste erstellt, der eine zweite Windows Terminal-Instanz mit erhöhten Rechten startet. Dies löst einmalig eine UAC-Eingabeaufforderung aus. Ich benutze dies nur, wenn und wenn ich eine Erhöhung benötige.

Das Ergebnis sind zwei Windows-Terminals. Alles in einem ist Standard und alles in dem anderen ist erhöht. Für mich ist dies ein akzeptables Maß an Unterbrechung und Kontextwechsel. Das Windows-Terminal mit erhöhten Rechten stellt außerdem jedem Registerkartentitel „Administrator:“ voran, was eine gute visuelle Bestätigung des Unterschieds gibt.

Bearbeiten: Ich habe Powershell 7 installiert,

            "name" : "Launch Windows Terminal Elevated",
            "commandline" : "pwsh.exe -command Start-Process -Verb RunAs wt.exe"

@IarwainBen-adar, ich erinnere mich, dass ich kürzlich in den neuen Dokumenten gelesen habe, dass Sie das commandline -Element und das source -Element nicht zusammen verwenden können. Funktioniert es wie erwartet ohne das Element source ?

Ich habe seinen Code ausprobiert und kann nicht einmal den neuen Artikel im Pull erscheinen lassen
Down-Menü.

@shem-sargent tut mir leid, ich habe meinen Kommentar hier gelöscht, weil die überflüssige source -Deklaration tatsächlich das Problem war. Obwohl der Menüeintrag jetzt funktioniert, kann ich leider immer noch keine erhöhte Instanz von Windows Terminal starten – ich stoße auf Problem Nr. 3145 mit einem Fehler von The file cannot be accessed by the system.

@IarwainBen-adar Tut mir leid, ich kann #3145 nicht reproduzieren. Ansonsten würde ich versuchen, die Fehlersuche auf meiner Seite.

an Taskleiste anheften und Umschalt+Rechtsklick

Cheers @LordFPL und natürlich @gerardog , ich hatte noch nie zuvor von gsudo gehört (https://github.com/gerardog/gsudo für andere, die daran interessiert sind), aber das macht erhöhte Sitzungen jetzt zum Kinderspiel. Danke! Fügen Sie es entweder dem Profilobjekt in der Einstellungsdatei hinzu oder verwenden Sie einfach den Alias sudo , wie Sie es auf einem Linux-System tun würden. Perfekt!

@zadjii-msft Entschuldigung, aber ich verstehe nicht genau, worum es hier geht. Windows unterstützt Token-Manipulation und Identitätswechsel, so funktioniert Runas, nicht wahr? Mit gsudo von @gerardog kann ich eine niedrige (er) Integrität haben, während eine Shell mit hoher (er) Integrität gleichzeitig mit jeder anderen Integritäts-Shell gehostet wird, sei es Powershell, pwsh, cmd oder eine beliebige wsl-Shell. Nach meinen begrenzten Tests kann keine der Shells mit niedrigerer Integrität in diese Shell mit höherer Integrität debuggen. Was ist hier die Hürde, dies als eingebautes Terminal oder noch besser auf Betriebssystemebene zu haben?

@smokeintheshell https://github.com/microsoft/terminal/issues/632#issuecomment -519375707

Ein Fenster mit niedriger(er) Integrität, das Eingaben empfängt und direkt in einen Prozess mit hoher(er) Integrität leitet, öffnet diesen Prozess mit hoher(er) Integrität für die Kontrolle durch andere Dinge mit niedriger(er) Integrität im System.

Dies bedeutet, dass ein potenziell bösartiger Prozess nur eine laterale Bewegung auf derselben Berechtigungsebene benötigt, um EoP zu erlangen.

@smokeintheshell #632 (Kommentar)

Ein Fenster mit niedriger(er) Integrität, das Eingaben empfängt und direkt in einen Prozess mit hoher(er) Integrität leitet, öffnet diesen Prozess mit hoher(er) Integrität für die Kontrolle durch andere Dinge mit niedriger(er) Integrität im System.

Dies bedeutet, dass ein potenziell bösartiger Prozess nur eine laterale Bewegung auf derselben Berechtigungsebene benötigt, um EoP zu erlangen.

Ja, ich habe diese Erklärung am Anfang des Threads gelesen, aber ich verstehe nicht, warum es für Linux und wahrscheinlich Mac in Ordnung ist, aber nicht für Windows? Windows schützt derzeit Eingaben in Prozesse mit erhöhten Rechten vor Prozessen ohne erhöhte Rechte. In diesem oder einem verwandten Problem hat jemand vorgeschlagen, dass wir einen separaten Prozess pro Registerkarte benötigen. Ich würde denken, dass dies bereits der Fall ist, da jede Registerkarte einen eigenen auszuführenden Befehl hat (z. B.: pwsh.exe). Liegt es daran, dass sie alle Kinder desselben Root-Prozesses unter einem HWND sind?

Leidet das Terminal von Ubuntu unter dem gleichen Problem mit Registerkarten, wenn ich entweder:

• einen Tab mit su geöffnet haben
• eine Registerkarte haben, auf der ich bereits sudo erhöht habe und mein PW nicht erneut per Konfigurationsrichtlinie eingeben muss?

Oder ist die Architektur von Ubuntu irgendwie gegen prozessübergreifende Input-Injection-Angriffe gehärtet?

Leidet das Terminal von Ubuntu unter dem gleichen Problem mit Registerkarten, wenn ich entweder:

* have a tab with `su` open

* have a tab where I have elevated with `sudo` already and don't need to enter my PW again per configuration policy?

Oder ist die Architektur von Ubuntu irgendwie gegen prozessübergreifende Input-Injection-Angriffe gehärtet?

Wenn Sie sich meinen Kommentar hier ansehen, habe ich das Problem tatsächlich unter Linux reproduziert / ausgenutzt. Sowohl su als auch sudo sind wahrscheinlich gleichermaßen "anfällig", da Sie Tastenanschläge an Fenster mit niedrigerer Integrität senden können, auf denen diese Befehle ausgeführt werden. Das sudo-Passwort-Timeout (keine Passworteingabe beim nächsten sudo-Befehl innerhalb von 15 Minuten) macht dies noch einfacher. Sie können Ubuntu härten, indem Sie die für den Angriff notwendige X-Erweiterung deaktivieren. Ich bin mir nicht sicher, ob dies in einer Wayland-Umgebung möglich ist (der Angriff und/oder die Härtung).

Ich verstehe die Entscheidung, keine Registerkarten mit gemischter Höhe zu implementieren, vollkommen, es sei denn, es gibt eine Möglichkeit, virtuelle Tastaturen und andere Software-Eingabemethoden zu deaktivieren.

Ich würde denken, dass dies bereits der Fall ist, da jede Registerkarte einen eigenen auszuführenden Befehl hat (z. B.: pwsh.exe). Liegt es daran, dass sie alle Kinder desselben Root-Prozesses unter einem HWND sind?

@kbirger Ja, es gibt separate Prozesse für jede Registerkarte, aber alle Ihre Maus- und Tastatureingaben werden immer noch an das Fenster von Windows Terminal gesendet (das eine geringe Integrität aufweist) und dann über Standardeingabestreams an die einzelnen Shell-Prozesse weitergeleitet. So funktionieren alle Tastaturkürzel von Windows Terminal.

Ich frage mich, ob es möglich ist, zu erkennen, ob die Eingabe gefälscht ist, beispielsweise mit der GetCurrentInputMessageSource- API. Ich kann außer dem offiziellen Beispiel nicht viele Informationen über diese API finden, aber anhand der Beschreibung sollte es möglich sein, die Eingabequelle zu identifizieren (Hardware/von Prozessen mit uiAccess, meistens barrierefreie Software/von Prozessen ohne uiAccess, möglicherweise bösartig).

Warum ist es für Linux und wahrscheinlich Mac in Ordnung, aber nicht für Windows?

Ich bin mir ziemlich sicher, dass einer der drei Gründe darin besteht, dass Microsoft Sicherheit als Feature an andere große Unternehmen oder Regierungen verkauft.

Mir fallen noch ein paar andere Gründe ein, warum das bisher kein Problem war:

• Lange Zeit war Windows aus verschiedenen Gründen (z. B. weil „Hacker“ Windows nicht mögen und „jeder“ Windows verwendet ^^) das primäre (≈einzige) Ziel aller Arten von Malware. Es brauchte eine bessere Sicherheit (Schutz erhöhter Fenster), während andere sich nicht so sehr darum kümmerten.
• Wie bereits in dieser Ausgabe erläutert, sollte es für Malware nicht möglich sein, einfach auf Ihren erhöhten Konsolenhost unter Windows zuzugreifen, daher ist es wahrscheinlich, dass nicht viele in dieses Problem investiert haben (ich bin kein Sicherheitsexperte, daher weiß ich es nicht wenn einige haben)
• Malware hatte normalerweise andere Möglichkeiten, sich selbst zu erhöhen, als zu versuchen, eine Eingabeaufforderung mit erhöhten Rechten in Ihrem bevorzugten Betriebssystem zu finden
• Nur Entwickler und Systemadministratoren verwenden Terminals (dies reduziert nur die Zielgruppe des Angriffs; Regierungen und große Unternehmen sind immer noch ein Problem)

Nun, wenn Sie die Funktion naiv einführen (wie wir es alle getan hätten, da bin ich mir sicher 😄), würden Sie einen neuen (großen) Fehler in einige Windows-Installationen einführen. Da die Entwicklung offen durchgeführt wird, können Sie sicher sein, dass jeder Bedürftige sich des Fehlers bewusst ist und mit der Programmierung dagegen beginnt.
Die schnelle Gegenmaßnahme besteht darin, Windows Terminal zu verbieten (und wahrscheinlich alle anderen Terminal-Emulatoren da draußen, da der Fehler jetzt öffentlich ist), und Sie könnten sich dann von Ihren Träumen verabschieden, Windows Terminal in jeder Art von Unternehmensumgebung zu verwenden 😟

Ich hoffe aber immer noch sehr, dass eine sichere Version dieses Features das Licht der Welt erblickt 🤞

Ich verstehe. Danke für die Erläuterungen!

Nebenbei bemerkt, wie sendet die Bildschirmtastatur von Windows Tastenanschläge an erhöhte Fenster?

@mrwensveen AFAIK Es gibt drei Möglichkeiten, Eingaben an erhöhte Fenster zu senden:

1. Erhebe dich. Sie können jedoch immer noch keine Eingaben an Systemprozesse (z. B. Task-Manager, UAC-Dialog, Anmeldebildschirm) senden.
2. Registrieren Sie einen Windows-Dienst. Jetzt läuft Ihr Programm als SYSTEM, sodass Sie alles tun können, was Sie wollen. Ich habe gesehen, dass einige Remote Access-Programme dies tun.
3. Deklarieren Sie das Flag uiAccess , signieren Sie Ihre Binärdatei digital und installieren Sie sie an einem Ort, der für den aktuellen Benutzer nicht beschreibbar ist. Es ist eine „Hintertür“ für Barrierefreiheitssoftware, die es ihnen ermöglicht, andere Programme (einschließlich Systemprozesse) zu lesen/schreiben und über allen anderen Fenstern (einschließlich Secure Desktop, wo UAC-Popups und Anmeldebildschirm angezeigt werden) anzuzeigen, ohne dass sie erhöht ausgeführt werden. Siehe https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverview.

Die Bildschirmtastatur (osk.exe), Narrator.exe (und möglicherweise andere Bildschirmleseprogramme) verwenden alle Methode 3.

(Ein Screenshot, der das eingebettete Programmmanifest von osk.exe mit uiAccess=true zeigt)

Sieht so aus, als ob das uiAccess -Flag das Programm auch vor dem Zugriff durch andere Programme mit niedriger Integrität schützen kann (obwohl es immer noch ohne erhöhte Rechte ausgeführt wird). Vielleicht können wir dieses "Feature" verwenden, um WT zu schützen?

@yume-chan Cool, das ist sehr interessant, danke! Dürfen uiAccess -Programme Tastenanschläge an andere uiAccess -Programme senden? Wir wollen immer noch, dass OSK mit dem Windows-Terminal interagieren kann, und wenn dies bedeutet, dass andere Programme zumindest signiert werden sollten, bevor es Eingaben an das Windows-Terminal senden darf, ist das eine ausreichend hohe Barriere?

Dürfen uiAccess-Programme Tastenanschläge an andere uiAccess-Programme senden?

@mrwensveen Ja, Programme mit der Berechtigung uiAccess können aufeinander zugreifen.

Ich bevorzuge den GetCurrentInputMessageSource API-Weg (https://github.com/microsoft/terminal/issues/632#issuecomment-651114562), da dies nicht die beabsichtigte Verwendung uiAccess ist. Auch mit der API können wir weiterhin zulassen, dass Programme mit niedriger Integrität Tastenanschläge an nicht erhöhte Tabs senden, während sie nicht an erhöhte Tabs gesendet werden.

Kleiner Workaround, den ich hier gemacht habe:

Ich habe PowerToys installiert, das einige coole Funktionen hat. Eine davon besteht darin, die Windows-Verknüpfungen anzuzeigen, und ich habe festgestellt, dass beim Drücken von Win + Nummer die App in der Windows-Leiste geöffnet wird, die der Nummer entspricht, die in der Leiste angezeigt wird.

Also habe ich das Terminal als erstes Symbol in die Leiste eingefügt
.

Wenn ich Win + 1 drücke, öffnet sich das Terminal.

Wenn ich Win + Strg + Umschalt + 1 drücke, wird es erhöht geöffnet.

Ich werde meine Terminalkonfiguration und mein Powershell-Profil auch hier einfügen, wenn Sie die Funktionen zum Anzeigen des Git-Zweigs und der Conda-Umgebung in der Eingabeaufforderung und den Benutzer in Rot erhalten möchten, wenn es sich um ein erhöhtes Terminal handelt ...

Das gibt es mindestens seit Windows 7; es ist keine PowerToys-Sache.

@Firehawke Ja, ich habe es gerade wegen PowerToys entdeckt ... es wird nicht benötigt.

Hier ist ein Profil zum Starten von erhöhten Rechten, das im Windows Store funktioniert und ein richtiges Symbol hat:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

BEARBEITEN: Dank an @glooms , @shem-sargent, @LordFPL und @Firehawke für verschiedene Komponenten dieses Ausschnitts. Da dieser Befehl pwsh.exe aufruft, sieht es so aus, als ob einige Leute auf #4228 gestoßen sind (ein 0x80070002 Fehler beim Start) aufgrund beschädigter PATH-Umgebungsvariablen oder seltsamer Binärdateien in ihrem Pfad namens powershell.exe oder pwsh.exe . @zurkz hat dies durch Verweis powershell.exe behoben, aber ich glaube nicht, dass das jetzt zuverlässig ist. #6684 behebt dieses Problem für Windows Terminal, und Sie finden unten eine behobene Version, die dieser Lösung folgt, die dieses Problem überhaupt nicht haben sollte.

Hier ist ein Profil zum Starten von erhöhten Rechten, das im Windows Store funktioniert und ein richtiges Symbol hat:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@bb010g Das funktioniert gut! Danke.

Hier ist ein Profil zum Starten von erhöhten Rechten, das im Windows Store funktioniert und ein richtiges Symbol hat:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@bb010g ❤💯

Hier ist ein Profil zum Starten von erhöhten Rechten, das im Windows Store funktioniert und ein richtiges Symbol hat:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@anyone Verzeihen Sie meine Unwissenheit, wird dies in der Windows Store-Konfiguration gelöscht? Wenn ja, kann jemand den Pfad posten? Wenn nicht, wo soll dieser böse Junge leben?

TYIA!

@Kazamario
Es befindet sich in der Windows Terminal-Datei settings.json im Abschnitt Profile.

Es verursacht einen Fehler: 0x80070002 beim Start. pwsch 7.1.

Ich habe es geändert zu:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "powershell.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

und UAC aufgefordert, Berechtigungen zu erhöhen.

Ich habe es geändert zu:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "powershell.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

und UAC aufgefordert, Berechtigungen zu erhöhen.

das hat bei mir ganz gut funktioniert. Danke!

So starten Sie Windows Terminal mit erhöhten Rechten, wenn es an Start angeheftet wurde.
https://github.com/farag2/Utilities/blob/master/Windows%20Terminal/Pin%20to%20Start.ps1

@narfanar Es sieht so aus, als wären Sie auf #4228 gestoßen, wo Windows Terminal beim Start den Fehler 0x80070002 ausgibt, wenn die PATH-Umgebungsvariable durcheinander gebracht wird oder andere Binärdateien im Pfad mit dem Namen powershell.exe oder pwsh.exe . Ich glaube nicht, dass das Snippet von @zurkz dies wirklich behebt, da es nur potenzielle Probleme von pwsh.exe auf powershell.exe verschiebt. #6684 hat dies für WT behoben, also hier ist ein Ausschnitt, der an diese Lösung angepasst ist:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

console-z macht das gut

Beachten Sie, dass Cmder diese Funktion hat, die unglaublich nützlich ist. Würde es gerne in Windows Terminal implementiert sehen. Auch wenn es ein separates Fenster für die Admin-Tabs oder so starten muss.

Mein Standardprofil ist auf Bash und nicht auf Powershell eingestellt, und ich möchte es so beibehalten. Das obige Snippet funktioniert großartig, aber ich würde gerne ein neues erhöhtes Terminal mit geladenem Powershell-Profil starten können. Ich habe ungefähr 3 Stunden damit verbracht, das herauszufinden (kein großer Fan von / habe viel Erfahrung mit Powershell) und ich kann es nicht herausfinden - bitte helfen Sie. Es scheint, als gäbe es eine Kombination aus einfachen Anführungszeichen, doppelten Anführungszeichen, Escapezeichen, Leerzeichen, Zeilenumbrüchen, die es funktionieren lassen, aber ich kann den Startprozess und die Argumentliste nicht dazu bringen, das zu tun, was ich will. Ich habe es auf Folgendes reduziert:

Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p "Windows PowerShell"'
Dies funktioniert in einer .ps1-Datei, wenn ich es selbst ausführe, erhalte ich ein neues erhöhtes Windows-Terminal mit geladenem Powershell-Profil. aber es funktioniert nicht im Befehlszeilenparameter von settings.json, egal wie ich versuche, es zu verstümmeln, indem ich explizit argumentlist aufrufe, anstatt cmd /c zu verwenden, verschiedene Formen der Verwendung von Escapezeichen und Anführungszeichen usw.

"commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p \"Windows PowerShell\"'",
funktioniert nicht. Das Beste, was ich tun kann, ist, es dazu zu bringen, eine seltsame Mischung aus dem zu starten, was ich will. Ich bekomme ein "Administrator: Ubuntu" -Fenster geladen, das wie mein Bash-Profil aussieht, aber tatsächlich Powershell ausführt. falsche Schriftart und so. Wenn ich dieses Fenster verwende, um eine neue Powershell-Registerkarte zu öffnen, wird sie wie gewünscht erhöht. Wenn es so ist, kann ich den gewünschten Müll in den "Windows PowerShell"-Teil des Profilladens stecken und bekomme genau das gleiche Verhalten, also weiß ich, dass es nicht wirklich versucht, das Profil zu laden, das ich übergebe.

Ich habe also ein Problem beim Versuch, dies immer noch mit erhöhten Rechten auszuführen. Ich habe alle oben aufgeführten Optionen ausgeführt und erhalte entweder den Fehler „Die Datei kann nicht gefunden werden“ oder diesen.

Start-Process : This command cannot be run due to the error: The system cannot find the file specified.
At line:1 char:1
+ Start-Process -Verb RunAs shell:appsFolder\\Microsoft.WindowsTerminal ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Hat noch jemand das Problem oder hat es nicht geschafft, diese zum Laufen zu bringen?

Mein Standardprofil ist auf Bash und nicht auf Powershell eingestellt, und ich möchte es so beibehalten.

Ich auch. Ich führe die meiste Zeit WSL aus, aber hin und wieder muss ich PS erhöht ausführen, und ich möchte dies in einem Tab des neuen WT tun.

Ich konnte auch keines der Beispiele zum Laufen bringen - selbst wenn ich meine Dateipfade korrigiert habe. Ich habe gsudo gefunden und installiert, das die aktuelle Registerkarte erhöhen oder als Profil zum Öffnen einer erhöhten Registerkarte im selben Fenster verwendet werden kann. Ich bin mir nicht sicher, ob die obigen Lösungen in einem neuen Fenster gestartet wurden (einige Versuche, die ich vor der Verwendung gsudo unternommen habe, würden nur in einem neuen Fenster gestartet). Es öffnet sich ein UAC-Popup.

Dies ist das Profil, das ich verwende:

{
    // Elevated Powershell using gsudo
    // https://github.com/gerardog/gsudo
    "name": "Elevated PowerShell",
    "commandline": "powershell.exe gsudo powershell.exe -nologo",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png",
    "suppressApplicationTitle": true
}

Ich verwende supressApplicationTitle , damit der Registerkartentitel Administrator: nicht anzeigt, da er mit Elevated überflüssig ist.

@ayfine Wenn https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 tatsächlich nicht für Sie funktioniert, könnten Sie eine Transkription der genauen Fehler / des unerwarteten Verhaltens senden, die Sie mit dieser Konfiguration erhalten? (Stellen Sie sicher, dass Sie zusätzliche Konfigurationen wie suppressApplicationTitle in so kleinen Schritten wie möglich hinzufügen, damit WT einfacher zu erkennen ist, wo und wann es passiert, wenn eine Ihrer Konfigurationen bricht.)

Wenn andere Konfigurationen hier für Sie etwas weiter als die verlinkte sind, wären Details darüber, wie diese kaputt gehen, ebenfalls willkommen.

@bb010g Ich stoße auf keine Fehlermeldungen - ich entschuldige mich dafür, dass ich in meiner Antwort nicht präziser war. Bei der Verwendung von https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 bin ich auf das Problem gestoßen, dass Windows Terminal meine WSL-Ubuntu-Shell lädt (mein Standard). Ich hatte dies ursprünglich so verstanden, dass es nicht richtig funktionierte, aber ich sehe jetzt, dass in diesem neuen Fenster, wenn ich eine neue Powershell-Registerkarte (Standardprofil) starte, diese tatsächlich erhöht ist. Unabhängig davon ist es nicht einfacher, ein neues Fenster zu öffnen und darin einen neuen Tab zu starten, als einen Prozess mit erhöhten Rechten über mein Startmenü auszuführen. Was ich in meiner ursprünglichen Antwort beschrieben habe, liefert genau das Verhalten, das ich mir vorgestellt habe.

@ayfine - und ich habe dein Gsudo-Beispiel kopiert. Das ist eine ausreichend gute Lösung, bis etwas eingebautes codiert ist. Danke.

@ayfine Ich habe das Gsudo-Ding ausprobiert, aber es ist eine ziemlich schreckliche Erfahrung. Jede Art von TAB-Vervollständigung scheint zu brechen, und Unicode-Zeichen (Nicht-ASCII) scheinen nicht angezeigt zu werden. Ich vermute, es ist eine Art Prozess, der Eingabe und Ausgabe umleitet und dabei einen schrecklichen Job macht. Ich denke, die Lösung mit einem separaten Fenster funktioniert besser.

Wenn Sie Probleme mit gsudo haben, melden Sie diese bitte an @gerardog und nicht in diesem Thread. Jede Nachricht in diesem Thread (diese eingeschlossen; Entschuldigung!) E-Mails an Hunderte von Abonnenten.

Ich werde diesen Thread für weitere Nicht-Maintainer-Kommentare sperren, da wir den Punkt erreichen, an dem weitere Kommentare die Diskussion nicht wesentlich voranbringen.

Bitte reichen Sie neue Probleme ein, wenn Sie Bedenken haben, die hier nicht behandelt werden.