Powershell: Soutenir sudo<powershell cmdlet=""/>

Fredonner! Très intéressant. Mais, je pense que le comportement réel est comme prévu. Comme dans Windows, nous n'avons pas de commande comme sudo.
Mais, vous pouvez utiliser 'sudo powershell' puis faire le remove foo.txt (qui a été créé en utilisant 'sudo powershell'), puis cela fonctionne lorsque vous utilisez Remove-Item. Bien sûr, cela ne fonctionnera pas avec une autorisation non élevée.

Je n'utiliserais «sudo» que sur les commandes Linux («sudo nautilus») depuis PowerShell.

:)

Même sous Windows, il serait bon d'avoir une capacité similaire pour exécuter une applet de commande en tant qu'autre utilisateur ou avec élévation de privilèges et quelque chose sur lequel on pourrait s'appuyer dans des scripts portables. Peut avoir besoin d'une RFC pour cela.

Cette fonctionnalité serait utile pour contourner le # 3506.

Cela va devenir un bloqueur pour l'adaptation de Linux pour moi si cela n'est pas résolu. Nous ne sommes pas autorisés à sudo bash et de même, nous ne serons pas en mesure de faire sudo powershell.

Je suis d'accord avec Maximo, nous devrions laisser sudo pour bash et créer une nouvelle cmdlet pour faire l'élévation dans PowerShell en utilisant sudo comme échafaudage sur les fonctionnalités attendues.

@dantraMSFT a enquêté sur cela, Dan pouvez-vous nous fournir une mise à jour sur une réflexion actuelle à ce sujet?

@pixelrebirth Pouvez-vous fournir plus de détails sur ce que vous attendez? Attendez-vous une exécution simple avec une attente, une redirection de sortie ou une redirection de pipeline?
Un exemple d'utilisation serait également utile.

@dantraMSFT Par souci d'argument, je vais appeler le nouveau sudo comme cmdlet: Invoke-Elevated
Voici comment sudo fonctionne et se traduirait par Invoke-Elevated de manière PowerShell

$cred = Get-Credential
Invoke-Elevated -credential $cred -command {
        Get-ChildItem ./test | Remove-Item -force
} | Get-SomeCmdlet

Dans cet exemple, tout dans le scriptblock serait exécuté avec élévation, puis redirigé vers une Get-SomeCmdlet NON élevée
Cred peut être un utilisateur différent ou vous-même en tant qu'utilisateur élevé (les autorisations doivent être conservées quelque part comme le fichier sudoers le fait, c'est-à-dire une liste blanche)

La journalisation doit être activée, par défaut pour les instances où Invoke-Elevated est exécuté:
Utilisateur | Commande | Journalisation DateTime ou format similaire

Peut-être que certains de ces éléments seront étendus ou modifiés plus tard, mais c'est ce qui supprimerait mes bloqueurs

Cela devrait également fonctionner comme:

Get-ChildItem ./test | Invoke-Elevated -command {Remove-Item -force}
Où les informations d'identification sont votre utilisateur actuel et il vous demande simplement le mot de passe ...

Get-ChildItem est NON élevé, Remove-Item est élevé dans cet exemple

J'étais à l'appel de la communauté aujourd'hui pour poser des questions à ce sujet, mais ma femme a été blessée en expliquant les défis et j'en ai manqué beaucoup. Pouvez-vous s'il vous plaît mettre des notes ici pour que je puisse les transmettre à mon patron?

Je vais aider autant que possible et mettre la pression partout où j'en ai besoin.

@pixelrebirth espère qu'elle va bien! Nous mettrons en place un enregistrement de l'appel dans les prochains jours ou deux, afin que vous puissiez vous rattraper si vous le souhaitez.

Le résumé de base est que @dantraMSFT fait une enquête initiale pour déterminer comment faire cela de manière non piratée. Aujourd'hui, vous pouvez sudo powershell -c "invoke-foo" depuis un autre shell, mais ce n'est évidemment pas réalisable.

@dantraMSFT :

Cela peut sembler évident, mais jetez peut-être un coup d'œil au code source sudo et voyez comment ils le gèrent - peut-être que cela nécessite un codage de bas niveau. J'aimerais avoir une compréhension plus approfondie du code pour vous aider.

Elle va bien, elle se sent sur sa hanche de chirurgie. Merci pour la réponse rapide à ce sujet. Je travaille sur un petit travail de hack que je publierai ici si je le réussis.

@pixelrebirth Pour référence, sudo utilise le bit setuid, voir https://unix.stackexchange.com/a/80350/86669 pour plus de détails. Ce serait probablement une mauvaise idée de définir cela sur un shell entier, cependant.

Le sudo Windows natif est indispensable (donc le problème n'a probablement pas sa place ici, bien que l'option où il ne soit utilisable que via Powershell soit acceptable pour moi). J'utilise Powershell depuis le début et j'ai vu 99 variantes de script sudo, comme Invoke-Elevated ci-dessus (ou le mien que j'utilise tous les jours). Inclure une applet de commande comme celle-ci dans Powershell serait un pas en avant, cependant, ils se sentent tous encombrants par rapport à la façon dont cela fonctionne sous Linux.

Une des choses ennuyeuses pour moi est que cela démarre une nouvelle fenêtre shell (pas sous Linux) que j'aimerais voir implémentée dans Powershell / Windows, je ne sais pas si cela est techniquement possible sur Windows.

Bien que j'aime l'idée d'une autre applet de commande ("Invoke-Elevated") qui pourrait éventuellement être utilisée dans Windows, mais je ne comprends pas pourquoi ne pas m'en tenir à ouvrir PowerShell avec 'sudo' si vous devez créer un script à exécuter avec high privilège?

Surtout si vous automatisez une tâche qui sera finalement programmée pour s'exécuter avec une sorte d'informations d'identification à privilèges élevés de toute façon.
:)

Parce que ce n'est pas le flux de travail typique. Vous ne «sudo» pas et y vivez pour toujours, vous avez des commandes spécifiques à sudo et vous vivez dans un monde non sudo. Il n'y a pas de moyen rapide de le faire dans Windows et PowerShell lui-même est terriblement lent à démarrer, en particulier avec quelques éléments de profil inclus.

Dans une session typique de tous les jours, je sudo 20 fois des commandes spécifiques, d'autres fonctionnent sans privilège. C'est tout l'intérêt de sudo, n'augmenter les privilèges que lorsque cela est nécessaire et cela peut être nécessaire assez souvent.

Mon flux de travail était, exécutez la commande, il se plaint de privilèges, je sudo -L qui exécutera à nouveau la dernière commande avec privilège. Comme chic est si lent à démarrer, je lance simplement le shell d'administration et j'y vis constamment, ce n'est clairement pas une bonne idée.

Merci @majkinetor!
:)

Le sudo doit être une variante CLI de l'invite UAC. Windows, jusqu'à récemment, n'était jamais compatible avec la CLI, mais maintenant je pense que nous en avons besoin. Le moment est venu où vous pouvez faire des choses 100% Windows uniquement dans le shell - personnellement, j'utilise simplement le shell et le navigateur, presque rien d'autre.

@majkinetor : Autant que je sache, le seul moyen de lancer un processus élevé est via l'invite UAC.
FWIW: Vous pouvez accomplir cela sur Windows sans changement de PowerShell en utilisant ShellExecuteEx.
Cependant, si vous prévoyez de diffuser les résultats; c'est une histoire très différente.

Autant que je sache, le seul moyen de lancer un processus élevé est via l'invite UAC.

Des applications spécifiques peuvent être exclues de l'UAC, ce qui pourrait, je suppose, gérer l'élévation à sa manière.

Je voulais offrir ma solution / solution de contournement pour Sudo sur Windows. Tout commentaire / critique serait le bienvenu. S'il n'est pas approprié de publier ce genre de chose ici, je m'excuse à l'avance.

https://github.com/pldmgg/misc-powershell/tree/master/MyModules/Sudo

https://www.powershellgallery.com/packages/Sudo

Il existe trois fonctions dans le module Sudo:

• Nouveau-SudoSession
• Remove-SudoSession
• Démarrer-SudoSession

Start-SudoSession (alias "sudo") est pour les commandes ponctuelles que vous devez élever. Il vous demandera des informations d'identification et vous donnera une invite UAC avant d'exécuter la commande.

.EXEMPLE

$ModuleToInstall = "PackageManagement"
$LatestVersion = $(Find-Module PackageManagement).Version
# PLEASE NOTE the use of single quotes in the below $InstallModuleExpression string
$InstallModuleExpression = 'Install-Module -Name $ModuleToInstall -RequiredVersion $LatestVersion'
Start-SudoSession -Credentials $MyCreds -Expression $InstallModuleExpression

New-SudoSession si pour ouvrir une ElevatedPSSession dans laquelle des commandes élevées peuvent être injectées. L'idée est que dans un script plus long avec plusieurs opérations nécessitant une élévation, vous créez une ElevatedPSSession au début et recevez une invite UAC UNE FOIS, puis injectez ces commandes élevées en utilisant Invoke-Command dans cette ElevatedPSSession si nécessaire.

.EXEMPLE

PS C:\Users\zeroadmin> $MyElevatedSession = New-SudoSession -UserName zeroadmin -Credentials $MyCreds
PS C:\Users\zeroadmin> Get-PSSession
 Id Name            ComputerName    ComputerType    State         ConfigurationName     Availability
 -- ----            ------------    ------------    -----         -----------------     ------------
  1 ElevatedSess... localhost       RemoteMachine   Opened        Microsoft.PowerShell     Available

