Terminal: [Pregunta] Configuración del perfil de Terminal de Windows para que siempre se inicie elevado

No hay. No creo que planeemos admitir pestañas mixtas elevadas y no elevadas, porque es un pequeño agujero de seguridad.

Sí, sé que sudo existe, pero hemos tenido muchas conversaciones con el equipo de seguridad sobre la creación de un sudo para Windows. El principal problema se debe al hecho de que cualquier proceso no elevado puede enviar pulsaciones de teclas a cualquier otra ventana no elevada.

Si tenía una línea de comando elevada ejecutándose en una ventana no elevada, un mal actor que no sea de confianza podría ejecutar un ataque de elevación de privilegios al controlar las ventanas no elevadas que ejecutan la línea de comando elevada.

(como cuestión de enlazar hilos relacionados, #146)

EDITAR (14 de febrero de 2020)
Vale, entonces este comentario no envejeció muy bien. Originalmente, no había ningún plan para respaldar esto, ya que no funcionaría con el único HWND que teníamos. Estamos trabajando en el diseño de una solución que _podría_ respaldar esto en el futuro, pero no podemos comprometernos con nada hasta que estemos seguros de que podemos encontrar una solución apropiadamente segura, que asegure que un proceso con menos privilegios no pueda conducir una terminal de mayor privilegio.

Parece razonable. Creo que tener algo como una combinación de # 576 (Abrir como administrador en la lista de salto) y tal vez algún tipo de tecla de acceso rápido para iniciar una sesión de administración de la Terminal resolvería la mayor parte de mi dolor aquí.

¿Qué hay de tener una Terminal estándar y elevada abierta en una sola ventana pero con pestañas separadas?

@mdtauk Creo que, lamentablemente, cae en la misma categoría. Dado que todas las pestañas están bajo el mismo HWND, el HWND raíz es lo que debería elevarse para evitar que las aplicaciones no elevadas controlen la ventana.

Desde el punto de vista de la seguridad (ignorando el diseño de Windows Terminal, HWND de raíz única, etc.), cuán "menos seguro" es que Terminal ejecute pestañas de elevación mixta en comparación con ejecutar, por ejemplo, una instancia elevada de PowerShell junto a una no elevada en la UX actual ? El hecho de que las aplicaciones de la consola estén alojadas en las pestañas de la Terminal no hace ninguna diferencia para mí...

En una nota similar: ¿Cómo es más seguro tener una ventana no elevada incluso si abro una sesión remota de PS donde ahora puedo tener privilegios de administrador en un servidor remoto que ahora podría manejar una ventana no elevada? Para mí, esto parece mucho peor que obtener acceso de administrador local, por lo que no creo que ejecutar una pestaña como administrador sea diferente a la conexión remota / ssh a otros servidores. En ambos casos, necesito sentirme lo suficientemente cómodo con mi sistema para hacerlo. Es una cosa de "soy lo suficientemente mayor y entiendo los riesgos".

Cada vez que intento ejecutar la aplicación Terminal con una cuenta de administrador, haga clic derecho -> ejecutar como administrador, el UAC aparece dos veces y aparece un error que dice:
"Windows no puede encontrar (ruta\WindowsTerminal.exe) Asegúrese de haber escrito...".

La ruta existe y la aplicación funciona correctamente para el usuario no administrador que creó la aplicación, pero el otro usuario administrador no puede ejecutarla.
Si inicio sesión con el usuario administrador, la aplicación de terminal no está presente ni en la configuración ni en el menú de inicio, como si nunca se hubiera instalado en el sistema.

¿Hay alguna manera de compilar la aplicación para que se instale para todos los usuarios? ¿O la raíz del proyecto tiene que estar en un directorio no específico del usuario?

@

Cada vez que intento ejecutar la aplicación Terminal con una cuenta de administrador, haga clic derecho -> ejecutar como administrador, el UAC aparece dos veces y aparece un error que dice:
"Windows no puede encontrar (ruta\WindowsTerminal.exe) Asegúrese de haber escrito...".

La ruta existe y la aplicación funciona correctamente para el usuario no administrador que creó la aplicación, pero el otro usuario administrador no puede ejecutarla.
Si inicio sesión con el usuario administrador, la aplicación de terminal no está presente ni en la configuración ni en el menú de inicio, como si nunca se hubiera instalado en el sistema.

¿Hay alguna manera de compilar la aplicación para que se instale para todos los usuarios? ¿O la raíz del proyecto tiene que estar en un directorio no específico del usuario?

Estoy viendo el mismo problema sucediendo también.

Versión de Windows 18922.1000

Correcto, entonces ejecutar aplicaciones de la tienda como administrador o usuario diferente no funciona (por diseño, por cierto). Muchos de nosotros estamos conectados (a la PC) como una cuenta normal no elevada. Ejecutamos powershell/cmd/etc como administrador para realizar ciertas tareas.

Si la opción final es implementar esta aplicación es la tienda de Windows, es inútil para mí sin alguna forma de abrir pestañas elevadas. Mis 2 centavos.

"Inútil" es tal vez un poco duro, pero de hecho necesitamos una forma de usar el nuevo terminal tanto para aplicaciones/shells de consola no elevados como elevados. Y para mí, la mejor UX sería admitir una combinación de pestañas elevadas y no elevadas en la misma instancia de Windows Terminal. Menos preferible: admite de cero a muchas (normalmente una) instancias elevadas (cada una con una a muchas pestañas) junto con cero a muchas (normalmente una) instancias no elevadas.

ConEmu puede mezclar pestañas elevadas y no elevadas en la misma ventana. ¿No se puede hacer algo así aquí?

¿Podríamos tener una Terminal elevada que inicie pestañas no elevadas? Todavía necesito iniciar elevado PERO puedo abrir una nueva pestaña que está "protegida".

Si queremos ser muy específicos de Windows e ignorar otras plataformas que eventualmente pueden ver Terminal, tal vez el uso de Contenedores de Windows o procesos virtualizados podría ayudar a algunos a solucionar este problema. Personalmente, estoy bien con la solución actual, pero hacer que las aplicaciones de la consola se ejecuten como procesos aislados de forma predeterminada no sería una mala idea desde el punto de vista de la seguridad.

La elevación mixta en una ventana es imprescindible, al menos para mí.
¿Podría ser una característica opcional para alternar en la configuración?

@pratnala Con ConEmu solo _parece_ que está haciendo eso, pero en realidad no lo está haciendo en absoluto. Las "pestañas" elevadas y no elevadas son solo vistas en dos ventanas/procesos raíz completamente separados y aislados. Lo hace raspando el contenido de las ventanas, entre otras cosas, y ayudantes de elevación de proxy/intermediario, etc. Claro, es técnicamente posible, pero lo que hace ConEmu en realidad es un poco inseguro. Una cosa es que un programa de terceros haga esto y que la gente opte por el riesgo al descargar ConEmu, pero otra muy distinta es que Microsoft respalde oficialmente esto al hacerlo él mismo. Si quiero esconder las llaves de la puerta principal debajo del felpudo, está bien, ese es mi riesgo tonto. Pero, ¿y si en cada puerta que compras pusieras un juego de llaves debajo del felpudo?

Pero mire, desarrollo en C++ (y C#, PowerShell, Ruby, Python, GoLang, prácticamente cualquier cosa que se me presente). Tengo ConEmu y TakeCommand instalados, junto con mingw. Sé de qué manera sostener las tijeras mientras corro.

PowerShell _es_ un agujero de seguridad. Una herramienta de automatización muy útil, que permite todo tipo de accesos inesperados. Y lo que estamos pidiendo (modos mixtos) es ciertamente más seguro que la alternativa (todo elevado). Realmente este (terminal) es una herramienta poderosa para los usuarios avanzados, la mayoría de los cuales probablemente entienden muy bien el panorama de la seguridad... y entienden compromiso pragmático.

La confianza cero solo funciona cuando no es debilitante.

@robomac Si pudiéramos convencer al equipo de seguridad (que nos ha dicho en múltiples ocasiones que ni siquiera nos aventuremos remotamente cerca de elevaciones mixtas) que solo las personas que saben cómo sostener sus tijeras de la manera correcta y no correr con ellas _usarían_ este proyecto, probablemente lo haríamos. No sé si yo mismo me lo creo. Este es el por qué:

Al igual que no, si Terminal se ejecuta en elevación mixta (desde un host de IL medio a un cliente de IL alto), aún puede verse obligado a recibir información de cualquier otra cosa que se ejecute como ese usuario. Incluso si la persona detrás del teclado es un santo y solo se eleva durante los diez segundos que necesita para elevar, _cualquier aplicación que se ejecute bajo su cuenta de usuario puede hacerse pasar por el administrador sin un aviso de elevación adicional_. Probablemente completamente desapercibido, incluso.

@DHowett-MSFT Gracias por responder. Usted asume que estamos permitiendo que se ejecuten procesos maliciosos de todos modos. Restringimos los permisos de los mantras de "Mejores prácticas" que hacemos con nuestra pose de perro boca abajo todas las mañanas, pero si realmente le preocupa que unas pocas horas, incluso, de acceso elevado a la terminal lo ponga en riesgo _en su propio sistema que estás desarrollando en_ ...

1. No deberías estar ejecutando Terminal y
2. Deberías limpiar y empezar de nuevo.

Le concedo que un investigador de virus (de computadora) no debería arriesgarse a esto en una ruta vectorial... pero incluso desde el principio los estábamos encerrando en máquinas virtuales. Pero "Terminal" no es para tus parientes inexpertos; es una herramienta eléctrica.

Hay una forma estándar de lidiar con el riesgo. Traído a usted por el mundo del navegador. Cuando vas a las banderas avanzadas, recibes una advertencia de, más o menos, "Aquí hay dragones". (Creo que es precisamente eso en Pale Moon ... que es el navegador de seguridad más serio). Agregue la advertencia (no UAC, adicional), pero deje que el usuario decida.

Otra pregunta: ¿se comportarían como se esperaba dos sesiones distintas de Terminal, una elevada y otra no? ¿O ambos serían vectores para alguna sesión?

No estoy en desacuerdo con que las personas deberían poder optar por algo como esto. :sonreír:

dos sesiones distintas

Oh, sí, eso debería funcionar absolutamente hoy, y no ser un vector (el elevado se está ejecutando completamente en el lado del mundo de High-IL y no puede ser impulsado por ningún otro proceso de Medium-IL)

eso debería funcionar absolutamente hoy

Con el mismo espíritu, ¿no se pueden ejecutar 2 pestañas en diferentes procesos y, por lo tanto, habilitar la elevación mixta en la misma ventana?

@DHowett-MSFT Entonces, ¿por qué no se pueden alojar las dos sesiones distintas en la aplicación general? Realmente no es difícil de hacer.

Creo que entiendo las implicaciones de seguridad de tener aplicaciones de consola elevadas en primer lugar, pero lo que no puedo entender es por qué tener dos tipos de pestañas (elevadas y no elevadas) dentro de Windows Terminal sería _más riesgoso_ que lo que admite Windows. para las edades, es decir, ejecutar CMD elevados y no elevados / PowerShell de lado a lado. ¿Alguien puede arrojar algo de luz sobre esto?

@robomac
[1] Es trivial cuando _aloja ventanas tradicionales_ con identificadores de ventana tradicionales. Eso funciona muy bien en el caso de conemu, o en el caso de shell con pestañas, donde puede tomar el control de una ventana en una sesión elevada y volver a crear un padre bajo una ventana en una sesión no elevada.

Cuando haga eso, hay algunas características de seguridad que mencionaré en [2]. Debido a eso, puedes criarlo pero realmente no puedes obligarlo a hacer nada.

Sin embargo, hay un problema. La Terminal no está diseñada como una colección de ventanas re-parentales. Por ejemplo, no está ejecutando un host de consola y moviendo su ventana a una pestaña. Fue diseñado para admitir una "conexión", algo que pueda leer y escribir texto. Es una primitiva de nivel inferior a una ventana. Nos dimos cuenta del error de nuestras formas y decidimos que el modelo UNIX era correcto todo el tiempo, y las tuberías, el texto y los flujos están _donde están._

Dado que estamos usando islas Xaml para alojar una interfaz de usuario moderna y unir una superficie DirectX en ella, estamos mucho más allá del mundo de los identificadores de ventana estándar de todos modos. Las islas Xaml están completamente compuestas en un solo HWND, al igual que Chrome y Firefox y la gama de juegos DirectX/OpenGL/SDL. No tenemos componentes que se puedan ejecutar en un proceso (elevado) y alojar en otro (no elevado) que no sean las "conexiones" antes mencionadas.

Ahora, la pregunta de seguimiento obvia es _"¿por qué no puede tener una conexión elevada en una pestaña junto a una conexión no elevada?"_ Aquí es donde @sba923 debería continuar leyendo (:sonrisa:). Probablemente cubriré algunas cosas que tú (@robomac) ya sabes.

[2] Cuando tiene dos ventanas en el mismo escritorio en la misma estación de ventana, pueden comunicarse entre sí. Puedo usar SendKeys fácilmente a través WScript.Shell para enviar entradas de teclado a cualquier ventana que pueda ver el shell.

Ejecutar un proceso elevado _corta_ esa conexión. El caparazón no puede ver la ventana elevada. Ningún otro programa con el mismo nivel de integridad que el shell puede ver la ventana elevada. Incluso si tiene su identificador de ventana, en realidad no puede interactuar con él. Esta es también la razón por la que no puede arrastrar/soltar desde el explorador al bloc de notas si el bloc de notas se está ejecutando elevado. Solo otro proceso elevado puede interactuar con otra ventana elevada.

Esa característica de "seguridad" (llámela como quiera, probablemente fue pensada para ser una característica de seguridad en algún momento) solo existe para algunos tipos de objetos globales de sesión. Las ventanas son una de ellas. Las pipas no son realmente uno de ellos.

Por eso, es trivial romper esa seguridad. Tome la terminal como un ejemplo de eso. Si iniciamos una conexión elevada y la alojamos en una ventana _no elevada_, de repente creamos un conducto a través de ese límite de seguridad. Lo elevado en el otro extremo no es una ventana, es solo una aplicación en modo texto. Inmediatamente hace la oferta del host no elevado.

Cualquiera que pueda _controlar_ el host no elevado (como WScript.Shell::SendKeys ) _también_ obtiene un conducto instantáneo a través del límite de elevación. De repente, cualquier aplicación de integridad media en su sistema puede controlar un proceso de integridad alta. Este podría ser su navegador, o el minero de bitcoin que se instaló con el paquete left-pad de NPM, o realmente cualquier cantidad de cosas.

Es un pequeño riesgo, pero _es_ un riesgo.

Otras plataformas han aceptado ese riesgo en favor de la comodidad del usuario. No se equivocan al hacerlo, pero creo que Microsoft obtiene menos "aprobación" en cosas como "aceptar el riesgo por conveniencia del usuario". Windows 9x fue un desastre de seguridad absoluto, y las cuentas de usuario limitadas y las indicaciones de elevación y la seguridad a nivel de kernel para la administración de ventanas fueron la respuesta a esas cosas. No son cerraduras para aflojar a la ligera.

@ DHowett-MSFT Muchas gracias por la aclaración. Creo que tendremos que acostumbrarnos a ejecutar una instancia elevada de Windows Terminal y una instancia no elevada en paralelo, como lo estamos haciendo con las aplicaciones de consola en estos días.

Fascinante. Gracias. La terminal es más un renderizador de conexiones que una ventana, tiene sentido. ¿Eso le da a PowerShell, que ya se enfoca más bien en la tubería/conexión, algún control adicional sobre el anterior en una consola con ventana?

¿Las sesiones de Terminal separadas están completamente aisladas entre sí?

Estaría completamente satisfecho con solo tener una indicación de que estoy en una sesión elevada. Como "Administrador: \ Me estoy perdiendo eso bastante mal en este momento.

???

¡"Ejecutar como un usuario diferente" es algo que todos los administradores de Windows necesitan! Esto sería muy útil si está disponible. La mejor opción sería tenerlo con una bandera en la configuración para cada perfil.

Por cierto, hablando de aislamiento de ventanas, permítanme citar el último informe de vulnerabilidad de ctfmon

El ataque obvio es un usuario sin privilegios que inyecta comandos en la sesión de la consola de un administrador o lee las contraseñas cuando los usuarios inician sesión. Incluso los procesos de AppContainer en espacio aislado pueden realizar el mismo ataque.

@ecki Esa es una noticia bastante inquietante. Estoy seguro de que Tavis está de fiesta esta noche después de eso.

@DHDHowett-MSFT
Como muchos han escrito aquí, si el nuevo terminal no puede comenzar con la opción "ejecutar como un usuario diferente", entonces para una gran cantidad de usuarios no es muy útil, tampoco es compatible con el "modelo de nivel administrativo de Active Directory" de Microsoft. si, por ejemplo, tiene un usuario de AD con derechos predeterminados y ejecuta scripts de PS con un usuario administrador en un controlador de dominio.

No tengo muchos casos en los que inicio una terminal con mi usuario conectado actualmente... así que les pregunto, ¿cuál es el caso de uso de esta Terminal? Ping, nslookup, etc., si esa es la intención, ¿por qué estás poniendo tanto trabajo en todo esto?

Con "ejecutar como administrador" tiene algunos puntos válidos, pero ¿por qué otras consolas como (PS6/7) aún admiten estas funciones, si es tan inseguro?

Siempre pensé que la nueva aplicación Terminal reemplazaría todas las ventanas cmd/PS/… separadas, pero parece que no se puede usar en muchos escenarios del mundo real. Esto es un poco triste tbh...

@Fisico tu experiencia no es universal, y te animo a que lo consideres cuando le pidas a alguien que justifique la existencia misma de su proyecto.

Para su punto general sobre "ejecutar como un usuario diferente" que no existe/no funciona: esa es una limitación de la plataforma que estamos tratando de eliminar. No es por malicia o incompetencia que no lo apoyamos.

En cuanto a por qué otras aplicaciones de consola lo admiten, no es inseguro cuando lo hacen porque específicamente no alojan diferentes niveles de elevación en la misma ventana. Ese es el tema central aquí. Debido a que están alojados en procesos independientes con ventanas independientes, están libres de la restricción de la manipulación de niveles de integridad cruzada.

@DHowett-MSFT
Perdona si te ofendí con mi post, no era mi intención, le puse demasiada emoción.
Creo que la Terminal es una gran idea y tiene un gran potencial y me alegra que la estés desarrollando con la comunidad para aprovecharla al máximo.

En este punto hay mucha confusión sobre lo que se implementa y lo que no.
"Ejecutar como administrador" para toda la aplicación está funcionando en este momento, ¿está aquí para quedarse?

Según tengo entendido, "Ejecutar como administrador" para cada pestaña/perfil no es algo que desee implementar. Creo que esto está bien para la mayoría de nosotros.

"Ejecutar como un usuario diferente" no es posible porque Windows no lo admite para aplicaciones, ¿y usted / nosotros tenemos que esperar hasta que Windows lo admita? Si es así, ¿estamos hablando de años?

¿“Ejecutar como usuario diferente” por pestaña/perfil también es algo que no desea implementar?

@DHDHowett-MSFT
Como muchos aquí han escrito, si la nueva terminal no puede comenzar con la opción "ejecutar como usuario diferente"
que para una gran cantidad de usuarios no es muy útil, ... Siempre pensé que la nueva aplicación Terminal
reemplace todas las ventanas cmd/PS/… separadas, pero parece que no se puede usar en muchos escenarios del mundo real. Esto es un poco triste tbh...

no estoy de acuerdo Este es un gran avance sobre lo que teníamos antes. Desafortunadamente, la mayoría de nosotros probablemente nos hayamos acostumbrado a ejecutar nuestros proyectiles elevados debido a la falta de un enfoque más granular... y todavía podemos hacerlo. No podemos _mezclarlos_... pero nunca lo hicimos. En serio, en las _últimas tres_ empresas en las que he estado, Developer Wiki ha realizado todas las compilaciones/pruebas en un indicador de VS elevado. Implementamos seguridad a través de escaneos en tiempo real, cortafuegos activos agresivos y sabiendo que nuestros desarrolladores rara vez cometen errores. Los _no desarrolladores_ nunca se ejecutan elevados, porque (1) no podemos confiar en ellos y (2) no necesitan hacerlo.

Así que, por mi parte, agradezco esta nueva Terminal. No es perfecto, pero tampoco lo es Take Command / TCC. Al menos esto es estándar.

@DHDHowett-MSFT
Como muchos aquí han escrito, si la nueva terminal no puede comenzar con la opción "ejecutar como usuario diferente"
que para una gran cantidad de usuarios no es muy útil, ... Siempre pensé que la nueva aplicación Terminal
reemplace todas las ventanas cmd/PS/… separadas, pero parece que no se puede usar en muchos escenarios del mundo real. Esto es un poco triste tbh...

no estoy de acuerdo Este es un gran avance sobre lo que teníamos antes. Desafortunadamente, la mayoría de nosotros probablemente nos hayamos acostumbrado a ejecutar nuestros proyectiles elevados debido a la falta de un enfoque más granular... y todavía podemos hacerlo. No podemos _mezclarlos_... pero nunca lo hicimos. En serio, en las _últimas tres_ empresas en las que he estado, Developer Wiki ha realizado todas las compilaciones/pruebas en un indicador de VS elevado. Implementamos seguridad a través de escaneos en tiempo real, cortafuegos activos agresivos y sabiendo que nuestros desarrolladores rara vez cometen errores. Los _no desarrolladores_ nunca se ejecutan elevados, porque (1) no podemos confiar en ellos y (2) no necesitan hacerlo.

Así que, por mi parte, agradezco esta nueva Terminal. No es perfecto, pero tampoco lo es Take Command / TCC. Al menos esto es estándar.

elevado! = ejecutar como un usuario diferente.
Ejecuto PowerShell más con otros usuarios de AD que con el mío propio.
Estoy de acuerdo en que a menudo ejecuta un cmd o PS como administrador, incluso si no es necesario, pero hay muchos casos en los que debe ejecutarlo como administrador. La mayoría de las tareas de administrador de sistemas requieren derechos de administrador o un usuario diferente con algún tipo de privilegios.
Claro, si necesita ejecutar cmd en el contexto del usuario, todo está bien.

Entiendo que "elevado! = ejecutar como usuario diferente". Simplemente no creo que "ejecutar como un usuario diferente" sea tan común como afirmas.

Entiendo que "elevado! = ejecutar como usuario diferente". Simplemente no creo que "ejecutar como un usuario diferente" sea tan común como afirmas.

Si tiene algo que ver con el universo de Microsoft, lo necesita absolutamente.
No es la mejor idea iniciar sesión en máquinas Windows con derechos de administrador de dominio, por ejemplo.
Ejecutar secuencias de comandos de PS con un usuario que tiene derechos de administrador de dominio u otros derechos es muy común.

@Fisico, ¿por qué no usar el comando New-PSSession entonces?

Los scripts automatizados que requieren algún tipo de elevación específica para un servicio generalmente requieren 'ejecutar como un usuario diferente'. Si eso se aplica a Terminal es una historia diferente. Siempre puede cambiar su inicio de sesión una vez en una sesión de CMD o PS usando el comando runas . Esto no cambiaría el estado de elevación de la pestaña, ya que utiliza el inicio de sesión subyacente, que es su usuario habitual. Además, cualquier secuencia de comandos que ejecutaría con el Programador de tareas o un trabajo cron no requerirá que se ejecute Terminal a menos que lo esté utilizando para obtener una funcionalidad que de alguna manera no existe en una sesión de consola normal. Si ese es el caso, la solución sería la utilización de parámetros para ejecutar ese script con Terminal, que se inicia como un proceso en segundo plano.

Por lo tanto, la elevación mixta para las pestañas no es necesaria. Tenemos una solución alternativa y es bastante fácil copiar los comandos runas específicos que necesita en un archivo txt que puede copiar/pegar en la Terminal y luego completar su contraseña (nunca debe guardar su contraseña en nada que no esté encriptado).

@SamuelEnglard
No quiero conectarme a un host remoto para ejecutar un script.

@WSLUser sí, es una opción usar runas, pero es mucho más conveniente simplemente ejecutar la terminal o PS como un usuario diferente. No veo por qué esto debería ser un problema.

@Fisico New-PSSession no necesita conectarse a una computadora remota, vea la segunda primera entrada de sintaxis.

@SamuelEnglard
No quiero conectarme a un host remoto para ejecutar un script.

@WSLUser sí, es una opción usar runas, pero es mucho más conveniente simplemente ejecutar la terminal o PS como un usuario diferente. No veo por qué esto debería ser un problema.

Es una operación bastante estándar para un usuario anclar PowerShell a la barra de tareas y hacer clic con el botón derecho para ejecutar como administrador o, en algunos entornos, ejecutar como otro usuario, ya que se necesita una cuenta elevada para ejecutar un script de nivel empresarial. Decir que no es posible para la terminal es como los entornos que aprovechan PSLockDown y obligan a RunAs Admin solo a cargar el shell o VSCode
En mi humilde opinión

Si realmente necesita ejecutar una pestaña como un usuario diferente, podría tener un perfil que ejecute New-PSSession -Credential | Enter-PSSession al inicio.

DESCARGO DE RESPONSABILIDAD : No asumo ninguna responsabilidad por las computadoras arruinadas por hacer esto.

Si realmente necesita ejecutar una pestaña como un usuario diferente, podría tener un perfil que ejecute New-PSSession -Credential | Enter-PSSession al inicio.

> DESCARGO DE RESPONSABILIDAD : No asumo ninguna responsabilidad por las computadoras arruinadas por hacer esto.

Claro, o la "seguridad" que está aquí podría ser reconsiderada. Una vez más, fijo PowerShell a mi barra de tareas, desde allí puedo iniciar PowerShell no elevado; Puedo hacer clic con el botón derecho en eso y elegir "Ejecutar como administrador" y, si estoy en un entorno corporativo, puedo hacer clic con el botón derecho en el ícono, luego presionar Mayús y hacer clic con el botón derecho en "Windows PowerShell" y seleccionar "Ejecutar como un usuario diferente" para iniciar PowerShell. con credenciales alternas. Sin sesiones, sin RDP'ing a otro host para obtener esas credenciales.

Claro, o la "seguridad" que está aquí podría ser reconsiderada. Una vez más, fijo PowerShell a mi barra de tareas, desde allí puedo iniciar PowerShell no elevado; Puedo hacer clic con el botón derecho en eso y elegir "Ejecutar como administrador" y, si estoy en un entorno corporativo, puedo hacer clic con el botón derecho en el ícono, luego presionar Mayús y hacer clic con el botón derecho en "Windows PowerShell" y seleccionar "Ejecutar como un usuario diferente" para iniciar PowerShell. con credenciales alternas. Sin sesiones, sin RDP'ing a otro host para obtener esas credenciales.

Sí, y también puedo hacerlo con Windows Terminal. Acordado. No veo cómo eso ayuda a aquellos que quieren tener una combinación de pestañas que se ejecutan como diferentes usuarios (o diferente elevación).

Dejando a un lado las "pestañas mixtas", solo quiero aclarar que NO PUEDE hacer eso con (la vista previa publicada) Terminal de Windows debido al diseño de las aplicaciones de la Tienda Windows. Solo puede ejecutar como el usuario que instaló esa aplicación e inició sesión como ese mismo usuario.

Todo lo que quiero es poder hacer lo que hago hoy, iniciar sesión en la PC como usuario normal y ejecutar shells elevados. Si Windows Terminal se lanza como está, me sirve de poco.

Muy buen punto. Esta limitación no existe con las compilaciones privadas (no de la tienda) de Windows Terminal.

Dejando a un lado las "pestañas mixtas", solo quiero aclarar que NO PUEDE hacer eso con (la vista previa publicada) Terminal de Windows debido al diseño de las aplicaciones de la Tienda Windows. Solo puede ejecutar como el usuario que instaló esa aplicación e inició sesión como ese mismo usuario.

Todo lo que quiero es poder hacer lo que hago hoy, iniciar sesión en la PC como usuario normal y ejecutar shells elevados. Si Windows Terminal se lanza como está, me sirve de poco.

Acabo de abrir 2 instancias de la compilación de la tienda de Windows Terminal: una elevada y otra no. Así que no sé por qué no te funciona.

Ok, tengo que creer que eres un administrador local en tu PC. Para ser claro, tal vez debería aclarar. Nunca soy un administrador local en mi estación de trabajo. Entonces, cuando voy a 'ejecutar como administrador', se me solicita el usuario/contraseña.

La cuenta de 'administrador' que uso es diferente de mi cuenta normal de lectura de malware/correo electrónico. Entonces, técnicamente, lo que hago es ejecutar como un usuario diferente. Esta es la limitación de la aplicación de la Tienda Windows. La solución (y tal vez lo hagan) es lanzarlo como un componente de Windows que no tendrá esas limitaciones.

* [URGENTE] TODOS HE ENCONTRADO SOLUCION A ESTE PROBLEMA! * *

Siguiendo esta guía
https://www.maketecheasier.com/access-windowsapps-folder-windows-10/
¡Puedes hacer que la carpeta de la aplicación de Windows sea tuya!

una vez que haya hecho esto, puede ubicar la carpeta Microsoft.WindowsTerminal._blahblahYourVersion_ . Una vez dentro, busque WindowsTerminal.exe como se muestra a continuación

Una vez que lo haya encontrado, cree un acceso directo de este archivo y colóquelo donde desee. Después de hacerlo, configúrelo para que se ejecute como administrador. Puede hacer esto haciendo clic derecho y yendo a _Propiedades>Avanzado>Ejecutar como administrador_ Después de eso, haga clic en Aceptar y ¡ya está todo listo!

Personalmente, necesitaba esto porque uso el acceso directo en mi barra de tareas para poder presionar _Windows+1_ para iniciarlo como administrador. No es el largo camino de navegar a través de mi menú de inicio para ejecutarlo correctamente.

También puede descomprimir el paquete que ponemos en la página de lanzamientos. Es solo un archivo ZIP. Tenga en cuenta que _no admitimos oficialmente_ la ejecución sin empaquetar.

¡Pero esto todavía significa que no hay una forma _admitida_ de correr elevado! Creo que esta es una característica imprescindible.

De hecho, estoy corregido.

Lo que _falta_ es la entrada "ejecutar como administrador" en el menú contextual de la barra de tareas.

Ayer hablé con algunas personas en una reunión y algunas personas dijeron que principalmente lanzan powershell con Windows+X y que les encantaría tener terminal/terminal como administrador allí.

¡Muy buen punto!

¡Ese es exactamente mi punto! Esta es la solución para ejecutarlo desde la barra de tareas
con privilegios de administrador!

El domingo 25 de agosto de 2019 a las 1:08 Stéphane BARIZIEN [email protected]
escribió:

¡Muy buen punto!

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/microsoft/terminal/issues/632?email_source=notifications&email_token=AKO4CP6JWWDNLGCHWNIJGFTQGIOULA5CNFSM4HL5EE72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CNA6Q#issuecomment-52460351
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AKO4CPZ6YRX5V3ERW4L2GWLQGIOULANCNFSM4HL5EE7Q
.

De hecho, estoy corregido.

Lo que _falta_ es la entrada "ejecutar como administrador" en el menú contextual de la barra de tareas.

En la barra de tareas, haga clic derecho dos veces. Una vez en el ícono para que aparezca el menú contextual, luego una segunda vez en el nombre de la aplicación. por ejemplo, "Terminal de Windows (vista previa)" y elija "Ejecutar como administrador"

Me siento confundido.

Rubor.

Avergonzado.

¿Cómo es que no pensé en esto?

Gracias de todos modos por compartir con todos nosotros!

Veamos el problema desde el otro extremo...
Windows permite que los procesos no elevados controlen otros procesos no elevados, enviando pulsaciones de teclas, capturando su interfaz de usuario, etc., pero evita que los procesos no elevados hagan eso en una ventana de un proceso elevado.
La Terminal de Windows está diseñada para usarse también para administrar servidores remotos, a través de ssh, comunicación remota de PowerShell, etc.
Esto significa que Windows Terminal se convierte en un agujero de seguridad tan pronto como se usa para la administración, ya que un malware local podría esperar una sesión de Windows Terminal para espiar lo que está haciendo el usuario, y tan pronto como detecte un shell remoto, intente inyectar comandos para infectar el servidor usando derechos de administrador.

Evitar que Windows Terminal se ejecute como administrador no parece una mejora de seguridad en absoluto, ya que ejecutarlo como administrador protegería al usuario de procesos no elevados que secuestran sus sesiones remotas de shell. Ejecutarlo como administrador debe recomendarse al usuario cada vez que use una herramienta que le brinde un símbolo del sistema elevado, local o remotamente.

Y sobre sudo para Windows, ¿ejecutar el servicio sshd y luego conectarse a localhost desde un shell no elevado no presenta el mismo problema de seguridad?

Esto significa que Windows Terminal se convierte en un agujero de seguridad tan pronto como se usa para la administración, ya que un malware local podría esperar una sesión de Windows Terminal para espiar lo que está haciendo el usuario, y tan pronto como detecte un shell remoto, intente inyectar comandos para infectar el servidor usando derechos de administrador.

Si bien es cierto que el sistema remoto podría infectarse (suponiendo que el proceso remoto tenga derechos de administrador), eso no significa que también debamos dejar que infecte el sistema local.

Evitar que Windows Terminal se ejecute como administrador no parece una mejora de seguridad en absoluto, ya que ejecutarlo como administrador protegería al usuario de procesos no elevados que secuestran sus sesiones remotas de shell. Ejecutarlo como administrador debe recomendarse al usuario cada vez que use una herramienta que le brinde un símbolo del sistema elevado, local o remotamente.

Nada le impide ejecutar la Terminal de Windows con derechos de administrador en este momento. El problema en cuestión es tener pestañas mixtas elevadas y no elevadas.

@SamuelEnglard en la respuesta.

Para agregar, lo que estamos tratando de hacer es evitar agregar _nuevos_ agujeros de seguridad. La consola original tenía los mismos problemas con la administración remota del servidor. Lamentablemente, no podemos hacer nada al respecto. Los usuarios que realizan la administración remota del servidor siempre ejecutan sus consolas/terminales elevados, y eso les brindará algo de seguridad adicional (aunque no soy un experto en seguridad y no interpretaría esa afirmación como un consejo)

Idea para progresar en este problema: intente ejecutar toda la _aplicación como elevada y, si tiene éxito, agregue un botón junto a cada botón "abrir" con el ícono de un escudo UAC y agregue una combinación de teclas de prefijo para abrir una pestaña elevada: Ctrl Mayús E . (Lo verifiqué y esto no estaba vinculado). Solo funciona para la siguiente pestaña abierta.

De todos modos, las pestañas abiertas tienen un ícono de UAC antes de su ícono normal y se ejecutan como administrador. (Recuerde, los programas ya no pueden enviar estas claves. Ejecutamos la aplicación como administrador).

La aplicación debería intentar elevarse automáticamente y, si eso falla, ejecutarse normalmente e ignorar todo este hilo.

De hecho, estoy corregido.
Lo que _falta_ es la entrada "ejecutar como administrador" en el menú contextual de la barra de tareas.

En la barra de tareas, haga clic derecho dos veces. Una vez en el ícono para que aparezca el menú contextual, luego una segunda vez en el nombre de la aplicación. por ejemplo, "Terminal de Windows (vista previa)" y elija "Ejecutar como administrador"

Acabo de darme cuenta de que el aviso de UAC que se obtiene en ese caso dice "Programa desconocido".

Bastante inesperado si me preguntas...

@sba923 ese es el #2289 :sonrisa:

@DHowett-MSFT gracias por la información; Es bueno saber que (ya) está rastreado.

La mejor respuesta a esto que se me ocurre es tener la opción de tener un perfil que debe estar elevado y si la ventana actual no está elevada, iniciar una nueva instancia elevada con ese perfil. (Piense en cómo funcionan las sesiones de navegación privada)

Muy buena idea

Usé esta forma de agregar la Terminal en el menú Win+X:
Cree un nuevo acceso directo con el objetivo:
C:\Windows\explorer.exe shell:appsFolder\Microsoft.WindowsTerminal_xxxxxxxxxxxx!Aplicación
editar:
Lo sentimos, esto no funcionará si desea ejecutar la aplicación como administrador.
En su lugar, puede usar nircmd y crear un acceso directo con
cmd.exe /q /c nircmd elevate "shell:appsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App"

(La ruta correcta para "Microsoft.WindowsTerminal_xxxxxxxxxxxx" se puede encontrar con el comando PS "Get-appxpackage *WindowsTerminal*", use la entrada en PackageFamilyName)

Este acceso directo se puede utilizar para iniciar el terminal con privilegios de administrador con un simple doble clic y con WinXEditor se puede agregar en el menú Win+X.
Nota: El terminal también debe estar instalado en la cuenta de administrador.

¿La idea es cargar todos los perfiles como Administrador o solo algunos? Idealmente me gustaría tenerlo por perfil individual. ¿Tal vez una propiedad que es la cuenta "runas" y otra como "iselevated"?

Como se discutió extensamente en este hilo, no puede tener una combinación de elevado y no elevado en la misma instancia de Windows Terminal, y esto no se agregará.

De hecho, estoy corregido.
Lo que _falta_ es la entrada "ejecutar como administrador" en el menú contextual de la barra de tareas.

En la barra de tareas, haga clic derecho dos veces. Una vez en el ícono para que aparezca el menú contextual, luego una segunda vez en el nombre de la aplicación. por ejemplo, "Terminal de Windows (vista previa)" y elija "Ejecutar como administrador"

FWIW, acabo de probar shift-and-right-click, lo que da la opción "Ejecutar como administrador" de inmediato, solo un poco más rápido que la opción de dos clics derechos que anteriormente era mi opción.

Hola chicos, ¿olvidaron el UAC? La aplicación no puede hacer clic en las cosas en el escritorio seguro.

FWIW, acabo de probar shift-and-right-click, lo que da la opción "Ejecutar como administrador" de inmediato, solo un poco más rápido que la opción de dos clics derechos que anteriormente era mi opción.

También puede presionar Ctrl + Mayús + hacer clic con el botón izquierdo en el icono para que aparezca el UAC al instante.

Genial, muchas gracias! ¿Cuántos atajos tenemos que recordar? ;-)

Para su punto general sobre "ejecutar como un usuario diferente" que no existe/no funciona: esa es una limitación de la plataforma que estamos tratando de eliminar. No es por malicia o incompetencia que no lo apoyamos.

En cuanto a por qué otras aplicaciones de consola lo admiten, no es inseguro cuando lo hacen porque específicamente no alojan diferentes niveles de elevación en la misma ventana. Ese es el tema central aquí. Debido a que están alojados en procesos independientes con ventanas independientes, están libres de la restricción de la manipulación de niveles de integridad cruzada.

Definitivamente espero que correr como un usuario diferente sea algo que llegue en algún momento. Si bien no es la mayor parte de mi actividad diaria, algunos cmdlets de PowerShell requieren elevación (y ejecuto con diferentes usuarios, piense en un administrador de usuario protegido).

No es el fin del mundo, pero sin duda será molesto tener que volver a los shells heredados.

¡Con el tiempo, supongo!

No hay absolutamente ningún problema/limitación con el uso de Windows Terminal elevado, por lo que no es necesario seguir con los "shells heredados" (o para ser más exactos: con el host de la consola heredada).

Es solo que no puede mezclar elevados y no elevados en (diferentes pestañas dentro) de la misma instancia .

No hay absolutamente ningún problema/limitación con el uso de Windows Terminal elevado, por lo que no es necesario seguir con los "shells heredados" (o para ser más exactos: con el host de la consola heredada).

Es solo que no puede mezclar elevados y no elevados en (diferentes pestañas dentro) de la misma instancia .

Supongo que puedo haber malinterpretado lo anterior, pero hay una limitación de la plataforma al ejecutar la terminal en un contexto de usuario completamente diferente al que estoy leyendo.

Supongo que puedo haber malinterpretado lo anterior, pero hay una limitación de la plataforma al ejecutar la terminal en un contexto de usuario completamente diferente al que estoy leyendo.

Yah, este hilo ha estado por todas partes en ese punto. No soy un administrador en mis estaciones de trabajo, por lo que 'ejecutar como administrador' simplemente me pide que ingrese mis 'credenciales elevadas'.

Probablemente deberíamos simplemente tener un nuevo hilo sobre ese caso de uso.

Para ser claros, lo que quiero decir (y creo que muchos 'administradores' necesitan) es la capacidad de iniciar sesión en nuestra estación de trabajo como un usuario normal. Luego ejecute 'algún shell' como un usuario elevado como, por ejemplo, Administrador de dominio para hacer el trabajo de AD.

Bien o mal, eso es lo que algunos de nosotros hacemos y necesitamos. Todos los trucos sobre la instalación de la consola desde la tienda como ese usuario y la creación de atajos inteligentes realmente no me han funcionado.

Y sí, puedo hacer esto de varias maneras y tal vez debería restringir algunas de estas actividades a una estación de trabajo protegida, pero la realidad es que, como usuario normal, generalmente no necesito un shell.

En IMVHO, la confusión se debe al hecho de que las personas (mantienen los hábitos anteriores a Vista muriendo con fuerza) usan de manera más o menos intercambiable los términos "elevado" y "como otro usuario [de dominio] [administrador]".

Correr como otro usuario no es lo mismo que correr elevado.

1. Algunas de las personas en este hilo tienen la necesidad, cuando inician sesión como usuario administrador, de ejecutar cargas de trabajo de Windows Terminal con elevación.

2. Algunas otras personas tienen la necesidad, cuando inician sesión como un usuario normal (o no administrador de dominio), de ejecutar cargas de trabajo de Windows Terminal como otro usuario administrador, generalmente con elevación.

3. También se podría considerar el caso en el que las personas inician sesión como usuario normal A y desean ejecutar cargas de trabajo de Windows Terminal como usuario B sin elevación.

En los números 2 y 3, la implementación basada en la Tienda Windows hace que la historia sea más compleja, porque la Terminal de Windows no se ejecutará como el usuario que inició sesión, donde las "aplicaciones de la tienda" se implementan para ese usuario.

Espero entender la situación correctamente. Si lo hago, espero que esto aclare un poco el asunto.

Lo hiciste bien exactamente.

Solo para su información, ese problema exacto, incapaz de elevar ("Ejecutar como administrador", en lugar de ejecutar como otro usuario administrativo, "Ejecutar como usuario diferente") cuando la cuenta con la que inició sesión no es un administrador local en el sistema, según las mejores prácticas), se trató brevemente en otro número: https://github.com/microsoft/terminal/issues/1538 . Eso se cerró con una explicación de que se trata de un problema de Windows, no de la Terminal, ya que parece ser una limitación de las aplicaciones de la Tienda.