PS C:\Users\zeroadmin> Invoke-Command -Session $MyElevatedSession.ElevatedPSSession -Scriptblock {Install-Package Nuget.CommandLine -Source chocolatey}

Enfin, Remove-SudoSession supprime la ElevatedPSSession créée par la fonction New-SudoSession. L'idée est de placer ceci à la fin de votre script, à quel point vous recevrez une invite UAC. Donc, au total, pour exécuter un nombre quelconque d'opérations élevées dans un script particulier, vous ne recevez que deux invites UAC - une pour ouvrir une ElevatedPSSession et une pour la fermer. Utilisation de Remove-PSSession:

.EXEMPLE

$MyElevatedSession = New-SudoSession -UserName zeroadmin -Credentials $MyCreds
PS C:\Users\zeroadmin> Get-PSSession
 Id Name            ComputerName    ComputerType    State         ConfigurationName     Availability
 -- ----            ------------    ------------    -----         -----------------     ------------
  1 ElevatedSess... localhost       RemoteMachine   Opened        Microsoft.PowerShell     Available

Remove-SudoSession -Credentials $MyCreds -OriginalConfigInfo $MyElevatedSession.OriginalWSManAndRegistryStatus -SessionToRemove $MyElevatedSession.ElevatedPSSession

Sous le capot, voici ce qu'il fait à partir d'une session PowerShell non élevée (si la session est déjà élevée, elle ne fait rien):

• Vérifie que WinRM / WSMan est activé et configuré pour autoriser l'authentification CredSSP (sinon,
  des modifications de configuration sont effectuées)

• Vérifie l'objet de stratégie de groupe local ...

  Configuration ordinateur -> Modèles d'administration -> Système -> Délégation des informations d'identification -> Autoriser la délégation de nouvelles informations d'identification

  ... pour vous assurer qu'il est activé et configuré pour autoriser les connexions via WSMAN / LocalHostFQDN

• Crée une PSSession élevée à l'aide de la cmdlet New-PSSession

• Exécute l'expression passée au paramètre -Expression dans la session PSSession élevée

• Supprime la session PSSession élevée et rétablit toutes les modifications apportées (le cas échéant) à la stratégie de groupe locale et à la configuration WSMAN / WinRM.

EDIT: Mise à jour de l'exemple de faute de frappe Remove-SudoSession.

@pldmgg Je ne vois pas sous quelle licence votre code est donc nous ne pouvons même pas regarder ce que vous avez fait. Pouvez-vous ajouter un fichier LICENCE? Le MIT serait très convivial et nous permettrait d'utiliser votre code ou d'en dériver. Merci!

@pldmgg Suite à ce que @ SteveL-MSFT a mentionné, un excellent guide pour vous aider tout au long de ce processus est https://choosealicense.com/.

tl; dr - Il est difficile de se tromper avec les licences suivantes:

• Apache 2.0
• MIT

Plus de détails

Apache 2.0 a quelques atouts supplémentaires par rapport au MIT, mais dans l'ensemble, ils sont très permissifs et faciles à utiliser avec d'autres licences open source et très conviviaux. Si vous choisissez des licences copyleft (GPL), le code ne peut pas être utilisé avec d'autres outils sans que ces autres outils ne passent à une licence GPL (également appelée licence virale - LGPL étant l'exception ici, où les modules / binaires sous licence LGPL peuvent être placé à côté d'autres outils sans nécessiter de changement de licence pour l'autre code).

@pldmgg aussi, très, très cool!

@ferventcoder Merci pour la référence https://choosealicense.com! Comme vous (+ @ SteveL-MSFT) le soupçonniez probablement, je ne savais pas vraiment quelle licence choisir. J'ai mis à jour tout mon dépôt misc-powershell pour utiliser Apache 2.0, et j'ai mis à jour le Sudo.psd1 pour faire référence à Apache 2.0 (dans mon dépôt git ainsi que dans la galerie PowerShell). J'espère que cela peut être utile aux gens! Tous les conseils / critiques sont les bienvenus!

@ SteveL-MSFT Pouvez-vous l'utiliser si la licence est Apache 2.0? Si vous avez besoin que ce soit le MIT, faites le moi savoir et je mettrai à jour.

@pldmgg mon plus gros problème avec votre solution est l'utilisation de CredSSP. C'est une méthode moins sécurisée pour la gestion des informations d'identification et je pense que cela expose beaucoup de risques à la limite UAC.

Pour citer Powershell Magaize ,

"C'est une mauvaise idée d'utiliser CredSSP pour s'authentifier sur le poste de travail d'un utilisateur en utilisant un compte d'administrateur de domaine; vous donnez essentiellement les clés du royaume."

"Ne placez pas d'informations d'identification de confiance élevée sur des ordinateurs de faible confiance"

L'intérêt de l'UAC est de ne pas faire confiance aux applications de l'ordinateur. Même si je peux accepter une commande sudo qui finit par faire des ravages sur ma machine, elle n'aura généralement pas mes informations d'identification. Si la commande sudo a maintenant un accès clair à mes informations d'identification de domaine, cela pourrait faire beaucoup plus de dégâts en compromettant mon réseau.

Votre solution peut-elle fonctionner sans CredSSP? Sinon, quel problème tentiez-vous de résoudre en utilisant CredSSP? Ces informations pourraient être utiles à l'équipe PowerShell pour trouver une solution plus sécurisée.

@pldmgg Je pense qu'Apache 2.0 est suffisant. Merci!

@ dragonwolf83 C'est une préoccupation commune. En fait, j'ai avancé tout mon argument selon lequel tout va bien dans cette situation spécifique dans ce fil:

https://www.reddit.com/r/PowerShell/comments/6c778m/startsudosession_sudo_for_powershell_written_in/dhsretm/

Mais, pour résumer, je pense que ça va ici parce que:

• Il se connecte à l'hôte local (pas distant)

• Depuis Windows 8.1 / Server 2012R2, CredSSP n'envoie plus les mots de passe en texte clair

• Remote Desktop Protocol est toujours vulnérable aux attaques pass-the-hash, tout comme CredSSP, donc si cela vous inquiète pour CredSSP, vous devriez également vous en inquiéter pour RDP. (Bien sûr, il existe un mode d'administration restreint RDP ou le nouveau "Credential Guard")

PS Cet article est devenu ma référence pour PowerShell Security (et c'est là que j'ai découvert Credential Guard) .. Je le recommande vivement .

https://blogs.msdn.microsoft.com/daviddasneves/2017/05/25/powershell-security-at-enterprise-customers

Pour la version 6.0.0, je pense que nous finirons par:

Une fonction de script appelée sudo qui n'existe que sous Linux (nous reportons la prise en charge de l'élévation de Windows). Si l'argument est une applet de commande / scriptblock, alors il sera sudo powershell avec ces arguments. Cela signifie que pour l'instant, les objets de pipelining ne fonctionneront pas. Si l'argument est une commande native, nous le transmettons directement à sudo.

Après la version 6.0.0, nous aimerions finalement arriver à une expérience comme:

Get-Item foo.txt | sudo Remove-Item

et faites-le fonctionner à la fois sur Windows et Linux. cc @joeyaiello

Sur la base de la discussion de @ PowerShell / powershell-comité, cela n'est pas nécessaire pour la version 6.0.0 et la recommandation est d'investir dans une cmdlet de type Invoke-AsUser

Pour modifier l'élévation en général, vous auriez besoin de quelque chose avec setuid bit sous UNIX et ce serait sudo lui-même. sudo est un binaire spécial qui ne peut pas être facilement émulé et ne doit pas être émulé pour des raisons de sécurité. Veuillez laisser le sudo réel être utilisé pour lancer une instance temporaire de PowerShell qui exécute la commande en question. De plus, le sudo d'un shell entier est plutôt dangereux étant donné que l'on peut oublier le shell ouvert sur un serveur distant. sudo a un mécanisme pour oublier que l'utilisateur s'est élevé au bout de quelques minutes ce qui protège la machine à long terme. La résolution de ce problème permettrait à plus de personnes d'utiliser PowerShell en production sur des serveurs Linux. Dans l'état actuel des choses, PowerShell restera une nouveauté secondaire puisque la sécurité est primordiale dans la production.

@borgdylan aujourd'hui, vous pouvez faire sudo pwsh -c foo dans PowerShell Core (ou simplement sudo nativecmd ). Je pense que le désir est de pouvoir sudo une cmdlet dans une session PowerShell Core existante. Nous n'essayons pas de recréer sudo ici, mais plutôt d'avoir du sucre syntaxique pour le rendre plus facile à utiliser.

Avec # 1527 et ce problème étant repoussé de plus en plus loin dans les jalons, je commence à me demander: est-ce que tout le monde est vraiment à l'aise pour se connecter aux sessions root pour faire des tâches d'administration? Il n'existe pratiquement aucun moyen pratique d'appeler des commandes PowerShell lorsque PS est impliqué de quelque manière que ce soit.

@MathiasMagnus Je n'ai pas testé cela à fond, mais vous pouvez configurer des commandes courantes ou utilisées à plusieurs reprises pour ne pas exiger de mot de passe sur sudo. Pour tester, j'ai ajouté ceci avec visudo:

mark ALL=(ALL:ALL) NOPASSWD: /usr/bin/pwsh

J'ai ensuite pu appeler sudo pwsh -c 'cat /etc/sudoers' via une session de communication à distance PowerShell SSH. Selon la façon dont vous faites votre sécurité et ce que vous configurez exactement dans sudoers (par exemple, All=(ALL:ALL) est un peu ouvert ...) cela peut être sûr ou dangereux.

Si vous ssh sous Linux (c'est-à-dire pour bash shell au lieu de PowerShell SSH remoting), vous pouvez exécuter sudo avec une invite de mot de passe normale dans pwsh pour autant que je sache.

Ce n'est pas tant que ce soit impossible, juste que les solutions de contournement actuelles sont livrées avec des bagages.

@MathiasMagnus # 1527 est toujours ciblé pour la version 6.1.0 car il n'y a pas de bonne solution de contournement pour cela. Pour les applets de commande, le principal problème est la complication du pipelining vers / depuis une applet de commande sudo'd. Pour des opérations uniques, sudo pwsh -c est viable. Bien sûr, si quelqu'un de la communauté soumet un PR, nous serons plus qu'heureux de le prendre.

Sous Windows, c'est maintenant un problème qui, je pense, ne peut pas être résolu sans élever les connexions ssh, ce qui nécessite alors un moyen d'élever à partir de la ligne de commande.

Je sais qu'il est facile de se plaindre de choses qui ne fonctionnent pas et de ne pas agir, mais mon expertise est ailleurs. Je contribue principalement aux bibliothèques C ++ et GPGPU et à Vcpkg en faisant beaucoup de portages CMake. Je n'ai jamais écrit C # et je ne pense pas en avoir la capacité. Cependant, j'administre un petit groupe de ~ 12 machines. C'est sur le point d'être gérable à la main, mais la capacité sudo manque cruellement, c'est-à-dire si je n'ai pas l'intention de créer une connexion pour l'utilisateur root sur Ubuntu, ce qui est mal vu. DSC Core serait une solution, mais même s'il a été annoncé il y a un an, il a récemment été retardé indéfiniment.

PowerShell Core sur Linux tel qu'il est actuellement est un peu coincé entre la manière automatisée de faire les choses et le style ad-hoc qui est familier aux administrateurs système Linux. J'espère que quelqu'un trouvera le temps de participer à ce numéro.

@MathiasMagnus c'est quelque chose que tout le monde veut, mais ce n'est pas un problème simple à résoudre. Notez que l'utilisation de sudo contre des commandes natives fonctionne correctement, il n'est tout simplement pas disponible pour exécuter sudo sur les applets de commande. La solution de contournement consiste à appeler pwsh dans pwsh:

sudo pwsh -c remove-item quelque chose

La principale complication est quand il s'agit de quelque chose dans un pipeline:

get-item toto * | sudo remove-item

@ SteveL-MSFT Au moins, le concept n'est pas si complexe. S'il vous plaît, dites-moi ce que vous pensez.

Nous avons simplement besoin d'une combinaison des binaires sudo, su et login, pour gérer tous les cas.

Il doit faire:

• Créez un socket unix pour les rappels et autorisez uniquement l'utilisateur de destination à y accéder.
• Validez que l'appelant est autorisé à accéder sudo (je pense que l'on peut simplement copier le code source de su , sudo et login )
  
  
  
  • Si / etc / sudoers existe, il doit être analysé
    
    
    
    
    
    • Seulement des commandes spécifiques
    
    
    
    • En utilisant le mot de passe des utilisateurs de destination
    
    
    
    • Sans validation des informations d'identification (sans mot de passe)
    
    
    
  
  
  • Si ce n'est pas le cas, il faut appeler pem pour vérifier si l'utilisateur "connaît" directement les informations d'identification de l'utilisateur root.
  
  
  • S'il ne connaît pas non plus les informations d'identification des utilisateurs de destination, refusez l'accès et lancez une exception dans PowerShell.
  
  
• Si la validation est réussie, nous devons basculer le contexte de l'utilisateur sur root ou sur l'utilisateur de destination.
• Une fois que nous avons changé le contexte utilisateur, le nouveau processus doit établir la communication avec le PowerShell original en cours d'exécution en le connectant au socket unix.
• Si l'utilisateur entre "exit", nous signalons sur le socket unix, que nous avons terminé et que nous quittons, l'utilisateur reviendra automatiquement aux privilèges de l'appelant, donc nous n'avons besoin que du PowerShell d'hébergement pour afficher une invite ou exécuter le suivant instruction.
• Si à la place le PowerShell hôte se termine, le socket unix se ferme et le PowerShell élevé doit interrompre l'exécution et se terminer, comme si l'on ferme le terminal.

Le flux d'exécution ressemblerait à ceci:
PWSH (crée le socket /proc/self/change-user.socket) => PWSH-SU (invoqué avec le socket et l'utilisateur de destination comme paramètre; PWSH-SU est défini suid pour s'exécuter en tant que root lui-même) => PWSH en tant que l'utilisateur de destination se connecte au socket unix.

La partie la plus longue est de permettre au PowerShell de se connecter en interne via un socket unix. Il ne suffit pas de rediriger les liens d'entrée et de sortie des autres applications Unix, car nous traitons des objets et pas seulement des chaînes lors de l'appel de tubes.

Pourquoi utiliser les trois binaires?
sudo est requis pour permettre à plusieurs utilisateurs de basculer dans le contexte racine sans perdre l' auditabilité .
su est utilisé pour basculer vers n'importe quel autre utilisateur en utilisant les informations d'identification des utilisateurs de destination.
login est utilisé pour créer une toute nouvelle session de connexion.
Avoir toutes ces fonctionnalités également dans PowerShell peut être utile dans de nombreux cas, par rapport à n'en avoir qu'une.

L'utilisation de tuyaux pourrait également faire fonctionner cela sous Windows d'une manière moins surprenante et plus pratique - je déteste avoir un autre shell avec tous les scripts "sudo" + UAC en cliquant mais avec des tuyaux comme celui-ci, cela pourrait être fait dans le même shell juste comme sur linux en communiquant via pipe avec un autre interpréteur déjà exécuté en tant qu'administrateur et peut-être en implémentant de vrais trucs sudo (délai d'expiration de l'invite par exemple ou fichier sudoers avec des commandes comme alternative aux points de terminaison PowerShell personnalisés)

Je suis vraiment content de voir les réflexions à ce sujet, mais en ce qui concerne la mise en œuvre réelle, il me semble que nous prenons un peu d'avance sur nous-mêmes. La première chose est que le système a besoin d'un moyen de créer un processus élevé, un thread, quel qu'il soit à partir d'un processus non lié. Aucun des problèmes de cmdlet ne peut vraiment être résolu si nous ne pouvons pas créer une instance élevée de PowerShell pour commencer, sans passer par UAC. OMI, le premier scénario à aborder ici devrait être - vous avez une session SSH limitée - comment exécutez-vous un exe régulier avec des autorisations d'administrateur?

J'ai commencé à expérimenter avec cela ici (actuellement cassé car je l'ai refactorisé, mais le concept fonctionne), mais je ne pense pas qu'une application tierce soit la vraie solution. J'aimerais voir Windows livrer d'abord un exe «sudo». Cela pourrait être aussi simple que d'activer runas pour créer un processus élevé avec une invite d'informations d'identification, mais sans la première étape, tout cela est théorique.

Aucun des problèmes de cmdlet ne peut vraiment être résolu si nous ne pouvons pas créer une instance élevée de PowerShell pour commencer, sans passer par UAC

Une possibilité pour cela consiste à utiliser une tâche planifiée avec l'option «exécuter avec le privilège le plus élevé».

Ouais, mais pour créer cela, vous devez déjà avoir des autorisations d'administrateur, n'est-ce pas? C'est ce que fait psexec. Autant que je sache, pour le moment, vous devez à un moment donné passer par l'UAC. J'aimerais voir ce changement, et avec toutes les sessions SSH augmentées, c'est en quelque sorte un problème de sécurité. Si un logiciel sommaire tente de SSH dans ma machine Windows, par exemple à partir d'un autre ordinateur sur lequel j'ai une clé privée configurée (ou le scénario de bouclage), il peut faire tout ce qu'il veut.

@parkovski Ma solution était Linux / MacOS et tous les autres SE * NIX uniquement. Windows ne prend pas en charge SUID et GUID.
Comme sudo n'existe actuellement pas non plus sur Windows, il est hors de portée de ce problème pour moi.

Et pour résoudre le problème UAC, Windows devrait implémenter SUID et GUID à l'avenir. Tout le reste n'est qu'une sale solution de contournement pour un problème de longue date ...

Ouais, mais pour créer cela, vous devez déjà avoir des autorisations d'administrateur, n'est-ce pas?

Oui, mais cela ne déclenche pas la fenêtre contextuelle UAC.

UAC peut également être ignoré de la manière officielle avec la boîte à outils de compatibilité des applications de Microsoft.

Windows ne prend pas en charge SUID et GUID.

Windows n'a pas à le prendre en charge et le concept n'est pas valide sur ce système d'exploitation.
Son modèle d'autorisation est basé sur les ACL et il n'y a pas de propriété de groupe unique.

Il n'est pas nécessaire non plus qu'il s'agisse d'une réplique sudo complète sur Windows, mais d'un moyen plus convivial d'appeler des commandes d'administration.