Sin entrar en un debate sobre si esto debería haberse lanzado como una instalación de MSI en lugar de usar la Tienda, hay una solución en ese hilo que he usado; inicie sesión brevemente como su cuenta de administrador, instale la aplicación desde la Tienda y luego vuelva a cerrar sesión. Ejecutar como administrador luego funcionó para mi cuenta de usuario normal (hasta la próxima actualización, cuando tendrá que volver a hacerlo).

Sí, debería haber un MSI disponible. Mi nuevo empleador no permite las instalaciones (públicas) de la tienda, por lo que la única forma en que podré usar Windows Terminal será compilar desde la fuente ...

Decepcionado al ver que no puede ejecutar Windows Terminal "como administrador" sin errores y luego tener que implementar una solución alternativa. Diría que muchas empresas implementan un enfoque de separación de privilegios para las identidades (con empleados de TIC que tienen una cuenta con privilegios y sin privilegios). Por lo tanto, ¿ser capaz de cumplir con este requisito al proporcionar una implementación de MSI opcional según la sugerencia de @sba923 sería un buen enfoque hasta que las aplicaciones empaquetadas en la tienda puedan hacer frente a la separación de privilegios?

Esta es una VISTA PREVIA, ni siquiera la versión 1.0...

Siento que este tema se ha discutido bastante bien en este momento, pero hay una perspectiva que aún no he entendido: ¿por qué no podemos crear un acceso directo de Windows a esta aplicación? Esa es la solución típica para "lanzar siempre como administrador": la solución típica es crear un acceso directo y cambiar el acceso directo para usar el acceso elevado de forma predeterminada.