Je pense que c'est bien de différer la prise en charge de Windows car les utilisateurs de Windows sont probablement habitués à ouvrir une session PowerShell élevée aujourd'hui, tandis que les utilisateurs de Linux s'attendent à s'exécuter en tant que non-root et sudo si nécessaire. Nous voulons simplement nous assurer que toute conception n'empêche pas la prise en charge future de Windows. Je me concentrerais probablement aussi sur l'activation de sudo pour root plutôt que sur tout utilisateur arbitraire pour le simplifier et je pense que cela représente plus de 90% de l'utilisation.

@ SteveL-MSFT

se concentrerait probablement également sur l'activation de sudo pour root plutôt que sur n'importe quel utilisateur arbitraire

Je pense que cela ne fera pas une grande différence, mais fournira l'expérience su / sudo complète pour le résumé que j'ai décrit ci -

Je pense que c'est bien de différer la prise en charge de Windows car les utilisateurs de Windows sont probablement habitués à ouvrir une session PowerShell élevée aujourd'hui

La majorité des personnes avec lesquelles j'ai travaillé désactivent simplement l'UAC si elles le peuvent.

Malheureusement, ce n'est pas vraiment une option dans de nombreux environnements, et je doute fort que MS va abandonner complètement l'UAC. 😕

Ce problème ne concerne pas l'UAC. Mais de mon point de vue, il devrait être complètement abandonné et soit être remplacé par une philosophie stricte de deux comptes un administrateur un utilisateur (et l'administrateur ne peut pas être utilisé pour la connexion) (l'installation par défaut vous oblige à les créer) ou pour le même concept * NIX a, vous commencez en tant qu'utilisateur et augmentez au besoin en utilisant sudo et SUID / SGID-Flags.

J'ai récemment ajouté ce qui suit à mon $profile . Je l'ai couvert plus en détail sur https://stackoverflow.com/a/56265080/118098

function Invoke-MySudo { & /usr/bin/env sudo pwsh -command "& $args" }
set-alias sudo invoke-mysudo

Au moins à première vue, cela fonctionne pour moi, et permet "sudo". Cela ne couvre pas le cas de" capable de sudo une cmdlet dans une session PowerShell Core existante "par https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -354853084

Cependant, je me demande à quel point il est important de donner au contexte élevé toute la session de la commande appelante. Dans d'autres shells, sudo exécute toujours la commande fournie dans un nouveau contexte.

J'ai implémenté un sudo de base qui fonctionne bien pour exécuter des commandes en tant qu'administrateur sur Windows. Je ne sais pas si cela fonctionnerait également sous linux / mac, car je ne sais pas si "RunAs" s'élève correctement ou non sur ces plates-formes.

Modifier votre profil:

PS > notepad $PROFILE

Ajoutez la fonction sudo suivante:

function sudo {
    Start-Process -Verb RunAs -FilePath "pwsh" -ArgumentList (@("-NoExit", "-Command") + $args)
}

Puis invoquez dans votre shell. Prend en charge les applets de commande, les exécutables, tout ce qui pourrait normalement être tapé dans une invite PS:

PS > sudo Remove-Item .\test.txt  # Remove a file
PS > sudo Copy-Item .\test.txt C:\  # Copy a file
PS > sudo net start w3svc  # Start IIS

Si vous souhaitez transmettre une variable ou une expression qui sera évaluée au moment de l'exécution, plutôt que pré-évaluée, placez-la entre accolades. Par exemple:

PS > $myvar = "a"
PS > sudo echo $myvar  # $myvar is pre-evaluated, so the command reads: sudo echo "a"
PS > sudo { $PSVersionTable }  # with braces, $PSVersionTable is not evaluated until it is run as administrator

Supprimez "-NoExit" de la fonction sudo si vous préférez que la fenêtre de l'administrateur se ferme une fois terminé.

@vsalvino Ceci est une solution de contournement utile lorsque l'interface graphique est disponible et est utile en attendant, mais ce n'est toujours pas un vrai sudo car cela ne fonctionne pas sans accès à l'interface graphique. Dans un shell distant (ssh), le seul moyen de faire ce travail est un service et un client comme j'ai essayé de le démontrer ici .

Pour répondre à quelques suggestions courantes, car croyez-moi, j'ai examiné toutes les possibilités:

• La désactivation de l'UAC n'est pas une solution. C'est une solution de contournement qui peut être faite comme un choix personnel, mais ce n'est pas une solution générale à ce problème.
• Tout ce qui apparaît UAC (chaque script "sudo" que j'ai vu) n'est pas une solution, y compris le faire une fois pour démarrer une session à distance élevée.
• Tout ce qui nécessite une interface graphique _à tous_ n'est pas une solution. Supposons que nous utilisons ssh ici et que l'interface graphique n'est pas disponible.
• Tout ce qui nécessite des modifications majeures de Windows n'est pas une solution. Nous ne pouvons pas espérer que l'UAC se transforme en quelque chose de mieux.
• Même un binaire signé de Microsoft n'est pas une solution, car il ne fonctionnera pas lorsque l'UAC est réglé sur élevé (je me suis trompé sur le fichier readme de wsudo; je le corrigerai plus tard).
• La seule vraie solution à sudo sur Windows est un service qui élève les processus utilisateur en cas d'authentification réussie. J'aimerais entendre d'autres idées, mais faites d'abord vos recherches.

En gros, quelqu'un va devoir faire beaucoup de travail, pas moyen de le contourner. Ce que nous voulons, c'est quelque chose qui, une fois que PowerShell prend en charge cela sous Unix, est une goutte de remplacement sous Windows et fonctionne comme vous vous attendez à ce que sudo fonctionne (pas d'interface graphique, pas d'UAC).

Pouvons-nous d'abord clarifier la portée de cette question? Je pense que plusieurs personnes parlent de sujets différents en ce moment.
Ce problème est-il:
a) À propos de l'implémentation de sudo dans PowerShell pour les systèmes Linux / Mac?
b) Implémenter une réplique sudo dans Windows?
c) Autoriser à élever les privilèges lors de psremoting?
d) Autoriser à se faire passer pour d'autres utilisateurs sur Windows?
e) Permettre de passer d'un compte utilisateur non privilégié à un compte utilisateur privilégié?
f) quelque chose de complètement différent?

Pour a) https://github.com/PowerShell/PowerShell/issues/3232#issuecomment-444849067
Pour b) Identique à a (Windows a également des sockets unix), mais au lieu d'un binaire suid, il doit être généré par un service (s'exécutant au sein d'un utilisateur qui a le privilège "agir en tant que partie du système d'exploitation", par exemple le système utilisateur) et ce service doit également vérifier les privilèges. Ou implémentez le concept SUID / GUID sur Windows.
Pour c) non requis, vous disposez déjà des privilèges les plus élevés lors de la communication à distance. Il n'y a pas de séparation des privilèges lors de l'accès aux hôtes distants (il y a également déjà eu des contournements UAC de bouclage localhost qui fonctionnaient de cette façon).
Pour d) L'approche de a / b peut également être adoptée, mais je ne sais pas comment cela devrait fonctionner lorsque vous essayez d'accéder aux ressources du réseau, sans connaître les informations d'identification des utilisateurs ou créer un nouveau backend d'authentification Windows / ActiveDirectory.
Pour e) Identique à b, mais la vérification des informations d'identification est également requise, sinon l'API runas pourrait être assouplie pour permettre à un utilisateur connaissant le nom d'utilisateur et le mot de passe d'obtenir un nouveau jeton d'utilisateur et de garder le contrôle sur ce processus. (Peu probable compte tenu des concepts et considérations de sécurité UAC, nous revenons donc à b).

IMO, ce problème doit concerner l'implémentation de sudo dans PowerShell où la fonctionnalité sous-jacente existe déjà. La discussion sur un équivalent sudo pour Windows est probablement plus appropriée dans ce problème de terminal .

La discussion sur un équivalent sudo pour Windows est probablement plus appropriée dans ce problème de terminal.

Pourquoi l'application de terminal serait-elle un meilleur endroit pour discuter de sudo, étant donné qu'il s'agit seulement d'une autre interface vers le monde CLI? Par la même logique, vous pouvez déposer un ticket dans le référentiel ConEmu.

IMO, ce problème doit concerner l'implémentation de sudo dans PowerShell où la fonctionnalité sous-jacente existe déjà.

L'un des points du prochain Powershell est la réduction des problèmes de compatibilité entre les systèmes qui l'utilisent. À ce propos, faire quelque chose uniquement sur le système X n'est pas acceptable pour l'OMI.

En tant qu'utilisateur CLI, je m'en fiche si sudo est un sudo Linux complet utilisant le fichier suders ou certaines fenêtres. Sudo n'est qu'une interface vers les fonctionnalités d'élévation du système d'exploitation. Une telle interface pourrait être conçue pour fonctionner de manière presque identique quel que soit le «backend».

Sinon, @parkovski pointe sur l'interface graphique - je voudrais simplement ajouter Windows Core parmi les raisons.

Pourquoi l'application de terminal serait-elle un meilleur endroit pour discuter de sudo, étant donné qu'il s'agit seulement d'une autre interface vers le monde CLI? Par la même logique, vous pouvez déposer un ticket dans le référentiel ConEmu.

Parce que ce dépôt n'est pas simplement "une application de terminal"; l'équipe qui l'exécute possède essentiellement les parties en mode texte de Windows et a déjà déclaré qu'elle était intéressée par l'implémentation de sudo quand elle en trouverait le temps. En revanche, personne de l'équipe PowerShell ni de ConEmu n'a proposé.

La raison pour laquelle je pense que Windows sudo est hors de portée ici est que nous avons déjà déterminé que le faire correctement est une somme de travail assez importante et est orthogonal à PowerShell lui-même. PowerShell peut l'utiliser quand il existe, mais c'est vraiment un composant indépendant d'un shell particulier.

D'un autre côté, PowerShell peut exécuter des applets de commande via un binaire sudo, quelle que soit la plate-forme ou le fonctionnement réel de ce binaire, est totalement une chose qui doit faire partie de PowerShell, qui appartient ici.

En tant qu'utilisateur de la CLI, je m'en fiche si sudo est un sudo linux complet utilisant un fichier suders ou certaines fenêtres. Sudo n'est qu'une interface vers les fonctionnalités d'élévation du système d'exploitation. Une telle interface pourrait être conçue pour fonctionner de manière presque identique quel que soit le «backend».

Oui, il devrait absolument. C'est juste que sudo n'existe pas encore sous Windows, cela demandera beaucoup de travail et ne sera probablement pas écrit par l'équipe PowerShell. Lorsqu'une telle chose existe, espérons que PowerShell l'implémentera de manière à ce que cela fonctionne également sous Windows.

Quoi qu'il en soit, je vais reporter les autres commentaires jusqu'à ce que nous obtenions une réponse officielle ici car ce problème va dans toutes sortes de directions différentes.

Un avis à ce sujet?
http://blog.lukesampson.com/sudo-for-windows
Installé avec scoop install sudo , c'est le plus proche auquel je puisse penser. Cela fonctionne comme unix sudo - exécutez des commandes avec élévation. Je l'utilise avec pip ou Install-Module pour tous les utilisateurs.

Luke Sampson - Sudo pour Windows

Sudo pour Windows

@ Restia666Ashdoll S'il est renommé en Invoke-ElevatedCommand ça me va.
C'est parce que sudo n'est pas seulement responsable de l'élévation des commandes, mais aussi de l'usurpation de l'identité des utilisateurs et de la "suppression" ( sudo -u nobody command ) des privilèges. La réutilisation de noms déjà existants s'est également avérée être une mauvaise idée, surtout si les fonctionnalités et les paramètres diffèrent.
J'ai déjà décrit ci-dessus à quoi ressemblerait un vrai sudo avec usurpation d'identité et comment cela pourrait fonctionner.

@ Restia666Ashdoll Veuillez lire ce commentaire dans ce fil.

@parkovski C'est juste un wrapper pour -Verb RunAs, qui ne fonctionne qu'avec quelques commandes. Celui que j'ai lié peut être utilisé presque avec tout. Par exemple, je l'utilise comme ceci - sudo pip install httpie .

Vous n'avez pas lu mon message, n'est-ce pas?

Je suppose qu'il n'y a aucun moyen de modifier le titre pour inclure quelque chose comme "PAS UN SUDO SUR WINDOWS DISCUSSION"? Je sais que je ne suis personnellement pas obligé de continuer à répondre à cela, mais les gens continuent à dire la même chose sans faire leurs recherches.

J'ai essayé de cliquer sur le lien de désabonnement de ce gars et cela ne me permettra malheureusement pas de le faire sans être connecté en tant que lui.

J'ai déjà signalé @troymoore à GitHub

Je voudrais proposer une solution unique et différente dont je n'ai pas vu parler ici. Qu'en est-il d'utiliser quelque chose comme des tubes nommés pour sérialiser les commandes vers un processus élevé qui retourne ensuite sa sortie sérialisée au processus appelant?

Voici un module fonctionnel qui montre comment cela fonctionnerait sur NT: https://github.com/mmillar-bolis/Invoke-AsAdmin

Ce n'est pas parfait, bien sûr, mais cela permet d'élever des tâches simples et des piplines sans ouvrir une autre console. Je n'ai pas l'intention de présenter cela comme un sudo en soi car je ne pense pas que le clonage de la conception de sudo soit la meilleure solution à long terme, mais j'ai pensé qu'une approche différente de ce problème d'élévation nébuleux pourrait approfondir la discussion constructive.

EDIT: Je dois également mentionner que cela n'accomplira pas la demande de @parkovski pour l'élévation sans UAC.

Cela ressemble à JEA.
En ce qui concerne la sérialisation, tous les modules ne le prennent pas en charge.

Cela ressemble à JEA.

Oui, c'est l'idée.

En ce qui concerne la sérialisation, tous les modules ne le prennent pas en charge.

Comme vous l'avez probablement vu dans le code, cela est atténué par des flux de texte qui reconstruisent le code à l'autre extrémité du tube. J'admets que c'est lent, mais néanmoins une nouvelle solution de contournement. Votre mention de JEA a de nouveau été un facteur influent ici; si une partie de son code n'a pas besoin d'être élevée, elle ne devrait pas l'être.

Le module est destiné à résoudre un problème très spécifique d'élévation des commandes interactives dans les sessions GUI sur NT et rien de plus. La chose a commencé il y a cinq ans avant que quiconque n'imagine que le SSH natif pourrait être une chose pour NT. Je suis d'accord avec @parkovski qu'il s'agit d'un problème lié à la façon dont NT gère l'élévation, donc sans un service écoutant et fournissant une forme profilée d'élévation de commande, il est plutôt difficile de parvenir à un cas d'utilisation simple similaire à sudo, pkexec ou doas.

Pourtant, au lieu d'être stoppé par une erreur nirvana selon laquelle une implémentation de type sudo doit exister sur NT avant que PowerShell puisse prendre en charge toute forme d'élévation de commande, pourquoi ne poussons-nous pas d'abord pour une forme d'élévation interactive JEA dans la session shell?

Cela favoriserait au moins une meilleure pratique de sécurité dans le monde NT. Pourquoi ne pas implémenter à la fois une applet de commande pour s'exécuter de manière interactive et une pour démarrer une session de console distincte? Ou mieux encore, il suffit de promouvoir les moyens actuels de démarrer une session élevée avec un ensemble plus spartiate de cmdlets avec différents cas d'utilisation? C'est au moins un pas en avant.

Je pourrais également ajouter que même la bibliothèque Python elevate ne peut pas faire ce que fait ce module. Avez-vous déjà trouvé un autre module avec lequel il ne fonctionne pas? Parce que mon point principal est que peut-être des esprits plus intelligents que le mien peuvent prendre ce module et ses idées et fonctionner avec lui dans une direction qui conviendra à NT. Après cela, nous pouvons avoir les débuts d'une plate-forme pour NT et * nix à se rencontrer au milieu, nous permettant de réviser une implémentation plus courante pour PowerShell pour élever les commandes.

C'est au moins mes deux cents. Mais après avoir vu le code, si l'on sent que les idées qu'il contient ne sont pas bonnes, je comprendrai. Je n'avais encore vu personne essayer quelque chose comme ça.

Je vais prendre du recul par rapport à mes doléances frustrées d'expliquer le point de sudo pendant une minute parce que (a) oui c'est un problème très difficile, (b) ne peut vraiment être résolu correctement que par MS (merci de ne pas être open source, Windows), (c) c'est vraiment cool de voir que d'autres sont passionnés par cela aussi.

Je sais combien il est difficile de faire cela correctement parce que j'ai commencé dans cette voie. Donc, si la seule chose qui nous empêche pour le moment est un dialogue UAC, qu'il en soit ainsi. Au moins de cette façon, nous pouvons tester une solution multiplateforme avec un effort mineur.

Ce que j'aimerais personnellement voir de PowerShell est un support complet pour le sudo Unix, mais conçu pour prendre en charge une certaine forme de script "pseudo-sudo" tel qu'il est maintenant ainsi qu'un futur sudo réel potentiel pour Windows. Je pense que si quelqu'un fait un prototype sur la façon dont un sudo Windows fonctionnera finalement mais laisse la restriction UAC, cela devrait être assez simple, nous donner quelque chose qui est fondamentalement aussi bon que pour le moment, et quand nous obtenons la vraie chose, cela devrait être joli être juste un remplacement instantané.

Évidemment, cela signifie que quelqu'un va devoir trouver un modèle qui comprend ou du moins se traduit à la fois par le modèle uid / gid d'Unix et le modèle sid / acl de Windows. Espérons que cette personne aime les défis. Deviner cela nécessitera également des discussions avec les équipes de sécurité du terminal et des fenêtres au sein de MS.

Je suppose qu'avec autant de personnes ayant créé leurs propres solutions de contournement au mieux, et que soutenir quelque chose comme celui-ci pourrait bien aider à concevoir une manière robuste de le faire, pourquoi pas?

Sidenote - quiconque écrit ces scripts de contournement peut considérer la fonction de délai d'expiration de sudo, aussi ennuyeuse que soit cette fenêtre contextuelle.

On pourrait penser à Start-Process pwsh -NoNewWindow -Credential $cred . Cela ne fonctionne pas mais pourrait.

Évidemment, cela signifie que quelqu'un va devoir trouver un modèle qui comprend ou du moins se traduit à la fois par le modèle uid / gid d'Unix et le modèle sid / acl de Windows. Espérons que cette personne aime les défis. Deviner cela nécessitera également des discussions avec les équipes de sécurité du terminal et des fenêtres au sein de MS.

Unix a également des acls et windows a une compatibilité posix et au moins s'il s'agit d'un joint de domaine, il y a aussi un attribut de groupe principal que nous pourrions utiliser (ainsi que des attributs posix). Il aurait juste besoin d'être implémenté pour les clients Windows User ).