¿Puede alguien explicarme por qué no podemos crear un acceso directo a esta aplicación? Esto probablemente esté más relacionado con el funcionamiento interno de Windows que con el funcionamiento interno de Terminal, pero siento que nos estamos andando por las ramas si no lo pregunto directamente.

Gracias.

Mantengo nircmd en mi carpeta c:\utils junto con muchas otras herramientas de uso común.
Agregué un perfil que se ve así:

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

Muestra una solicitud de elevación de UAC, luego abre una instancia de administración de Windows Terminal. Es una solución decente por el momento.

Estaría bien con la capacidad de etiquetar sesiones como Elevadas y abrirlas en una nueva ventana, sinceramente.

Vine aquí en busca de una buena solución, pero como no parece existir, compartiré mi solución hacky-ish. Agregué un perfil para ejecutar powershell elevado:

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

Aparece en una ventana separada pero hace el trabajo.

Siento que este tema se ha discutido bastante bien en este momento, pero hay una perspectiva que aún no he entendido: ¿por qué no podemos crear un acceso directo de Windows a esta aplicación? Esa es la solución típica para "lanzar siempre como administrador": la solución típica es crear un acceso directo y cambiar el acceso directo para usar el acceso elevado de forma predeterminada.

¿Puede alguien explicarme por qué no podemos crear un acceso directo a esta aplicación? Esto probablemente esté más relacionado con el funcionamiento interno de Windows que con el funcionamiento interno de Terminal, pero siento que nos estamos andando por las ramas si no lo pregunto directamente.