Le modèle générique pour les permissions Unix et Windows est donc fondamentalement:
ACL avec un utilisateur propriétaire et un groupe propriétaire avec certains ACE attendus (utilisateur, groupe et autres).

Ensuite, nous pourrions mapper les autorisations unix comme suit:
uid => SID du propriétaire
gid => Le SID du groupe principal de l'utilisateur qui a créé l'objet.
user => ID de propriétaire du créateur S-1-3-0
group => ID du groupe de créateurs S-1-3-1
autre => Monde / Tout le monde S-1-1-0
Le mappage des uids de la liste acl sous unix est un peu plus compliqué car nous devons considérer que le système peut faire partie d'un ldap, d'un annuaire actif ou de tout autre annuaire. Les deux seuls cas que je considérerais dans la portée de PowerShell sont l'absence de répertoire et LDAP / Active Directory.
Dans le premier cas, je suggérerais d'utiliser S-1-6-1-uid et S-1-6-2-gid (en supposant que S-1-6 est toujours disponible et que l'équipe responsable est prête à l'allouer à cette fin ).
Et pour le deuxième cas, nous avons juste besoin d'une sorte de résolution de l'uid via le backend d'authentification. Le serveur LDAP / Active Directory est le seul responsable de fournir un sid.
Et enfin, il y a quelques cas particuliers à cartographier:
uid 0 => S-1-5-32-544
gid 0 => S-1-6-500 (et S-1-5-21 - * - 500)
la plupart des autres sids bien connus peuvent être gérés via un fichier de configuration ou via une API quelconque (ou simplement les supprimer car ils ne sont probablement pas utilisés de toute façon)

Si nous faisons cela dans le shell, les commandes intégrées comme Get-Acl / Set-Acl commenceraient à fonctionner sur les systèmes Unix sans savoir comment les autorisations sont stockées sur le disque.

@ mmillar-bolis J'ai déjà suggéré une approche utilisant des sockets ici: https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

Nous pourrions penser à Start-Process pwsh -NoNewWindow -Credential $ cred. Cela ne fonctionne pas mais pourrait.