Gracias.

@aaronsteers , tiene razón en que se trata más de Windows que de Terminal. El problema principal aquí es que estamos distribuidos e instalados como un "paquete de aplicación moderno". Tienen una serie de restricciones y limitaciones accidentales en comparación con las aplicaciones nativas, pero es necesario para Terminal porque también es la forma menos difícil de usar componentes de la "API moderna de Windows" (WinRT). Es terriblemente frustrante para todos en el equipo casi todo el tiempo. :sonreír:

Estamos tratando de convertir esa frustración y la frustración de la comunidad en un avance para la plataforma. Me disculpo, sin embargo, ¡ese cambio no es rápido aquí en Windows!

@DHowett Realmente estoy tratando de entender, porque 2/3 me gusta Terminal, pero no está haciendo algunos conceptos básicos a los que estoy acostumbrado con TakeCommand o ConEmu, etc.

No puedo mezclar elevaciones en las distintas pestañas. Si entiendo, ¿es porque eres un tipo diferente de aplicación y realmente no estás alojando el shell?

El búfer de desplazamiento hacia atrás nunca se borra, en ninguno de los tres entornos (cmd, PowerShell, wsl bash). Lo hace en mis shells normales. Nuevamente, ¿por cómo está alojado?

Y sería bastante bueno tener un menú contextual o desplegable más accesible. Por ejemplo, para borrar ese desplazamiento hacia atrás, considerando que incluso el truco de escape de la consola no funcionó para mí.

La integración de los entornos y lo bien que capta los shells WSL de Linux es realmente agradable. Pero la usabilidad cuesta mucho debido a los problemas de elevación y desplazamiento hacia atrás, por lo que rara vez lo uso.

@robomac Hay una excelente publicación de @DHowett-MSFT aquí que explica por qué no podemos mezclar pestañas elevadas y no elevadas en la misma ventana no elevada.

El tl;dr es: si permitimos que los usuarios se conecten a líneas de comando elevadas desde una ventana de Terminal no elevada, eso crea un agujero de seguridad gigante, donde otras aplicaciones no elevadas podrían impulsar efectivamente el proceso elevado, a través de la ventana de Terminal.

No sé cómo ConEmu mitiga este riesgo, si es que lo hacen. Es muy posible que sea un agujero de seguridad que crea conemu y que no nos sentimos cómodos enviando como parte de la Terminal de Windows.

El resto de sus inquietudes son todos los problemas que se rastrean en otras partes de este repositorio, sugiero buscarlos para rastrear su progreso individualmente. Preferiríamos mantener este hilo en el tema único de "elevación mixta de pestañas"/"tener un perfil que se inicia elevado"

Sobre el tema: quiero experimentar con la ruta "lanzar otra instancia elevada" para perfiles "elevados". Si la experiencia del usuario no es tan mala, entonces esa es una posible ruta hacia adelante aquí, al menos como una opción.

ConEmu no mitiga este riesgo. Pasan ese riesgo a sus usuarios. (Ni siquiera estoy seguro de que estén documentando este riesgo).

Sobre el tema "lanzar otra instancia elevada": no me importaría este comportamiento siempre que pueda usar la misma instancia elevada de Terminal para estas pestañas y no lanzar una nueva instancia cada vez que invoco un perfil "elevado".

En mi opinión, el "gigantismo" de ese agujero de seguridad es un poco exagerado. No es normal tener un malware en la computadora que se sienta y espera la oportunidad de elevarse, por lo que sacrificar la comodidad por la seguridad no se siente bien.

Por otro lado, si el objetivo final es que WT se envíe con Windows como terminal predeterminado, eso aumentaría drásticamente la superficie de ataque. Pero nuevamente, en este caso, personalmente mitigaría el riesgo usando una alternativa impopular que probablemente no sea un objetivo para tal ataque y brinde la conveniencia requerida (suponiendo que detectar la presencia de una pestaña elevada en una terminal no sea lo suficientemente trivial). para ser específico del terminal).

Algo de esto es tl; dr para mí, pero si toma y descarga el paquete, puede ejecutar wt fuera del sandboxing, lo que significa elevación, y ejecutar como un usuario diferente funciona sin problemas. Hablé con MSFT en ignite sobre esto y me dijeron que enviara una solicitud de extracción, pero mis habilidades de VS son bastante débiles. Lo que sería bastante fácil de hacer es firmarlo correctamente (tuve que hacerlo con mi propio pki interno para poder ejecutarlo en applocker) y ponerlo en un formato distribuible MSI o MSIX. Hay un error extraño aquí o allá que puede ser específico para ejecutarlo de esta manera, pero en general funciona muy bien. Por ahora, solo tengo una función para extraer, firmar y reemplazar/actualizar una versión basada en archivos de programa desde la versión basada en la tienda.

Entiendo el riesgo de esa característica de "conectar" pestañas elevadas en un proceso no elevado, pero ¿no es posible ir al revés?
Significado para las personas, ¿cómo necesitan esto, dejar que la Terminal en sí también se ejecute como Elevada y permita iniciar Pestañas no elevadas?
Por supuesto, eso tiene otras desventajas, pero para mí (y creo que para otros también) son aceptables.
(claro, eso podría ser "interesante" ya que la terminal es una aplicación de la tienda de Windows, no estoy seguro de si eso funciona)

PD. Perdón por reabrir este problema (también si otra persona ya hizo esa sugerencia y "leí" eso).

Gracias a @EmTschi , hice una solución simple y 100% conveniente
Utiliza el menú contextual y actúa de la misma manera que lo hace PowerShell 7
https://github.com/nt4f04uNd/wt-contextmenu
Allí puede encontrar una guía sobre cómo implementarlo y todos los archivos necesarios.

Gracias por el consejo, lo probaré más tarde.
Actualmente estoy trabajando con dos accesos directos en mi escritorio, que están asignados a las teclas Ctrl+Alt+T y Ctrl+Alt+Shift+T para una terminal elevada, también está bien como solución alternativa, pero... no tan bueno como podría ser y millas de distancia de algo como sudo.

@

Cada vez que intento ejecutar la aplicación Terminal con una cuenta de administrador, haga clic derecho -> ejecutar como administrador, el UAC aparece dos veces y aparece un error que dice:
"Windows no puede encontrar (ruta\WindowsTerminal.exe) Asegúrese de haber escrito...".
La ruta existe y la aplicación funciona correctamente para el usuario no administrador que creó la aplicación, pero el otro usuario administrador no puede ejecutarla.
Si inicio sesión con el usuario administrador, la aplicación de terminal no está presente ni en la configuración ni en el menú de inicio, como si nunca se hubiera instalado en el sistema.
¿Hay alguna manera de compilar la aplicación para que se instale para todos los usuarios? ¿O la raíz del proyecto tiene que estar en un directorio no específico del usuario?

Estoy viendo el mismo problema sucediendo también.

Versión de Windows 18922.1000

Acabo de instalar en Win10 actualización 1909, y tengo el mismo problema al intentar ejecutar como Administrador

El mismo problema aqui. No puedo usar la terminal de Windows ahora porque siempre necesito ejecutar la ventana acoplable y luego siempre necesito ser administrador en la terminal ...

Tengo una solución hack-around para cualquiera que la quiera:

1. descargue msixbundle desde la página de lanzamiento
2. descomprima eso, allí, encuentre el msix que es para su plataforma (típicamente el x64)
3. descomprimir eso en una carpeta en algún lugar
4. copie esa carpeta donde quiera y ejecute WindowsTerminal.exe elevado o como quiera

Gran parte de esta falla parece provenir de la conveniencia de tener esto como una aplicación de tienda. Hay una discusión sobre esto en el n.° 1386 y alguien mencionó que tal vez se instale con Scoop, que automatiza el proceso de extracción anterior.

Sería bueno que los siguientes fueran tratados como ciudadanos de primera clase:

1. Instalaciones portátiles (archivos zip, incluso si la configuración aún no es portátil, ya que se encuentra en AppData\Local cuando se ejecuta fuera del área de instalación de la tienda de Windows)
2. Un instalador .exe normal antiguo (o, si es necesario, .msi) para las personas que no quieren la Tienda o no usan el Instalador de la Tienda

Ambos no son tan difíciles de implementar desde el procedimiento de compilación actual, como lo demuestra la automatización de Scoop. Y ahora que Windows Terminal se está volviendo bastante bueno, me gustaría poder usarlo como cualquier otro terminal.

Mientras estamos en eso: a menos que haya incompatibilidades de API, sería genial tener la opción de instalar Windows Terminal sin la Tienda (incluso la forma "portátil") en versiones anteriores de Windows 10 (mi empleador nos bloquea en 1809/ RS5 y la instalación desde la Tienda está bloqueada).

@ sba923 si no confiáramos en las API que solo existen en 1903, no necesitaríamos 1903.

Claro... fue mi suposición 😜

Tendrá que cabildear para que se actualice en toda la empresa, probablemente chocará contra un muro...

Esto es tan estupido.

Hagamos un nuevo terminal unificado para símbolo del sistema, powershell y bash para Windows.
¿Puedo ejecutar cmd.exe como administrador?
No.

Supongo que mantendré mis íconos cmd.exe y powershell preestablecidos para ejecutarse como administrador en mi barra de tareas indefinidamente entonces.

Cosas tontas como esta es la razón por la que mi principal máquina de trabajo sigue siendo una Macbook.

Esto es tan estupido.

Hagamos un nuevo terminal unificado para símbolo del sistema, powershell y bash para Windows.
¿Puedo ejecutar cmd.exe como administrador?
No.

Supongo que mantendré mis íconos cmd.exe y powershell preestablecidos para ejecutarse como administrador en mi barra de tareas indefinidamente entonces.

Cosas tontas como esta es la razón por la que mi principal máquina de trabajo sigue siendo una Macbook.

Estoy de acuerdo en este caso. Quiero una sola ventana de Terminal de Windows que contenga todas las pestañas de terminal que necesito, donde cada pestaña de terminal pueda ser uno de los múltiples hosts de terminal instalados, y estar elevada o no.

Realmente parece que esta característica de elevación mixta está siendo frenada por la decisión de diseño técnico de alojar todas las pestañas en un solo identificador HWND.

1) ¿Puede ejecutar la nueva terminal como administrador? SÍ (Hay problemas para hacerlo dependiendo de cómo lo instaló/ejecutó, pero no hay ningún deseo de que esto no funcione). (Si no sabe cómo hacer esto, vea varias publicaciones anteriores sobre cómo hacerlo).

2) ¿Puedes tener una pestaña elevada y otra no? no Consulte https://github.com/microsoft/terminal/issues/632#issuecomment -519375707 para saber por qué.

¿Pueden las personas recordar que este problema se trata de pestañas de elevación mixta? Si desea iniciar todo el proceso elevado y no puede, abra un nuevo problema.

@DHowett-MSFT ¿Podríamos cambiar el nombre de este problema para que se trate de pestañas de elevación mixta?

Independientemente de cómo se maneje esto o no, las terminales o pestañas elevadas deberían tener algún tipo de indicador. Ahora, si inicio una nueva terminal con Ejecutar como administrador, no hay forma de notar fácilmente que mis pestañas de cmd tienen un acceso elevado en comparación con las de la siguiente ventana.

EDITAR después del comentario de @SamuelEnglard : Obviamente, elegí apresuradamente cmd como un mal ejemplo. Sí, cmd muestra 'Administrador:' en el título de la pestaña. Pero WSL Ubuntu bash en mi pestaña predeterminada sobrescribe lo que pueda haber en el título de la pestaña. Supongo que bash no sabe (ni siquiera le importa) la elevación de Windows Terminal, por lo que esa información no se puede usar al actualizar el título desde bash (por supuesto, hay sudo situación, pero eso es otra cosa).

En el profiles.json de la Terminal, hay
"showTabsInTitlebar": false
pero con esta configuración, la barra de título de la Terminal no indica la elevación.

@janilahti hace que las pestañas CMD elevadas no se vean como
¿para ti?

La seguridad es un punto discutible si nadie quiere usar su herramienta...

Todos deberían hacer un comando sudo para Windows que funcione tanto en cmd.exe como en powershell. Eso me ahorraría la molestia de tener un acceso directo para que ambos se ejecuten como administrador.

Para su información, escribí un sudo for windows , llamado gsudo : https://github.com/gerardog/gsudo

Admite elevar los comandos cmd / powershell / pwsh o todo el shell. Es fácil de instalar y usar y debería parecerse al *nix sudo original. Hay otras implementaciones de sudo en la naturaleza, pero en mi humilde opinión, gsudo es la más versátil y fácil de usar.

Puede usarlo, por ejemplo, para crear un perfil WT que llame a gsudo cmd / gsudo pwsh o gsudo WhateverShell para iniciar pestañas elevadas. Instale gsudo y agregue un perfil WT:

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

Es una aplicación cliente-servidor de C# que actúa como un cliente cuando no está elevado y se inicia como un servidor elevado. Ambas instancias se comunican a través de canalizaciones con nombre seguras. Otros sudos de Windows en la naturaleza son en su mayoría como secuencias de comandos 'runas' de PowerShell que abren una nueva ventana, pero ser una aplicación completa me permitió agregar muchas más funciones.

He leído el hilo y se ha discutido la seguridad de un comando sudo y se han hecho algunos puntos válidos. He tomado todas las medidas de seguridad que se me ocurrieron y estoy abierto (y planeando) introducir más de ellas. En este punto, debería ser tan seguro/inseguro como si abriera una sesión de PS de administración remota o si hiciera ssh root@server desde una consola no elevada. (por ejemplo, vulnerable a las pulsaciones de teclas o al desguace de pantalla, y corríjame si me equivoco, pero entiendo que * nix sudo también es vulnerable de esta manera). También está el caché de credenciales, que reduce la cantidad de ventanas emergentes de UAC durante una sesión de 5 minutos (inspirado en * nix sudo), que claramente es un vector de ataque, que se puede desactivar a través de la configuración. Para aquellos preocupados por la seguridad, planeo agregar una manera muy fácil de reforzarla (al deshabilitar funciones como el caché de credenciales) con un comando simple o mediante una configuración de registro/política de grupo empresarial.

Un punto interesante de este comentario es que Microsoft no puede darse el lujo de "aceptar el riesgo por conveniencia del usuario". Si esa es la última palabra de MS, al menos parece una solución decente (totalmente funcional), y todos los comentarios/ problemas o ideas sobre cómo mejorar la seguridad son bienvenidos.

No puede ser algo que tenga que instalar que no sea compatible oficialmente. Mata cualquier capacidad de usarlo en un entorno corporativo.

Entonces @hparadiz tendría que esperar hasta que salga una nueva versión de windows con un nuevo diseño de seguridad que permita un sudo oficial (o pestañas de elevaciones mixtas) sin riesgos de seguridad. Parece que no sucederá pronto. Lo mejor que puede hacer es esperar hasta que todo el WT se pueda lanzar como administrador, rastreado en el n.º 4217, y es probable que se lance antes.

Encontré un buen truco de un blog:

http://nuts4.net/post/windows-terminal-ejecutar-como-administrador

@gerardog , ¿tiene un balde de cucharadas por gsudo ? o es en uno de los conocidos? Actualmente estoy en una caja de Linux, así que no puedo verificar.

@fluffynuts Está en el repositorio principal de Scoop. Así que simplemente 'instalar gsudo'. También se enumeran otros métodos de instalación en https://github.com/gerardog/gsudo . Pero mantengamos esta discusión sobre el tema WT. 😉

Pregunta abierta: si es un riesgo de seguridad mezclar pestañas elevadas y no elevadas, ¿ese riesgo está presente en ConEmu ? Porque puede hacer exactamente eso. ¿O ConEmu está implementando esa función de una manera diferente a como lo haría en Terminal? Y, en términos más generales, señalaría que muchas de las funciones que se solicitan aquí (en este hilo y en otros) ya existen en otras terminales, siendo ConEmu solo un ejemplo, por lo que cuando los desarrolladores de terminales sugieren que estas funciones nunca se implementarán o no se implementarán para durante mucho tiempo, implícitamente solo está confirmando que no deberíamos usar Terminal.

si no confiáramos en las API que solo existen en 1903, no necesitaríamos 1903.

@DHowett-MSFT ¿Hay alguna documentación pública disponible sobre qué API son y por qué son necesarias? Porque como observador externo, cuando veo esta decisión y la decisión de usar UWP, no veo el valor agregado. Solo veo obstáculos para agregar lo que muchos usuarios empresariales consideran una funcionalidad básica.

@dadpolice Consulte https://github.com/microsoft/terminal/issues/632#issuecomment -518888895 para conocer lo que hace ComEmu.

Pensé que "UAC no es una barrera de seguridad" según Microsoft. Fue tratado como uno en Vista. Luego nos dijeron que no era uno y que cualquier problema como este era una broma en Windows 7. ¿Ahora es uno nuevamente hoy?

Tal vez necesite revisar el diseño del Explorador de archivos y la lista blanca de UAC en este caso. :)

¿O simplemente depende de si es o no una excusa para tomar un atajo al diseñar algo que los desarrolladores normales no pueden hacer (Explorador de archivos) o no implementar una característica esencial (en este caso)?

no implementar una característica esencial (en este caso)?

Quiero dejarlo claro: no estamos tratando de _no_ implementar esta función. Ciertamente es una característica importante que _queremos_ implementar. Es algo con lo que me encuentro a diario en este momento: tener una segunda ventana elevada está _bien_ pero no es _bueno_.

Solo nos tomará un tiempo poder diseñar una solución apropiadamente segura y luego hacer el esfuerzo de ingeniería para implementarla realmente. Es algo que planeamos por un tiempo incluso esta semana.

@zadjii-msft

[...]
No creo que planeemos admitir pestañas mixtas elevadas y no elevadas, porque es un pequeño agujero de seguridad.
[...]