Mise à jour: .Net Core (et je suppose que l'API Windows aussi) ne permet pas d'exécuter un nouveau processus attaché à la même console.

Nous pouvons donc utiliser uniquement un service Windows amélioré. Mais nous devons créer un tel processus de service par "sudo" pour être sécurisé.
La solution sera donc New-PSSession (ou invoquer dans PSSession) vers localhost avec des informations d'identification utilisateur élevées.

@iSazonov L'une des seules choses qui vous permettrait de l'attacher à la même console est ce que j'ai déjà mentionné ici: https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

Maintenant que Windows prend en charge les sockets unix, nous pourrions les utiliser ou les tubes nommés et le service privilégié serait responsable de la validation des informations d'identification et devrait fonctionner à tout moment (par rapport à être appelé via suid comme mentionné dans la publication liée pour * nix oses) .

Peut-être que lsas aurait / pourrait devoir être étendu pour fournir de telles capacités d'authentification API?
De cette façon, nous pourrions obtenir une usurpation d'identité complète tout en étant en mesure de nous attacher en toute sécurité à la même console et d'accepter les entrées.

@ agowa338 Votre proposition "de facto" est la communication à distance PowerShell. Il est déjà implémenté.

Mais

La solution sera donc New-PSSession (ou invoquer dans PSSession) vers localhost avec des informations d'identification utilisateur élevées.

ne fonctionne pas pour localhost. Il lance uniquement AccessDenied.

Sauf que l'un d'entre eux est le cas:

• UAC est désactivé
• vous essayez de vous connecter à BUILDIN \ Administrator sans que le mode d'approbation administrateur soit activé.
• le processus (powershell) est déjà élevé.

Voici une bonne explication pourquoi c'est par @ jborean93 : https://github.com/PowerShell/Win32-OpenSSH/issues/1308#issuecomment -448430464

Par conséquent, nous avons besoin d'un service privilégié agissant en tant que courtier ou l'une des API doit changer, mais ce n'est pas quelque chose que nous pourrions faire dans PowerShell / PowerShell et qui devrait être délégué par le personnel de Microsoft en interne.

@ agowa338 Le commentaire que vous avez référencé concerne l'API Windows locale, et non la communication à distance PowerShell qui était une question.

@iSazonov : Avez-vous même essayé de faire une communication à distance PowerShell vers localhost? Je l'ai fait et cela ne fonctionne pas pour les raisons exposées ci-dessus. L'affectation du jeton d'accès est bloquée par le système d'exploitation.

La communication à distance PowerShell vers localhost ne permet pas d'obtenir des privilèges

Cependant, la communication à distance PowerShell vous accorde des privilèges élevés sur tous les autres hôtes du réseau, à l' exception de l' hôte local (en supposant que vous soyez membre de Domain-Admins, etc.).

C'est la raison pour laquelle nous avons besoin d'un équivalent sudo sur Windows. Si la communication à distance PowerShell se comportait de cette façon, vous pensez que ce ticket pourrait être fermé en écrivant un exemple dans la documentation, car la fonctionnalité existe déjà.

@ agowa338 Cela ne fonctionne pas pour vous en raison de la protection de sécurité. Ce n'est pas une fonctionnalité du système d'exploitation. Vous pouvez configurer WinRM comme décrit dans la documentation https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting . Le problème auquel vous avez fait référence indique également que cela fonctionne pour SSH (les étapes sont référencées dans cet article).

car la fonctionnalité existe déjà.

La demande est de faire fonctionner "sudo Remove-Item foo.txt où foo.txt appartient à root".
Ça ne marche pas mais on voudrait.
Le problème se compose de deux parties: le sucre de syntaxe dans le langage et l'implémentation.

Si vous réfléchissez davantage à votre proposition, vous découvrez que vous devez avoir un contexte PowerShell par utilisateur / par session / par espace d'exécution / par étendue. Ensuite, vous devez répondre aux exigences de conformité de sécurité et vous obtiendrez un «accès refusé» dans la configuration par défaut. Après cela, votre proposition sera la même que la communication à distance PowerShell déjà implémentée.

about_Remote_Troubleshooting - PowerShell

Cela ne fonctionne pas pour vous en raison de la protection de la sécurité. Ce n'est pas une fonctionnalité du système d'exploitation. Vous pouvez configurer WinRM comme décrit dans la documentation

@iSazonov Pouvez-vous nous en dire un peu plus? Je peux à distance de cette machine et de n'importe quelle machine vers n'importe quelle autre machine du réseau, mais d'aucune d'entre elles vers localhost. Et oui j'ai lu cette page.

La demande est de faire fonctionner "sudo Remove-Item foo.txt où foo.txt appartient à root".

Pour les systèmes non Windows, nous pourrions utiliser l'approche de socket unix pour implémenter l'emprunt d'identité / l'élévation pour PowerShell à distance.

Pouvez-vous nous en dire un peu plus? Je peux à distance de cette machine et de n'importe quelle machine vers n'importe quelle autre machine du réseau, mais d'aucune d'entre elles vers localhost. Et oui j'ai lu cette page.

La plupart des attaques visent une élévation locale. Donc, toutes les configurations sont "sécurisées par défaut". WMI, WinRM, bouclage IIS, etc. - tous les sous-systèmes désactivent les fonctionnalités qui autorisent les élévations locales.
Ce n'est pas si important pour la discussion. Même si la communication à distance PowerShell ne nous permet pas de faire sudo par défaut, nous pourrions l'implémenter désactivée par défaut ou autoriser uniquement une session interactive.

Vous avez commencé à parler de Windows, pour les systèmes non Windows, nous pourrions utiliser l'approche socket Unix pour implémenter l'emprunt d'identité / l'élévation pour la communication à distance PowerShell.

Nous devrions avoir le même UX pour toutes les plateformes. En réalité, PSRP fonctionne sur un transport - WinRM ou SSH. MSFT a déclaré aimer SSH mais je ne vois aucun progrès notable au cours des deux dernières années. Et c'est incroyable qu'ils veuillent un troisième protocole dans un futur proche - trop de travail (la nécessité de maintenir la compatibilité avec les anciens systèmes).

La plupart des attaques visent une élévation locale. Donc, toutes les configurations sont "sécurisées par défaut". WMI, WinRM, bouclage IIS, etc. - tous les sous-systèmes désactivent les fonctionnalités qui autorisent les élévations locales.
Ce n'est pas si important pour la discussion. Même si la communication à distance PowerShell ne nous permet pas de faire sudo par défaut, nous pourrions l'implémenter désactivée par défaut ou autoriser uniquement une session interactive.

J'ai essayé d'activer cela il y a quelque temps, et beaucoup d'autres m'ont dit à plusieurs reprises que cela est limité par le système d'exploitation en interne et que ce n'est en aucun cas possible sans une application qui s'intègre profondément aux internes de Windows. En fait, beaucoup ont souligné les restrictions de l'API Windows référencées ci-dessus et les ont utilisées comme argument pour expliquer pourquoi PowerShell ne pourrait jamais fournir une telle capacité. Et quelqu'un a même référencé un CVE où l'élévation du bouclage a été intentionnellement supprimée. Par conséquent, excusez-vous d'aller un peu plus loin dans ce terrier de lapin, mais que dois-je configurer pour que cela fonctionne? Est-ce même documenté quelque part?

Nous devrions avoir le même UX pour toutes les plateformes. En réalité, PSRP fonctionne sur un transport - WinRM ou SSH. MSFT a déclaré aimer SSH mais je ne vois aucun progrès notable au cours des deux dernières années. Et c'est incroyable qu'ils veuillent un troisième protocole dans un proche avenir - trop de travail (le besoin de maintenir la compatibilité avec les anciens systèmes).

Eh bien, nous devrions faire avancer l'une ou l'autre des deux solutions, car les deux fonctionnent sur n'importe quelle plate-forme.

• PSRP: SSHing to localhost fonctionne pour l'élévation sous Windows et Linux, donc en utilisant le sous-système psrp, nous avons déjà les autorisations appropriées, donc seule la couche PowerShell doit être uniformisée pour permettre le passage d'objets. Droite?
• L'utilisation de sockets Unix fournirait également une fonctionnalité similaire à celle de PowerShell à distance, mais au moment de la rédaction, j'ai supposé que c'était une limitation difficile de faire une élévation locale sans aucun service supplémentaire fonctionnant en tant que système local pour effectuer l'échange de jetons ...

Par conséquent, comme la transmission à distance PowerShell est déjà là (et fonctionne également un peu sur ssh), nous devrions prioriser cette solution, je pense.

Et quelqu'un a même référencé un CVE où l'élévation du bouclage a été intentionnellement supprimée.

Je ne peux pas confirmer. Je suppose que le CVE pourrait simplement désactiver le bouclage par défaut, mais pas du tout.
Voir aussi https://github.com/PowerShell/PowerShell/issues/3874#issuecomment -510715727

@iSazonov : Cela ne fonctionne pas, il ne fournit que le jeton d'accès à faible privilège mais pas le jeton d'accès élevé (par exemple Mandatory Label\High Mandatory Level ). Je n'obtiens pas les autorisations administratives d'un PowerShell à faible privilège même si TrustedHosts est défini sur * pour moi. Le jeton de connexion est toujours de type interactif, même après Enter-PSSession.
Je peux en fait Enter-PSSession localhost -ScriptBlock {} mais la transmission des informations d'identification provoque un "Accès refusé". , non, il jette toujours "Accès refusé" qu'un autre système avait désactivé uac.

Mais je l'ai maintenant essayé également en utilisant SSH et cela fonctionne comme prévu, il fournit le jeton élevé ( Mandatory Label\High Mandatory Level ) avec le type de connexion Network.

Par conséquent, dans PSCore, nous pouvons compter sur psrp pour l'élévation (même localement via Enter-PSSession -HostName localhost qui fonctionne également avec des informations d'identification explicites transmises.
Où Enter-PSSession -ComputerName localhost -Credential $foo ne le fait pas (même si $ foo.Username est le même que l'utilisateur actuel)

@ agowa338 Je pense que nous ne devrions pas discuter du contournement des fonctionnalités de sécurité de WinRM ici (c'est un domaine sensible à la conformité). Je ne peux qu'indiquer (1) que quel que soit le protocole, la sécurité doit rester au même niveau, ce qui implique que le bouclage SSH doit se comporter de la même manière que pour WinRM en tenant compte du fonctionnement des internes de Windows, (2) L'implémentation PS sudo devrait fonctionner tout transport.

@iSazonov : Je n'ai pas demandé d'exploit, mais seulement ce qui doit être configuré pour l'activer. Vous devez également être le seul à avoir compris comment configurer WinRM afin d'autoriser l'élévation en boucle.
J'ai essayé d'activer cela pendant très longtemps. Toutes les questions (sur stackoverflow, reddit, problèmes github, ...) que je rencontre se terminent par "windows is wird", "don't know what windows does there", "Ce n'est documenté nulle part", "Windows ne fournit pas cette capacité "," Utiliser Linux à la place "," Désactiver l'UAC "," Vous devez écrire un service de courtier qui s'exécute avec les privilèges système ". Alors s'il vous plaît, si vous l'avez compris, partagez vos connaissances.

Je ne peux qu'indiquer (1) que quel que soit le protocole, la sécurité doit rester au même niveau

Qu'est-ce que tu veux dire par là?

ce qui implique que le bouclage SSH doit se comporter de la même manière que pour WinRM en tenant compte du fonctionnement des internes de Windows

Eh bien, SSH a un service système qui agit comme un courtier en arrière-plan pour faire exactement cela. Il fournit un jeton d'accès au réseau ...

(2) L'implémentation de PS sudo devrait fonctionner sur n'importe quel transport.

Eh bien, ce n'est pas pour WinRM exactement pour cette raison. Donc, si c'est vrai ce que vous avez dit, nous avons besoin de documentation sur la façon d'activer WinRM en boucle.

si vous l'avez compris, partagez vos connaissances.

@ agowa338 L' équipe MSFT m'a demandé de ne pas discuter de sécurité publiquement et je suis le CoC. Je soutiens votre désir d'explorer ce sujet en profondeur, mais dans le cadre de cette discussion, c'est un casse-tête pour MSFT comment intégrer cette solution dans Windows et maintenir la conformité de la sécurité.

Eh bien, cela n'aide personne.

Pour le convoquer:

• Vous dites que Windows a des capacités de type sudo dans WinRM.
• Il n'est pas documenté qu'il existe ni comment l'activer / le désactiver.
• Divulguer comment l'utiliser constituerait un risque pour la sécurité.

Désolé, mais cela ressemble à une porte dérobée et non à une fonctionnalité. Il est inutilisable pour quiconque sauf vous.
La sécurité par l'obscurité n'a pas non plus fonctionné dans le passé ...

Nous revenons donc à ce qu'il n'est actuellement pas implémenté et nous avons besoin d'un service de courtier que ...

@ agowa338 Nous avons rassemblé suffisamment d'informations pour que l'équipe MSFT puisse conclure. S'ils trouvent des problèmes de sécurité, ils nous montreront une alternative acceptable.

Cela était possible mais a été corrigé plus tôt cette année https://devblogs.microsoft.com/powershell/windows-security-change-affecting-powershell/ avec le correctif KB4480116 et toutes les mises à jour cumulatives ultérieures. Avant cette mise à jour, il était possible d'élever vos privilèges si vous avez le LocalAccountTokenFilterPolicy défini sur 1, ce que fait winrm quickconfig (et est vraiment requis pour WinRM).

Il y a une note là-bas indiquant que les points de terminaison JEA ne sont pas affectés, vous pouvez donc créer votre propre PSSessionConfiguration et vous y connecter, mais je n'ai pas testé cela pour vérifier. Personnellement, je pense que ce correctif est ridicule car ce correctif empêche simplement le client PowerShell de se connecter à localhost, mais vous pouvez facilement le contourner si vous savez ce que vous faites. Par exemple, je peux toujours passer de limité à élevé sans toucher à l'UAC en utilisant SSH ou un autre client PSRemoting comme ça

PS C:\Users\vagrant> whoami.exe /groups  # prove the current process is limited

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
======================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Group used for deny only

BUILTIN\Administrators                                        Alias            S-1-5-32-544 Group used for deny only

BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Performance Log Users                                 Alias            S-1-5-32-559 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\REMOTE INTERACTIVE LOGON                         Well-known group S-1-5-14     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\INTERACTIVE                                      Well-known group S-1-5-4      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
LOCAL                                                         Well-known group S-1-2-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\Medium Mandatory Level                        Label            S-1-16-8192

PS C:\Users\vagrant> ssh vagrant<strong i="11">@localhost</strong> whoami.exe /groups  # prove that SSH is elevated
vagrant<strong i="12">@localhost</strong>'s password:

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
===================================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Mandatory group, Enabled by
default, Enabled group
BUILTIN\Administrators                                        Alias            S-1-5-32-544 Mandatory group, Enabled by
default, Enabled group, Group owner
BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NETWORK                                          Well-known group S-1-5-2      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\High Mandatory Level                          Label            S-1-16-12288

PS C:\Users\vagrant> python -c "from pypsrp.client import Client; c = Client('localhost', username='vagrant', password='
<password>', ssl=False); print(c.execute_ps('whoami.exe /groups')[0])"

GROUP INFORMATION
-----------------

Group Name                                                    Type             SID          Attributes

============================================================= ================ ============ ============================
===================================
Everyone                                                      Well-known group S-1-1-0      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account and member of Administrators group Well-known group S-1-5-114    Mandatory group, Enabled by
default, Enabled group
BUILTIN\Administrators                                        Alias            S-1-5-32-544 Mandatory group, Enabled by
default, Enabled group, Group owner
BUILTIN\Remote Management Users                               Alias            S-1-5-32-580 Mandatory group, Enabled by
default, Enabled group
BUILTIN\Users                                                 Alias            S-1-5-32-545 Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NETWORK                                          Well-known group S-1-5-2      Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Authenticated Users                              Well-known group S-1-5-11     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\This Organization                                Well-known group S-1-5-15     Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\Local account                                    Well-known group S-1-5-113    Mandatory group, Enabled by
default, Enabled group
NT AUTHORITY\NTLM Authentication                              Well-known group S-1-5-64-10  Mandatory group, Enabled by
default, Enabled group
Mandatory Label\High Mandatory Level                          Label            S-1-16-12288

Nous pouvons voir qu'en utilisant SSH, nous avons un jeton élevé, nous pouvons également voir qu'en utilisant une bibliothèque tierce, nous pouvons toujours utiliser localhost PSRemoting qui crée un jeton élevé et que le correctif n'est pas un bloc total de cette fonctionnalité.

Je ne vois pas cela comme un problème de sécurité ou le franchissement d'une frontière de sécurité car MS a répété à plusieurs reprises que l'UAC n'est pas une frontière de sécurité

• https://blogs.technet.microsoft.com/markrussinovich/2007/02/12/psexec-user-account-control-and-security-boundaries/
• https://blogs.msdn.microsoft.com/e7/2009/02/05/update-on-uac/

Il peut être proche ou agir de la même manière, mais ce n'est pas infaillible. L'une de ces façons de contourner l'UAC est la propriété de registre connue et documentée LocalAccountTokenFilterPolicy . Le but explicite de cette propriété est de garantir que les ouvertures de session réseau sont toujours élevées et non le jeton filtré et elle indique explicitement que ne pas activer cette option empêche les attaques de «bouclage»

Pour mieux protéger les utilisateurs qui sont membres du groupe Administrateurs local, nous implémentons des restrictions UAC sur le réseau. Ce mécanisme permet d'éviter les attaques de "bouclage". Ce mécanisme permet également d'empêcher les logiciels malveillants locaux de s'exécuter à distance avec des droits d'administration.

En fin de compte, cela signifie qu'il n'y a pas de moyen vraiment officiel sur Windows d'élever vos privilèges de limités à un administrateur de manière non interactive. C'est assez simple à utiliser Start-Process ... -Verb Runas mais cela nécessite une connexion interactive pour afficher l'invite UAC. Avoir un mécanisme de type sudo aiderait à atténuer ce problème, mais pour le faire correctement, il faudrait travailler dans Windows lui-même et ne pas être spécifique à PowerShell. Il existe des «solutions de contournement», mais je ne les appellerais pas officielles et ne sont qu'un sous-produit connu de l'activation de WinRM.

PowerShell

Changement de sécurité Windows affectant PowerShell |

Changement de sécurité Windows affectant PowerShell 9 janvier 2019 Le récent (1/8/2019) correctif de sécurité Windows CVE-2019-0543, a introduit un changement radical pour un scénario de communication à distance PowerShell. Il s'agit d'un scénario à portée étroite qui devrait avoir un faible impact pour la plupart des utilisateurs. Le changement de rupture n'affecte que la communication à distance en boucle locale,

Blog de Mark

PsExec, contrôle de compte d'utilisateur et limites de sécurité

J'ai introduit le commutateur -l dans PsExec il y a environ un an et demi comme moyen simple d'exécuter des processus avec des droits d'utilisateur standard à partir d'un compte administratif sous Windows XP. Dans Running as Limited User - The Easy Way, j'ai décrit comment PsExec utilise l'API CreateRestrictedToken pour créer un contexte de sécurité qui est un ...

Ingénierie Windows 7

Mise à jour sur l'UAC

Salut, Jon DeVaan ici pour vous parler des récents commentaires de l'UAC que nous avons reçus. La plupart de notre travail de finition de Windows 7 est axé sur la réponse aux commentaires. Les commentaires de l'UAC sont intéressants sur quelques dimensions du processus de prise de décision en ingénierie. Je pensais qu'explorer ces dimensions ferait un e7 intéressant ...

@iSazonov Aucune de ces suggestions n'accomplira une élévation de commande _user-interactive_ à partir de _dans la même session de console_, en particulier dans un environnement qui _ manque d'UAC_. Il semble que vous puissiez parler au nom de Microsoft sur ces questions. Pouvez-vous donc préciser s’ils ne sont tout simplement pas intéressés par l’introduction d’une fonctionnalité telle que je l’ai décrite?

Si tel est le cas, comme je l'ai interprété à partir des articles ci-dessus, il semble prudent de fermer ce fil, car le reste d'entre nous, les utilisateurs, devra chercher ailleurs des solutions telles que l' idée de @parkovski .

Il semble que vous puissiez parler au nom de Microsoft sur ces questions

Je suis un mainteneur communautaire du projet, non membre de MSFT et je ne peux pas parler au nom de Microsoft.

pourriez-vous préciser s'ils ne sont tout simplement pas intéressés par l'introduction d'une fonctionnalité telle que je l'ai décrite?

_Toutes les propositions ont de la valeur; aucun d'entre eux n'est rejeté. La discussion est juste pour recueillir toutes les propositions possibles._

Actuellement, j'essaie de résumer toutes les propositions afin que nous puissions aller de l'avant et ne pas stagner.

Que je vois.
Le scénario principal est l'adoption des utilisateurs Unix sur Windows.

• Historiquement, les utilisateurs d'Unix travaillent dans une seule console et sudo les aide nativement à faire un travail avec des droits élevés dans la console _same_
• Historiquement, les utilisateurs de Windows ouvrent une nouvelle fenêtre avec une console à droits élevés si nécessaire. Cela fonctionne bien de nombreuses années car c'est pratique dans un environnement multi-fenêtres. (Les utilisateurs de Windows pourraient également bénéficier de pssudo en tenant compte de Windows Core et Nano)

Les attentes sont donc:

• pssudo ne fonctionne que dans les sessions interactives
• pssudo n'ouvre pas de nouvelle console (la fenêtre UAC est acceptable sous Windows, nous ne voulons pas casser la sécurité et l'esprit de Windows)
• identifiants de cache pssudo en temps opportun
• pssudo ne met pas en cache un état de session pour la sécurité
• le même UX (que possible) est sur toutes les plateformes
• pssudo exécute des commandes natives
• pssudo exécute des blocs / fichiers de script PowerShell

Détails d'implémentation:

• La communication à distance PowerShell est la solution la plus puissante et la plus fonctionnelle. Il est déjà implémenté et fonctionne. D'autres devraient également émuler cette fonctionnalité pour exécuter des blocs de script PowerShell par utilisateur / par session / par espace d'exécution / par état d'étendue.
• Le transport préféré est WinRM car toute l'infrastructure Windows en est basée. Un certain investissement est nécessaire dans WinRM, bien que MSFT ne le souhaite pas car il est basé sur SOAP.
• Le transport SSH pourrait être. Ce n'est toujours pas la norme pour Windows. Nécessite un investissement important pour la mise en œuvre et la maintenance. Et il y a un problème avec les anciens systèmes.
• Autres transports comme les sockets Unix. Nécessite de gros investissements non seulement dans l'infrastructure mais aussi dans PowerShell.

@ mklement0 Je me demande que je fais ici ce que vous faites généralement bien :-) Vous me volez d'être un adversaire :-)

Pourquoi ne pas écrire un binaire Windows qui nécessite des privilèges qui démarre une instance PowerShell avec les commandes qui lui sont passées. Il faudrait que ce soit une application en mode console pour fonctionner correctement. Ensuite, pour Linux, nous écrivons un script qui nécessite des autorisations qui démarre une instance PowerShell avec les commandes fournies. Si cela fonctionne dans la pratique comme en théorie, PowerShell sera lancé avec des autorisations élevées, exécutera les commandes et quittera.

Pourquoi ne pas écrire un binaire Windows qui nécessite des privilèges qui démarre une instance PowerShell avec les commandes qui lui sont passées. Il faudrait que ce soit une application en mode console pour fonctionner correctement.

Parce que l'API Windows empêche cela et l'application console s'ouvrirait dans une nouvelle fenêtre. Nous avons déjà parlé de solutions de contournement possibles.

Une chose à garder à l'esprit est que peu importe la façon dont cela est mis en œuvre, il y a toujours un saut de processus vers et depuis un processus élevé. Cela signifie que vous aurez toujours des objets désérialisés dans le pipeline et que ces limitations s'appliqueront. Dans de nombreux cas, ce ne sera pas un problème, mais si une applet de commande attend un objet .NET actif, cela ne fonctionnera pas.

Pour prendre en charge JEA avec SSH, nous aurions éventuellement besoin d'un démon / service généralisé qui remplace de toute façon le besoin de WinRM en tant que service. À ce moment-là, nous évaluerions l'utilisation de cela pour élever une partie du pipeline.

Pour info: https://github.com/gerardog/gsudo

GitHub

gerardog / gsudo

Un Sudo pour Windows - s'exécute en élévation sans couvrir une nouvelle fenêtre d'hôte de console - Gerardog / GSudo

Pour info: https://github.com/gerardog/gsudo

GitHub gerardog / gsudo A Sudo pour Windows - Exécuter en élévation sans couvrir une nouvelle fenêtre d'hôte de console - gerardog / gsudo

Encore mieux
http://blog.lukesampson.com/sudo-for-windows

GitHub

gerardog / gsudo

Un Sudo pour Windows - s'exécute en élévation sans couvrir une nouvelle fenêtre d'hôte de console - Gerardog / GSudo

Luke Sampson - Sudo pour Windows

Sudo pour Windows

Encore mieux

Non.

Gsudo ne demande pas de mot de passe à chaque fois et est remarquablement plus rapide à installer et à utiliser.

Il me semble que cette question devrait être acceptée (ce qui signifie qu'il faudrait lui donner plus de temps et d'organisation) à en juger par l'intérêt non seulement de ce billet. Il n'est pas correct de ne pas le reconnaître officiellement comme une tâche de travail car les difficultés techniques actuellement perçues ne seront pas résolues sans une participation active.

J'utilise gsudo depuis quelques mois maintenant et je ne peux pas imaginer revenir constamment à l'horreur traditionnelle de Windows UAC.

@majkinetor ce problème a été https://github.com/PowerShell/PowerShell/issues/11343 pour approfondir la discussion sur la conception