(como cuestión de enlazar hilos relacionados, #146)

Es extraño que la gente tuviera la impresión de que la función no se implementará. signo de sarcasmo

@kort3x Hay una diferencia entre "Sin plan" (es decir, no lo prometemos) y no querer y hacer lo que pueden hacer para encontrar la manera de implementarlo.

Como dijo @zadjii-msft:

Solo nos tomará un tiempo poder diseñar una solución apropiadamente segura y luego hacer el esfuerzo de ingeniería para implementarla realmente. Es algo que planeamos por un tiempo incluso esta semana.

Mientras no tengan una solución segura, no planearán (también conocido como promesa) admitir pestañas de elevación mixta. Sin embargo, estoy dispuesto a aceptar que en el momento en que tengan una solución segura, la agregarán al plan (aunque no puedo prometer nada).

Pensé que "UAC no es una barrera de seguridad" según Microsoft. Fue tratado como uno en Vista. Luego nos dijeron que no era uno y que cualquier problema como este era una broma en Windows 7. ¿Ahora es uno nuevamente hoy?

Según tengo entendido es una barrera de seguridad si está configurado como "Notificar siempre", de lo contrario no lo es.

Bueno, esto es decepcionante. Me gusta la terminal (que dice mucho, ya que estoy bastante enamorado de las herramientas que no son de MS en general), pero la incapacidad de elevar sin problemas es una barrera real para mí para trabajar más en este sistema operativo.

LOL está bien, sí, puedo ver cómo eso es confuso. Originalmente escribí ese comentario días después de que lo anunciáramos por primera vez, cuando no había un plan. Después de algunos meses de discusión, ciertamente he llegado a la idea de que esto podría ser posible, con más esfuerzo. Iré a actualizar el comentario para reflejar eso. Sin embargo, @SamuelEnglard tiene razón, es difícil _comprometerse_ a hacer esto hasta que _sabemos_ que es posible hacerlo correctamente.

Es alentador escuchar esto. ¿Es posible extender este entusiasmo a otros equipos, de modo que el #3581 pueda arreglarse?

Sería bueno si se permitiera que las pestañas fueran procesos diferentes (similares a cómo lo administra Chrome) en primer lugar porque entonces no tendría que reiniciar todas las pestañas después de agruparlas bien solo para obtener un entorno actualizado en un solo pestaña cmd...
Una vez que la Terminal de Windows es solo un administrador, podría ejecutarse en un modo no elevado mientras mantiene las indicaciones de comando elevadas. Eso estaría bien. (bueno, tener el wt elevado mientras sostengo terminales no elevados también estaría bien para mí)

@ rapus95 técnicamente son las pestañas, en el sentido de que la "consola" es un proceso diferente. Windows Terminal ya es solo un administrador

EDITAR (14 de febrero de 2020)
Vale, entonces este comentario no envejeció muy bien. Originalmente, no había ningún plan para respaldar esto, ya que no funcionaría con el único HWND que teníamos. Estamos trabajando en el diseño de una solución que _podría_ respaldar esto en el futuro, pero no podemos comprometernos con nada hasta que estemos seguros de que podemos encontrar una solución apropiadamente segura, que asegure que un proceso con menos privilegios no pueda conducir una terminal de mayor privilegio.

Aparte de algunos otros puntos, esa es la razón principal por la que sigo usando ConEmu . Y apuesto a que alguna vez lo haré.
https://conemu.github.io/ @Maximus5

Esto es tan estupido.

Hagamos un nuevo terminal unificado para símbolo del sistema, powershell y bash para Windows.
¿Puedo ejecutar cmd.exe como administrador?
No.

Cosas tontas como esta es la razón por la que mi principal máquina de trabajo sigue siendo una Macbook.

@hparadiz Eche un vistazo a ConEmu :-D No hay problemas para ejecutar varios Shells como pestañas en UNA ventana; incluso ejecutando sesiones elevadas de Powershell y cmd.exe aparte de las no elevadas.

@tmeckel , ¿estamos seguros de que conemu no tiene las vulnerabilidades de seguridad que preocupan al equipo de la terminal? los usuarios a menudo eligen software menos seguro porque hace lo que quieren, pero bajo su propio riesgo.

@drdamour @tmeckel Lo hace. Hice la misma pregunta anterior, se responde en otro hilo: https://github.com/microsoft/terminal/issues/632#issuecomment -518888895

He sido bastante crítico con Terminal hasta ahora, pero para ser justos, ConEmu, ConsoleZ y otras herramientas similares ya existen. Microsoft tiene poco valor si simplemente las copia, pero tiene un gran valor recrear esas características de una manera segura. Dicho esto, sigo pensando que es muy tonto crear un emulador de terminal como una aplicación para UWP solo en la tienda, especialmente ahora que Microsoft parece estar alejándose de UWP (por ejemplo, el nuevo Edge es una aplicación Win32).

Dicho esto, sigo pensando que es muy tonto crear un emulador de terminal como una aplicación para UWP solo en la tienda, especialmente ahora que Microsoft parece estar alejándose de UWP (por ejemplo, el nuevo Edge es una aplicación Win32).

Para ser claros, la Terminal no es solo de tienda ( hay .msix disponibles aquí ), ni es una aplicación UWP. Es una aplicación Win32 que utiliza UWP XAML como marco de interfaz de usuario.

@ rapus95 técnicamente son las pestañas, en el sentido de que la "consola" es un proceso diferente. Windows Terminal ya es solo un administrador

Bueno, entonces, ¿por qué el entorno no está actualizado para una nueva instancia de cmd? Siempre necesito abrir una nueva Terminal de Windows que, en cierto sentido, reduce la usabilidad general de tener varias pestañas...

@ rapus95 aunque no estoy seguro (tendría que investigar el código), estoy bastante seguro de que cada subproceso se inicia con el entorno de su padre, no con uno nuevo.

eso no parece tener sentido para un administrador de terminal 🤔

@rapus95 En realidad es un error que estamos rastreando aquí: #1125

Para ser claros, la Terminal no es solo de tienda ( hay .msix disponibles aquí ), ni es una aplicación UWP. Es una aplicación Win32 que utiliza UWP XAML como marco de interfaz de usuario.

Eso suena como UWP con pasos adicionales. Sea lo que sea lo que hace que no pueda hacer clic con el botón derecho en Terminal y ejecutarlo como un usuario diferente, como puedo hacerlo con cualquier aplicación Win32 normal, esa fue una elección extraña.

No es una aplicación para UWP ni una aplicación solo para tiendas.
Simplemente sucede que uno de los métodos de distribución es la Tienda, que requiere un paquete UWP.
Solo aquellos que lo instalaron usando la tienda no pueden Right click -> Run As Admin .
Desinstale y use el msix o vía primicia

Desinstale y use el msix o vía primicia

O chocolatey .

@gerardog No dije ejecutar como administrador, dije ejecutar como usuario diferente.

¿No te funciona Shift + Right Click ?

(Tenga en cuenta que he instalado usando scoop )

No. Lo instalé usando el paquete msix y esa opción no está allí.

Lo instalé como chocolatey y tampoco lo he ejecutado como administrador.

Para ser claros, la Terminal no es solo de tienda ( hay .msix disponibles aquí ), ni es una aplicación UWP. Es una aplicación Win32 que utiliza UWP XAML como marco de interfaz de usuario.

Eso suena como UWP con pasos adicionales. Sea lo que sea lo que hace que no pueda hacer clic con el botón derecho en Terminal y ejecutarlo como un usuario diferente, como puedo hacerlo con cualquier aplicación Win32 normal, esa fue una elección extraña.

Lo mismo aquí, probé msix y la aplicación de la tienda. Todavía no tengo la opción "Ejecutar como otro usuario".

¿Qué hay de hacer que el fondo de todas las pestañas elevadas sea de color rojo para que sea obvio que está elevado?

Prefiero tener esto configurable: color de fondo, título de pestaña...

https://github.com/gerardog/gsudo funciona muy bien como una solución temporal

Tal vez implemente algo como wt elevated que abra una nueva ventana elevada con el shell actual con el mismo entorno.
EDITAR: o # 3158 pero como nueva ventana y elevada

No entiendo por qué no copiarías la forma en que lo hace Linux.

A mi entender o el mundo de Linux (corríjame si me equivoco), las aplicaciones de terminal (gnome-terminal, mate-terminal...) no necesitan ser elevadas incluso si escribe su o sudo y ejecuta el comando como el usuario raíz. La única misión de la aplicación de terminal es ejecutar un shell en un proceso diferente (bash, ksh...) que esté o no elevado, y redirigir la entrada y salida del shell para que podamos interactuar con el shell.

Si escribe "su" o comienza un comando con "sudo" en una terminal de Linux, no se abre una ventana diferente.

@gabsoftware No estoy seguro de la seguridad de esto incluso en Linux. También es posible enviar pulsaciones de teclas a X windows en Linux, y supongo que es posible enviar pulsaciones de teclas a clientes de terminal que se ejecutan en una ventana X, incluso si la terminal en ejecución está elevada con sudo o su. Incluso puede ser posible enviar pulsaciones de teclas a ventanas X elevadas, pero realmente no estoy seguro.

Para ser claros, la Terminal no es solo de tienda ( hay .msix disponibles aquí ), ni es una aplicación UWP. Es una aplicación Win32 que utiliza UWP XAML como marco de interfaz de usuario.

Eso suena como UWP con pasos adicionales. Sea lo que sea lo que hace que no pueda hacer clic con el botón derecho en Terminal y ejecutarlo como un usuario diferente, como puedo hacerlo con cualquier aplicación Win32 normal, esa fue una elección extraña.

Lo mismo aquí, probé msix y la aplicación de la tienda. Todavía no tengo la opción "Ejecutar como otro usuario".

No puedo "Ejecutar como un usuario diferente" presionando Mayús y haciendo clic con el botón derecho en el mosaico en el menú de inicio, pero puedo si hago Mayús y haciendo clic con el botón derecho en WindowsTerminal.exe

@gabsoftware No estoy seguro de la seguridad de esto incluso en Linux. También es posible enviar pulsaciones de teclas a X windows en Linux, y supongo que es posible enviar pulsaciones de teclas a clientes de terminal que se ejecutan en una ventana X, incluso si la terminal en ejecución está elevada con sudo o su. Incluso puede ser posible enviar pulsaciones de teclas a ventanas X elevadas, pero realmente no estoy seguro.

He hecho algunos experimentos y ahora estoy bastante seguro de la inseguridad de esto en Linux. No soy un experto en seguridad, así que no estoy seguro de las implicaciones de esto (¿alguien?). Resulta que es muy fácil enviar pulsaciones de teclas a X windows que acaban de ejecutar sudo y están abiertos a nuevos comandos sudo sin pedir una contraseña. Publicación de blog aquí , perdón por el enchufe vergonzoso ...

Mi conclusión sería que, a menos que haya una forma de no permitir el envío de pulsaciones de teclas a ventanas de elevación mixta, esto solo debería implementarse como una opción para los usuarios dispuestos a aceptar el riesgo (grandes señales de advertencia, etc.).

Como nota al margen, ¿cómo envía el teclado en pantalla de Windows las pulsaciones de teclas a las ventanas elevadas?

Lancé gsudo v0.7 y es relevante para este hilo:

EDITAR: Para contexto: gsudo es un sudo para Windows y permite elevar un comando simple o un shell en la consola actual. Cuando se invoca desde Cmd/Pwsh dentro de WT, eleva la pestaña. Además, puede editar su perfil, nombrarlo 'Powershell elevado' y cambiar su comando a gsudo Powershell y listo, tiene un perfil de pestaña elevado. Ver aquí

Pero dado que gsudo, o cualquier sudo para Windows, salta el aislamiento de UAC, se ha etiquetado como 'inseguro'. Lo que sigue es una solución alternativa más complicada que le permite hacer elevaciones mixtas de pestañas mientras mantiene la seguridad. /FIN EDITAR

gsudo ahora puede iniciar aplicaciones con cualquier nivel de integridad. Por ejemplo, podemos lanzar Windows Terminal con el nivel de integridad MediumPlus , lo que significa un modo 'semielevado': sin derechos de administrador pero aislado, inalcanzable desde otros procesos regulares (integridad media). (aparecerá una ventana emergente de UAC)

Entonces, el primer paso debe ser lanzar siempre WT con: gsudo -i MediumPlus WT
(Puede cambiar su atajo de WT). Esto protege a WT de procesos maliciosos, eliminación de pantalla, claves de envío, inyección de dll, etc.
(EDITAR: si no funciona, use: gsudo -n -i MediumPlus cmd /c cmd /c start wt )

Luego puede usar gsudo forma segura dentro de WT para elevar comandos, o incluso crear un perfil elevado con: "commandline": "gsudo cmd.exe" en profiles.json

Mi conclusión sería que, a menos que haya una forma de no permitir el envío de pulsaciones de teclas a ventanas de elevación mixta... esto solo debería implementarse como una opción para los usuarios dispuestos a aceptar el riesgo (grandes señales de advertencia, etc.).

Hecho y hecho. (He agregado advertencias de seguridad a gsudo).

Además, desde que aprendí que si el usuario está invocando a gsudo desde un proceso de integridad regular/medio , entonces el caché de credenciales de gsudo (la función para mostrar menos ventanas emergentes de UAC) nunca puede estar completamente protegido... Entonces, ahora las credenciales el caché debe habilitarse explícitamente a través gsudo cache on/off o gsudo config cachemode auto .

Resulta que "Changing your WT shortcut" no es trivial en absoluto: Dado el modelo de MSIX/AppStore, se encontró con #4217 y #4459.

El siguiente script de PowerShell soluciona esos problemas para crear un acceso directo de Terminal de Windows en el escritorio y lo asocia con la tecla de acceso rápido Ctrl+Alt+T:

$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()

Una vez que haya iniciado WT como MediumPlus (es decir, Ctrl+Alt+T), puede usar gsudo como se mencionó [anteriormente] (https://github.com/microsoft/terminal/issues/632#issuecomment-613751789) para elevar los comandos en lo que AFAIK debería estar seguro.

Mi solución a esto es usar _Sudo para Windows_ de Luke Samson . La configuración del perfil es:
"commandline": "pwsh.exe -Command sudo.ps1 pwsh.exe",
Al iniciar una nueva pestaña con ese perfil, aparece UAC y luego termina en un Powershell Core elevado. También funciona con cualquier otro terminal.
"commandline": "powershell.exe -Command sudo.ps1 powershell.exe",
"commandline": "powershell.exe -Command sudo.ps1 cmd.exe",
Si no usa scoop , estoy seguro de que el concepto se puede extraer y usar de forma independiente. Consulte el código fuente aquí: https://github.com/lukesampson/psutils/blob/master/sudo.ps1

Estoy usando la solución schtasks para ejecutar Windows Terminal como administrador y omitir UAC:

1. Inicie el Programador de tareas.
2. Crear una nueva tarea. Asígnele un nombre y marque la casilla de verificación "Ejecutar con los privilegios más altos".
   

3. En la pestaña Acciones, seleccione para iniciar un programa: wt

4. En la pestaña Configuración, asegúrese de que "Permitir que la tarea se ejecute bajo demanda" esté marcada y desactive la casilla de verificación "Detener la tarea si se ejecuta durante más de".

5. Cree un acceso directo haciendo clic derecho en el Escritorio y seleccione Nuevo -> Acceso directo y escriba schtasks.exe /run /TN "{task name}"
   
6. Si lo desea, cambie el icono de acceso directo y arrástrelo a la barra de tareas.

Parece que tendré que ceñirme a cmder hasta que esto se solucione.

Ahora que supuestamente hay un atisbo de un plan, ¿podemos obtener los documentos?
actualizado para que ya no diga que no hay un plan actual?

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

@drdamour Una vez que haya un plan, me encantaría eliminar esa sección. En este momento, sin embargo, solo hay un plan para investigar una forma de hacer un plan. Una vez que haya un plan real y una forma segura de hacerlo, eliminaré esa sección.

El método descrito por @KMoraz funciona muy bien como solución por ahora. Gracias por publicar esto.

Hola gente,

Estaba usando ConsoleZ hasta que descubrí este ayer.
ConsoleZ tiene algunas características y una es iniciar una nueva pestaña como administrador usando UAC (abre el cuadro de diálogo de UAC).
Lo encuentro muy útil porque no necesitas quitar las manos del teclado para abrir una nueva pestaña elevada.

¿Y si fuera una configuración dentro de la configuración del perfil? Así es como se hace en ConsoleZ.

Hola a todos,

Encontré otra solución de acceso directo que es simple y funciona muy bien para aquellos que tienen que ingresar las credenciales de administrador local cuando ejecutan algo como administrador.

Este enlace explica, pero necesita una ruta completa para la referencia wt.exe:
http://nuts4.net/post/windows-terminal-ejecutar-como-administrador

Mi cadena de acceso directo completa es: C:\Windows\System32\cmd.exe /c start /b C:\Users\myUserName\AppData\Local\Microsoft\WindowsApps\wt.exe

ACTUALIZACIÓN 21 de mayo de 2020:
Lo anterior solía funcionar antes de la versión 1.0.1401.0.

Vea también este nuevo número: https://github.com/microsoft/terminal/issues/6013

Ahora, el clic de Crtl-Shift tampoco funciona cuando tiene que elevar con una cuenta de administrador local.

Vea la siguiente captura de pantalla de error que recibo después de que se me soliciten dos veces los permisos de elevación:

Para obtener información, imho gsudo es perfecto para esto, gracias https://github.com/microsoft/terminal/issues/632#issuecomment -613751789

Mi configuración solo tiene este perfil para obtener privilegios:

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

Para mí, la forma más fácil de abrir Windows Terminal como administrador es anclarlo como el primer elemento en la barra de tareas. Luego Win+Ctrl+Shift+1 lo abre como administrador

Para mí, la forma más fácil de abrir Windows Terminal como administrador es anclarlo como el primer elemento en la barra de tareas. Luego Win+Ctrl+Shift+1 lo abre como administrador

De hecho, es muy conveniente, pero esto solo funciona para las cuentas que son miembros del grupo Administradores.

Si actúa como administrador de otra persona, no podrá ejecutar Windows Terminal como su usuario (administrador) desde su cuenta.

Creo que sería bueno tener una configuración de pestaña para ejecutar cmd como administrador, no todo.

Creo que sería bueno tener una configuración de pestaña para ejecutar cmd como administrador, no todo.

Como se explica en otra parte aquí, esto no es posible con el diseño actual.

¿Hay una bandera que se puede usar para ejecutar como administrador? Entonces podríamos simplemente crear un atajo para ello.

Si ancla Windows Terminal a la barra de tareas, puede iniciarlo _elevado_ usando Ctrl+Shift+clic.

Esto hará lo mismo que hacer clic con el botón derecho en el icono, hacer clic con el botón derecho en "Terminal de Windows", seguido de "Ejecutar como administrador".

Nota: Al ser Windows Terminal una aplicación de la Tienda, no puede ejecutarla como _otro usuario_.

Me encantaría ver la capacidad de tener "pestañas de nivel de integridad mixtas" en Windows Terminal, con el nivel de integridad como una opción en cada perfil. Esto es principalmente como una conveniencia en mi trabajo normal de administrador de sistemas/devops para minimizar las interrupciones del flujo de trabajo y el cambio de contexto.

He encontrado una alternativa simple que funciona para mí por ahora. Esto no aborda todos los escenarios presentados aquí por otros usuarios. No depende de aplicaciones de terceros, archivos de acceso directo, combinaciones de teclas o tareas programadas. No requiere identificar la ubicación del ejecutable de Windows Terminal. Simplemente hace una entrada separada en la lista de perfiles de Terminal de Windows que inicia una segunda instancia elevada de Terminal de Windows. Esto desencadena una solicitud de UAC una vez. Solo uso esto si y cuando necesito elevación.

El resultado son dos terminales de Windows. Cualquier cosa en uno es estándar y cualquier cosa en el otro es elevada. Para mí, este es un nivel aceptable de interrupción y cambio de contexto. La Terminal de Windows elevada también antepone el título de cada pestaña con "Administrador:", lo que brinda una buena confirmación visual de la diferencia.

Editar: tengo Powershell 7 instalado,

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

@IarwainBen-adar, creo recordar haber leído recientemente en los nuevos documentos que no puede usar el elemento commandline y el elemento source juntos. ¿Funciona como se esperaba sin el elemento source ?

Probé su código y ni siquiera puedo hacer que el nuevo elemento aparezca en el pull
menú inferior.

@shem-sargent lo siento, eliminé mi comentario aquí porque la declaración extraña source era de hecho el problema. Aunque, ahora que tengo la entrada del menú funcionando, lamentablemente todavía no puedo iniciar una instancia elevada de Windows Terminal: me encuentro con el problema n.º 3145 con una falla de The file cannot be accessed by the system.

@IarwainBen-adar Lo siento, no puedo reproducir el #3145. De lo contrario, intentaría solucionar el problema por mi parte.

anclar a la barra de tareas y shift+clic derecho

Saludos @LordFPL y, por supuesto, @gerardog , nunca antes había oído hablar de gsudo (https://github.com/gerardog/gsudo para otros interesados), pero ahora esto hace que las sesiones elevadas sean muy sencillas. ¡Gracias! Añádalo al objeto de perfil en el archivo de configuración, o simplemente use el alias sudo como lo haría en un sistema Linux. ¡Perfecto!

@ zadjii-msft, mis disculpas, pero no entiendo exactamente cuál es el problema aquí. Windows admite la manipulación y la suplantación de tokens, así es como funciona runas, ¿no? Al usar gsudo de @gerardog , puedo tener una integridad baja (más baja) con un shell de integridad alta (más) al mismo tiempo que cualquier otro shell de integridad de nivel, ya sea powershell, pwsh, cmd o cualquier shell wsl. Según mis pruebas limitadas, ninguno de los shells de integridad más baja puede depurar en ese shell de integridad más alta. ¿Cuál es el obstáculo aquí para tener esto como una función de terminal integrada, o incluso más preferible a nivel de sistema operativo?

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

Una ventana de baja (más) integridad _que recibe información y la canaliza directamente a un proceso de alta (más) integridad_ abre ese proceso de alta (más) integridad para que lo controlen otras cosas de más baja (más) integridad en el sistema.

Significa que un proceso potencialmente malicioso solo necesita un movimiento lateral con el mismo nivel de privilegios para obtener EoP.

@smokeintheshell #632 (comentario)

Una ventana de baja (más) integridad _que recibe información y la canaliza directamente a un proceso de alta (más) integridad_ abre ese proceso de alta (más) integridad para que lo controlen otras cosas de más baja (más) integridad en el sistema.

Significa que un proceso potencialmente malicioso solo necesita un movimiento lateral con el mismo nivel de privilegios para obtener EoP.

sí, leí esa explicación al comienzo del hilo, pero no entiendo por qué está bien para Linux, y probablemente Mac, pero no está bien para Windows. Actualmente, Windows protege la entrada a los procesos elevados de los procesos no elevados. En este problema o en uno relacionado, alguien sugirió que necesitamos un proceso separado por pestaña. Creo que este ya es el caso, ya que cada pestaña tiene su propio comando para ejecutar (por ejemplo: pwsh.exe). ¿Es porque todos son hijos del mismo proceso raíz bajo un HWND?

¿La terminal de Ubuntu sufre el mismo problema con las pestañas si yo:

• tener una pestaña con su abierta
• ¿Tengo una pestaña en la que ya he elevado sudo y no necesito ingresar mi PW nuevamente según la política de configuración?

¿O la arquitectura de Ubuntu está reforzada de alguna manera contra los ataques de inyección de entrada entre procesos?

¿La terminal de Ubuntu sufre el mismo problema con las pestañas si yo:

* 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?

¿O la arquitectura de Ubuntu está reforzada de alguna manera contra los ataques de inyección de entrada entre procesos?

Si miras mi comentario aquí , en realidad he reproducido/explotado el problema en Linux. Tanto su como sudo son probablemente igualmente "vulnerables", ya que puede enviar pulsaciones de teclas a ventanas de menor integridad que ejecutan esos comandos. El tiempo de espera de la contraseña de sudo (no tener que ingresar su contraseña en el próximo comando de sudo dentro de los 15 minutos), hace que esto sea aún más fácil. Puede fortalecer Ubuntu deshabilitando la extensión X que es necesaria para el ataque. No estoy seguro de si esto es posible en un entorno de Wayland (el ataque y/o el endurecimiento).

Entiendo completamente la decisión de no implementar pestañas de elevación mixta, a menos que haya alguna forma de desactivar los teclados virtuales y otros métodos de entrada de software.

Creo que este ya es el caso, ya que cada pestaña tiene su propio comando para ejecutar (por ejemplo: pwsh.exe). ¿Es porque todos son hijos del mismo proceso raíz bajo un HWND?

@kbirger Sí, hay procesos separados para cada pestaña, pero todas las entradas de su mouse y teclado aún se envían a la ventana de Windows Terminal (que es de baja integridad), luego se enrutan a cada proceso de shell a través de flujos de entrada estándar. Así es como funcionan todos los atajos de teclado de Windows Terminal.

Me pregunto si es posible detectar si la entrada está falsificada, por ejemplo, usando la API GetCurrentInputMessageSource . No puedo encontrar mucha información sobre esta API aparte del ejemplo oficial, pero a partir de la descripción debería poder identificar la fuente de entrada (hardware/de procesos con uiAccess, principalmente software de accesibilidad/de procesos sin uiAccess, tal vez malicioso)

¿Por qué está bien para Linux, y probablemente para Mac, pero no para Windows?

Estoy bastante seguro de que una de las tres razones es que Microsoft está vendiendo seguridad como una función a otras grandes corporaciones o gobiernos.

También hay algunas otras razones que me vienen a la mente sobre por qué eso podría no haber sido un problema hasta ahora:

• Durante mucho tiempo, y por muchas razones (como que a los "hackers" no les gusta Windows y "todos" usan Windows ^^), Windows solía ser el objetivo principal (≈único) de todo tipo de malware. Necesitaba mejor seguridad (proteger ventanas elevadas), mientras que a otros no les importaba mucho.
• Como se explicó anteriormente en este problema, no debería haber sido posible que el malware acceda fácilmente a su host de consola elevado en Windows, por lo que es probable que no muchos hayan invertido en ese problema (no soy un experto en seguridad, así que no sé si algunos tienen)
• El malware generalmente ha tenido otras formas de elevarse a sí mismo además de tratar de encontrar un símbolo del sistema elevado en su sistema operativo de elección.
• Solo los desarrolladores y administradores de sistemas usan terminales (esto solo reduce el objetivo demográfico del ataque; los gobiernos y las grandes corporaciones siguen siendo una preocupación)

Ahora, al introducir la función de forma ingenua (como todos lo habríamos hecho, estoy seguro 😄) estarías introduciendo una nueva (enorme) falla en algunas instalaciones de Windows. Con el desarrollo abierto, puede estar seguro de que todos los que lo necesiten se darán cuenta de la falla y comenzarán a codificar contra ella.
La contramedida rápida es prohibir Windows Terminal (y probablemente todos los demás emuladores de terminal ahora que la falla es pública), entonces podría despedirse de sus sueños de usar Windows Terminal en cualquier tipo de entorno corporativo 😟

Sin embargo, todavía tengo muchas esperanzas de que una versión segura de esta característica vea la luz del día 🤞

Veo. ¡Gracias por las explicaciones!

Como nota al margen, ¿cómo envía el teclado en pantalla de Windows las pulsaciones de teclas a las ventanas elevadas?

@mrwensveen AFAIK hay tres formas de enviar entradas a ventanas elevadas:

1. Elévate a ti mismo. Sin embargo, aún no puede enviar entradas a los procesos del sistema (por ejemplo, Administrador de tareas, cuadro de diálogo UAC, pantalla de inicio de sesión).
2. Registre un servicio de Windows. Ahora su programa se ejecuta como SISTEMA para que pueda hacer lo que quiera. He visto que algunos programas de acceso remoto hacen esto.
3. Declare el indicador uiAccess , firme digitalmente su binario, instálelo en una ubicación en la que no se pueda escribir para el usuario actual. Es una "puerta trasera" para los softwares de accesibilidad, lo que les permite leer/escribir cualquier otro programa (incluidos los procesos del sistema) y mostrarse encima de cualquier otra ventana (incluido Secure Desktop donde se muestran las ventanas emergentes de UAC y la pantalla de inicio de sesión), todo sin ejecutarse elevado. Consulte https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverview.

El teclado en pantalla (osk.exe), Narrator.exe (y quizás otros lectores de pantalla) utilizan el método 3.

(Una captura de pantalla que muestra el manifiesto del programa incrustado de osk.exe con uiAccess=true )

Parece que el indicador uiAccess también puede proteger el programa para que no sea accedido por otros programas de baja integridad (a pesar de que todavía se ejecuta sin niveles elevados), ¿tal vez podamos usar esta "característica" para proteger WT?

@yume-chan Genial, eso es muy interesante, ¡gracias! ¿Se permite que los programas uiAccess envíen pulsaciones de teclas a otros programas uiAccess ? Todavía queremos que OSK pueda interactuar con la terminal de Windows, y si esto significa que otros programas deben al menos firmarse antes de que se les permita enviar información a la terminal de Windows, ¿es una barrera lo suficientemente alta?

¿Se permite que los programas de uiAccess envíen pulsaciones de teclas a otros programas de uiAccess?

@mrwensveen Sí, los programas con privilegios uiAccess pueden acceder entre sí.

Prefiero la forma de API GetCurrentInputMessageSource (https://github.com/microsoft/terminal/issues/632#issuecomment-651114562) porque este no es el uso previsto uiAccess . Además, con la API, aún podemos permitir que los programas de baja integridad envíen pulsaciones de teclas a pestañas no elevadas, mientras que no a las elevadas.

Pequeña solución que he hecho aquí:

Instalé PowerToys , que tiene algunas características geniales. Uno de ellos es mostrar los accesos directos de Windows y descubrí que cuando presiona Win + número, abre la aplicación en la barra de Windows correspondiente al número que aparece en la barra.

Entonces, puse la terminal en la barra como el primer ícono
.

Cuando presiono Win + 1, se abre la terminal.

Cuando presiono Win + Ctrl + Shift + 1, se abre elevado.

Pondré aquí también la configuración de mi terminal y el perfil de PowerShell si desea obtener las características de mostrar la rama git y el entorno conda en el indicador y el usuario en rojo si se trata de una terminal elevada...

Eso existe desde al menos Windows 7; no es una cosa de PowerToys.

@Firehawke Sí, acabo de descubrirlo gracias a PowerToys ... no es necesario.

Aquí hay un perfil para el lanzamiento elevado que funciona en Windows Store y tiene un ícono adecuado:

{
    "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"
}

EDITAR: Crédito a @glooms , @shem-sargent, @LordFPL y @Firehawke por los diferentes componentes de este fragmento. Como este comando llama a pwsh.exe , parece que algunas personas se han topado con el #4228 (un error 0x80070002 al iniciar) con esto debido a variables de entorno PATH corruptas o binarios extraños en su ruta llamada powershell.exe o pwsh.exe . @zurkz arregló esto haciendo referencia a powershell.exe , pero no creo que sea confiable ahora. # 6684 soluciona este problema para Windows Terminal, y encontrará una versión corregida a continuación, siguiendo esa solución, que no debería tener este problema en absoluto.

Aquí hay un perfil para el lanzamiento elevado que funciona en Windows Store y tiene un ícono adecuado:

{
    "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 ¡ Eso funciona bien! Gracias.

Aquí hay un perfil para el lanzamiento elevado que funciona en Windows Store y tiene un ícono adecuado:

{
    "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 ❤💯

Aquí hay un perfil para el lanzamiento elevado que funciona en Windows Store y tiene un ícono adecuado:

{
    "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"
}

@alguien Perdone mi ignorancia, ¿se cae esto en la configuración de la Tienda Windows? Si es así, ¿alguien puede publicar la ruta? Si no, ¿dónde se supone que vive este chico malo?

¡TIIA!

@Kazamario
Va en el archivo settings.json de la Terminal de Windows, en la sección de perfiles.

Provoca un error: 0x80070002 al iniciar. pwsh 7.1.

Lo cambié a:

{
    "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"
}

y UAC solicitó elevar los permisos.

Lo cambié a:

{
    "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"
}

y UAC solicitó elevar los permisos.

eso me funcionó bastante bien. ¡Gracias!

Aquí se explica cómo iniciar Windows Terminal elevado si estaba anclado a Inicio.
https://github.com/farag2/Utilities/blob/master/Windows%20Terminal/Pin%20to%20Start.ps1

@narfanar Parece que te has topado con el #4228, donde Windows Terminal emite un error 0x80070002 al inicio cuando la variable de entorno PATH está desordenada u otros binarios están flotando en la ruta denominada powershell.exe o pwsh.exe . No creo que el fragmento de código de @zurkz realmente solucione esto, ya que solo cambia los problemas potenciales de pwsh.exe a powershell.exe . #6684 arregló esto para WT, así que aquí hay un fragmento ajustado a esa solución:

{
    "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 hace esto bien

Tenga en cuenta que Cmder tiene esta función, que es increíblemente útil. Me encantaría verlo implementado en Windows Terminal. Incluso si tiene que abrir una ventana separada para las pestañas de administración o algo así...

mi perfil predeterminado está configurado para bash en lugar de powershell, y me gustaría mantenerlo así. el fragmento anterior funciona muy bien, pero me encanta poder hacer que lance una nueva terminal elevada con el perfil de PowerShell cargado. Pasé como 3 horas tratando de resolver esto (no soy un gran fanático de / tengo mucha experiencia con powershell) y no puedo resolverlo, por favor ayuda. parece que hay una combinación de comillas simples, comillas dobles, escapes, espacios, líneas nuevas, que podrían hacer que funcione, pero no puedo obtener el proceso de inicio y la lista de argumentos para hacer lo que quiero. lo he reducido a:

Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p "Windows PowerShell"'
esto funciona en un archivo .ps1 si lo ejecuto yo mismo, obtengo una nueva terminal de Windows elevada con el perfil de PowerShell cargado. pero no funciona en el parámetro de línea de comando de settings.json, no importa cómo intente manipularlo, llamando explícitamente a argumentlist en lugar de usar cmd /c, varias formas de escape y uso de comillas, etc.

"commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p \"Windows PowerShell\"'",
No funciona. lo mejor que puedo hacer es hacer que lance un extraño híbrido de lo que quiero. Obtendré una ventana "Administrador: Ubuntu" cargada, que se parece a mi perfil bash pero en realidad está ejecutando PowerShell. fuente incorrecta y todo. si uso esa ventana para abrir una nueva pestaña de PowerShell, se elevará como desee. cuando es así, puedo pegar cualquier basura que quiera en la parte "Windows PowerShell" de la carga del perfil y obtengo exactamente el mismo comportamiento, así que sé que en realidad no está intentando cargar el perfil que estoy pasando.

Así que tengo un problema al tratar de ejecutar esto como elevado, he hecho todas las opciones enumeradas anteriormente y recibo el error "No se puede encontrar el archivo" o esto.

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

¿Alguien más tiene el problema todavía o no ha podido hacer que funcionen bien?

mi perfil predeterminado está configurado para bash en lugar de powershell, y me gustaría mantenerlo así.

Yo también. Ejecuto WSL la mayor parte del tiempo, pero de vez en cuando necesito ejecutar PS elevado, y me gustaría hacerlo en una pestaña del nuevo WT.

Tampoco pude hacer que ninguno de los ejemplos funcionara, incluso al corregir las rutas de mis archivos. Encontré e instalé gsudo , que puede elevar la pestaña actual o usarse como perfil para abrir una pestaña elevada en la misma ventana. No estoy seguro si las soluciones anteriores comenzaron en una nueva ventana (algunos intentos que hice antes de usar gsudo solo comenzarían en una nueva ventana). Se abrirá una ventana emergente de UAC.

Este es el perfil que estoy usando:

{
    // 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
}

Estoy usando supressApplicationTitle para que el título de la pestaña no muestre Administrador: ya que es redundante con Elevated .

@ayfine Si https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 no funciona para usted, ¿podría enviar una transcripción de los errores exactos/comportamiento inesperado que está obteniendo con esa configuración? (Asegúrese de agregar una configuración adicional, como suppressApplicationTitle , en pasos lo más pequeños posible, de modo que si alguna de sus configuraciones está rompiendo WT, será más fácil saber dónde y cuándo está sucediendo).

Si alguna otra configuración aquí fue un poco más lejos que la vinculada para usted, también agradecería los detalles sobre cómo se están rompiendo.

@ bb010g No encuentro ningún mensaje de error. Pido disculpas por no ser más preciso en mi respuesta. Al usar https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 me encontré con el problema de que Windows Terminal cargaba mi WSL Ubuntu shell (mi configuración predeterminada). Originalmente había interpretado que esto significaba que no funcionaba correctamente, pero ahora veo que en esa nueva ventana, si inicio una nueva pestaña de Powershell (perfil predeterminado), de hecho está elevada. De todos modos, tanto al abrir una nueva ventana como al tener que iniciar una nueva pestaña dentro de ella, no es más fácil que ejecutar un proceso elevado desde mi menú de inicio. Lo que describí en mi respuesta original proporciona el comportamiento exacto que estaba imaginando.

@ayfine - y copié tu ejemplo de gsudo. Esa es una solución lo suficientemente buena hasta que se codifica algo integrado. Gracias.

@ayfine Probé lo de gsudo, pero es una experiencia bastante horrible. Cualquier tipo de finalización de TAB parece romperse y los caracteres Unicode (no ASCII) no parecen mostrarse. Supongo que es algún tipo de proceso que redirige la entrada y la salida, y hace un trabajo terrible. Creo que la solución con una ventana separada funciona mejor.

Si tiene problemas con gsudo, infórmelos a @gerardog y no en este hilo. Cada mensaje en este hilo (este incluido; ¡lo siento!) envía correos electrónicos a cientos de suscriptores.

Voy a bloquear este hilo para otros comentarios que no sean de mantenimiento, ya que estamos llegando al punto en el que los comentarios adicionales no hacen avanzar la discusión de manera significativa.

Presente nuevos problemas si tiene inquietudes que no están cubiertas aquí.