Terminal: [Вопрос] Настройка профиля Windows Terminal для постоянного запуска с повышенными правами

Нет. Я не думаю, что мы планируем поддерживать смешанные вкладки с повышенными и неповышенными правами, потому что это немного дыра в безопасности.

Да, я знаю, что sudo — это вещь, но у нас было много обсуждений с командой безопасности по поводу создания sudo для Windows. Основная проблема связана с тем, что любые процессы без повышенных прав могут отправлять нажатия клавиш в любые другие окна без повышенных прав.

Если у вас была командная строка с повышенными правами, работающая в окне без повышенных прав, ненадежный злоумышленник может выполнить атаку с повышением привилегий, запустив окна без повышенных прав, в которых запущена командная строка с повышенными правами.

(чтобы связать связанные темы, # 146)

РЕДАКТИРОВАТЬ (14 февраля 2020 г.)
Итак, этот комментарий не очень хорошо устарел. Изначально не было плана по поддержке этого, так как это не сработало бы с единственными HWND , которые у нас были. Мы работаем над созданием решения, которое _могло бы_ поддерживать это в будущем, но мы не можем брать на себя никаких обязательств, пока не будем уверены, что сможем предложить достаточно безопасное решение, которое гарантирует, что процесс с более низким уровнем привилегий не сможет управлять терминалом с более высокими привилегиями.

Кажется разумным. Я думаю, что наличие чего-то вроде комбинации # 576 (Открыть от имени администратора в списке переходов) и, возможно, какой-то горячей клавиши для запуска сеанса администратора терминала решит большую часть моей проблемы здесь.

Как насчет открытия стандартного и расширенного Терминала в одном окне, но на отдельных вкладках?

@mdtauk Думаю, это, к сожалению, подпадает под ту же категорию. Поскольку все вкладки находятся под одним и тем же HWND, корневой HWND необходимо повысить, чтобы приложения без повышенных прав не управляли окном.

С точки зрения безопасности (игнорируя дизайн Windows Terminal, единый корневой HWND и т. д.), насколько «менее безопасным» является Terminal, использующий вкладки со смешанными правами, по сравнению с запуском, скажем, одного экземпляра PowerShell с повышенными правами рядом с одним экземпляром без повышенных прав в текущем UX. ? Тот факт, что консольные приложения размещены на вкладках терминала, для меня не имеет значения...

Аналогичная заметка: как сделать окно без повышенных прав более безопасным, даже если я открою удаленный сеанс PS, где теперь у меня могут быть права администратора на удаленном сервере, которым теперь может управлять не повышенное. Для меня это кажется намного хуже, чем получение доступа к локальному администратору, поэтому я не думаю, что запуск вкладки в качестве администратора чем-то отличается от удаленного взаимодействия / подключения по ssh к другим серверам. В обоих случаях мне нужно чувствовать себя достаточно комфортно с моей системой, чтобы сделать это. Это из разряда «я достаточно взрослый и понимаю риски».

Всякий раз, когда я пытаюсь запустить приложение «Терминал» с учетной записью администратора, щелкните правой кнопкой мыши -> запустить от имени администратора, UAC появляется дважды, и возникает ошибка:
«Windows не может найти (путь\WindowsTerminal.exe) Убедитесь, что вы ввели ...".

Путь существует, и приложение работает правильно для пользователя без прав администратора, создавшего приложение, но другой пользователь с правами администратора не может его запустить.
Если я вхожу в систему с правами администратора, приложение терминала отсутствует ни в настройках, ни в меню «Пуск», как будто оно никогда не устанавливалось в системе.

Есть ли способ создать приложение, чтобы оно устанавливалось для всех пользователей? Или корень проекта должен находиться в каталоге, не зависящем от пользователя?

@

Всякий раз, когда я пытаюсь запустить приложение «Терминал» с учетной записью администратора, щелкните правой кнопкой мыши -> запустить от имени администратора, UAC появляется дважды, и возникает ошибка:
«Windows не может найти (путь\WindowsTerminal.exe) Убедитесь, что вы ввели ...".

Путь существует, и приложение работает правильно для пользователя без прав администратора, создавшего приложение, но другой пользователь с правами администратора не может его запустить.
Если я вхожу в систему с правами администратора, приложение терминала отсутствует ни в настройках, ни в меню «Пуск», как будто оно никогда не устанавливалось в системе.

Есть ли способ создать приложение, чтобы оно устанавливалось для всех пользователей? Или корень проекта должен находиться в каталоге, не зависящем от пользователя?

Я также вижу ту же проблему.

Версия Windows 18922.1000

Правильно, поэтому запуск приложений магазина от имени администратора или другого пользователя не работает (кстати, по дизайну). Многие из нас вошли в систему (на ПК) как обычная учетная запись без повышенных прав. Мы запускаем powershell/cmd/etc от имени администратора для выполнения определенных задач.

Если окончательным выбором является развертывание этого приложения в магазине Windows, оно бесполезно для меня без какого-либо способа открывать вкладки с повышенными правами. Мои 2 цента.

«Бесполезно», может быть, немного резко, но нам действительно нужен способ использовать новый терминал как для приложений/оболочек консоли без повышенных прав, так и для консольных приложений/оболочек с повышенными правами. И для меня лучшим UX была бы поддержка сочетания вкладок с повышенными и обычными правами в одном и том же экземпляре Windows Terminal. Менее предпочтительно: поддержка от нуля до многих (обычно один) экземпляров с повышенными правами (каждый с одной или несколькими вкладками) наряду с от нуля до многих (обычно один) экземпляров без повышенных прав.

ConEmu может смешивать вкладки с повышенными и обычными правами в одном окне. Здесь нельзя сделать что-то подобное?

Можем ли мы иметь терминал с повышенными правами для запуска вкладок без повышенных прав? Мне все еще нужно запустить с повышенными правами, НО я могу открыть новую вкладку, которая «защищена».

Если мы хотим полностью сосредоточиться на Windows и игнорировать другие платформы, которые могут в конечном итоге увидеть Терминал, возможно, использование контейнеров Windows или виртуализированных процессов может решить эту проблему для некоторых. Меня лично устраивает текущее решение, но запуск консольных приложений как изолированных процессов по умолчанию не будет такой уж плохой идеей с точки зрения безопасности.

Смешанная высота в одном окне обязательна, по крайней мере для меня.
Может быть, это необязательная функция, которую нужно переключать в настройках?

@pratnala С ConEmu это только _выглядит_ так, как будто он это делает, но на самом деле это совсем не так. «Вкладки» с повышенными и неповышенными правами — это просто представления двух совершенно отдельных изолированных корневых окон / процессов. Он делает это, очищая содержимое окон, среди прочего, и помощники по повышению прав прокси / брокера и т. Д. Конечно, технически это возможно, но то, что делает ConEmu, на самом деле довольно небезопасно. Одно дело, когда это делает сторонняя программа, и люди соглашаются на риск, загружая ConEmu, и совсем другое, когда Microsoft официально одобряет это, делая это сама. Если я хочу спрятать ключи от входной двери под ковриком, то ладно - это мой глупый риск. Но что, если к каждой купленной двери положить ключи под коврик?

Но видите ли, я разрабатываю на C++ (а также на C#, PowerShell, Ruby, Python, GoLang и почти на всем, что мне попадется). У меня установлены ConEmu и TakeCommand, а также mingw. Я знаю, как держать ножницы во время бега.

PowerShell — это дыра в безопасности. Очень полезный инструмент автоматизации, обеспечивающий всевозможный неожиданный доступ. И то, о чем мы просим (смешанные режимы), безусловно, безопаснее, чем альтернатива (все с повышенными правами). На самом деле этот (терминал) является мощным инструментом для опытных пользователей, большинство из которых, вероятно, очень хорошо понимают ландшафт безопасности... и понимают прагматический компромисс.

Нулевое доверие работает только тогда, когда оно не изнурительно.

@robomac Если бы мы могли убедить команду безопасности (которая неоднократно говорила нам не рисковать даже отдаленно приближаться к смешанной высоте), что только люди, которые знают, как правильно держать ножницы и не бегать с ними, будут _использовать_ этот проект, мы, вероятно, сделали бы это. Не знаю, верю ли я сам. Вот почему:

Как бы то ни было, если Терминал работает со смешанными правами (от узла со средним уровнем IL до клиента с высоким уровнем IL), его все равно можно заставить получать ввод от кого-либо еще, работающего от имени этого пользователя. Даже если человек за клавиатурой — святой и повышает права только на те десять секунд, на которые ему нужно подняться, _любое приложение, работающее под его учетной записью, может выдавать себя за администратора без дополнительного запроса на повышение_. Скорее всего, даже совершенно незамеченным.

@ DHowett-MSFT Спасибо за ответ. Вы делаете предположение, что мы позволяем вредоносным процессам работать в любом случае. Мы ограничиваем разрешения из-за мантр «Передовой практики», которые мы делаем с нашей позой собаки мордой вниз каждое утро, но если у вас действительно есть опасения, что даже несколько часов доступа к терминалу с повышенными правами подвергают вас риску _на вашей собственной системе, которая вы разрабатываете на_ ...

1. Вы не должны запускать Терминал и
2. Вы должны стереть и начать заново.

Я согласен с тем, что исследователь (компьютерных) вирусов не должен рисковать этим в векторном пути... но даже раньше мы помещали их в песочницу на виртуальных машинах. Но «Терминал» не для ваших неискушенных родственников; это электроинструмент.

Существует стандартный способ борьбы с риском. Предоставлено вам миром браузеров. Когда вы переходите к расширенным флагам, вы получаете предупреждение, грубо говоря, «Здесь будут драконы». (Я думаю, что это именно то, что в Pale Moon... который является серьезным хардкорным браузером безопасности.) Добавьте (не UAC, дополнительное) предупреждение, но пусть решает пользователь.

Еще один вопрос: будут ли два разных сеанса Терминала, один с повышенными правами, а другой нет, вести себя так, как ожидалось? Или оба будут векторами для любых сеансов?

Я не возражаю, что люди должны иметь возможность выбрать что-то подобное. :улыбка:

два разных сеанса

О, да, это должно работать сегодня — и не быть вектором (повышенный уровень полностью работает на стороне мира с высоким уровнем IL и не может управляться каким-либо другим процессом со средним уровнем IL).

это должно работать сегодня

В том же духе, разве 2 вкладки не могут работать в разных процессах и, таким образом, включать смешанное повышение прав в одном окне?

@ DHowett-MSFT Так почему же два отдельных сеанса не могут быть размещены в общем приложении? Это действительно не сложно сделать.

Я думаю, что в первую очередь понимаю последствия для безопасности наличия консольных приложений с повышенными правами, но я не могу понять, почему наличие двух типов вкладок (с повышенными и без повышенных прав) в Терминале Windows было бы _более рискованным_, чем то, что поддерживает Windows. в течение многих лет, т.е. параллельное использование CMD/PowerShell с повышенными и неповышенными правами. Может ли кто-нибудь пролить свет на это?

@робомак
[1] Это тривиально, когда вы _размещаете традиционные окна_ с традиционными оконными дескрипторами. Это очень хорошо работает в случае conemu или в случае оболочки с вкладками, когда вы можете взять окно в сеансе с повышенными правами и переназначить его под окном в сеансе без повышенных прав.

Когда вы это сделаете, есть несколько функций безопасности, о которых я расскажу в [2]. Из-за этого вы можете воспитывать его, но вы не можете заставить его что-либо делать.

Однако есть проблема. Терминал не спроектирован как набор окон с возможностью повторного родителя. Например, он не запускает хост консоли и не перемещает его окно на вкладку. Он был разработан для поддержки «соединения» — чего-то, что может читать и писать текст. Это примитив более низкого уровня, чем окно. Мы осознали свою ошибочность и решили, что модель UNIX всегда была правильной, а конвейеры, текст и потоки — там, где они есть.

Учитывая, что мы используем острова Xaml для размещения современного пользовательского интерфейса и вшиваем в него поверхность DirectX, мы в любом случае далеко за пределами мира стандартных оконных дескрипторов. Острова Xaml полностью объединены в единый HWND, подобно Chrome и Firefox, а также всему спектру игр DirectX/OpenGL/SDL. У нас нет компонентов, которые можно запускать в одном процессе (с повышенными правами) и размещать в другом (без повышенных прав), которые не являются вышеупомянутыми «соединениями».

Теперь очевидный дополнительный вопрос: _"почему вы не можете иметь одно соединение с повышенными правами на вкладке рядом с соединением без повышенных прав?"_ Вот где @sba923 должен начать читать (:smile:). Возможно, я расскажу о некоторых вещах, которые вы уже знаете (@robomac).

[2] Когда у вас есть два окна на одном рабочем столе в одной оконной станции, они могут взаимодействовать друг с другом. Я могу легко использовать SendKeys через WScript.Shell для отправки ввода с клавиатуры в любое окно, которое может видеть оболочка.

Запуск процесса с повышенными правами _разрывает_ это соединение. Оболочка не видит приподнятое окно. Никакая другая программа с тем же уровнем целостности, что и оболочка, не может видеть окно с повышенными привилегиями. Даже если у него есть дескриптор окна, он не может с ним взаимодействовать. По этой же причине вы не можете перетаскивать из проводника в блокнот, если блокнот работает с повышенными правами. Только другой процесс с повышенными правами может взаимодействовать с другим окном с повышенными правами.

Эта функция «безопасности» (называйте ее как хотите, вероятно, в какой-то момент она предназначалась для защиты) существует только для нескольких типов глобальных объектов сеанса. Окна — одна из них. Трубы на самом деле не являются одним из них.

Из-за этого взломать эту защиту тривиально. Возьмите терминал в качестве примера этого. Если мы запустим соединение с повышенными правами и разместим его в окне без повышенных прав, мы внезапно создадим канал через эту границу безопасности. Приподнятая вещь на другом конце — это не окно, это просто приложение в текстовом режиме. Он сразу же выполняет ставки хоста без повышенных прав.

Любой, кто может _контролировать_ хост без повышенных прав (например, WScript.Shell::SendKeys ) _также_ получает мгновенный канал через границу повышения. Неожиданно любое приложение со средней степенью целостности в вашей системе может управлять процессом с высокой степенью целостности. Это может быть ваш браузер или биткойн-майнер, установленный с пакетом left-pad от NPM, или что угодно еще.

Это небольшой риск, но это _is_ риск.

Другие платформы пошли на этот риск ради удобства пользователей. В этом нет ничего плохого, но я думаю, что Microsoft меньше пропускает такие вещи, как «принятие риска ради удобства пользователя». Windows 9x была настоящей катастрофой в области безопасности, и ответом на эти проблемы были ограниченные учетные записи пользователей, запросы на повышение прав и безопасность на уровне ядра для управления окнами. Это не замки, которые можно легко ослабить.

@ DHowett-MSFT Большое спасибо за разъяснения. Я думаю, нам придется привыкнуть к одновременному запуску одного экземпляра Windows Terminal с повышенными правами и одного экземпляра без повышенных прав, как мы это делаем в наши дни с консольными приложениями.

Очаровательный. Спасибо. Терминал, являющийся скорее средством рендеринга соединения, чем окном, имеет смысл. Дает ли это PowerShell, уже ориентированному скорее на каналы/соединения, какой-либо дополнительный контроль по сравнению с ранее работавшей в оконной консоли?

Являются ли отдельные сеансы терминала полностью изолированными друг от друга?

Я был бы полностью удовлетворен, если бы у меня было просто указание, что я нахожусь в сеансе с повышенными правами. Типа "Администратор: \ Я очень скучаю по этому прямо сейчас.

???

«Запуск от имени другого пользователя» — это то, что нужно всем администраторам Windows! Это было бы очень полезно, если бы оно было доступно. Лучшим вариантом было бы иметь его с флажком в конфиге для каждого профиля.

Кстати, говоря об изоляции окон, позвольте мне процитировать последний отчет об уязвимости ctfmon.

Очевидная атака — непривилегированный пользователь, вводящий команды в сеанс консоли администратора или считывающий пароли при входе пользователя в систему. Даже изолированные процессы AppContainer могут выполнять ту же атаку.

@ecki Это довольно тревожная новость. Я уверен, что Тэвис сегодня вечером уйдет на вечеринку после той.

@DHDHowett-MSFT
Как многие здесь писали, если новый терминал не может запускаться с опцией «запуск от имени другого пользователя», чем для большого количества пользователей, он не очень удобен для использования, а также он несовместим с «моделью административного уровня Active Directory» Microsoft. например, если у вас есть пользователь AD с правами по умолчанию и вы запускаете сценарии PS с правами администратора на контроллере домена.

У меня не так много случаев, когда я запускаю терминал с моим текущим зарегистрированным пользователем… поэтому я спрашиваю вас, каков вариант использования этого терминала? Ping, nslookup и т. д., если это намерение, то почему вы вкладываете столько труда во все это?

С «запуском от имени администратора» у вас есть некоторые важные моменты, но почему другие консоли, такие как (PS6/7), все еще поддерживают эти функции, если они настолько небезопасны?

Я всегда думал, что новое приложение Terminal заменит все отдельные окна cmd/PS/…, но, похоже, его нельзя использовать во многих реальных сценариях. Это как-то грустно, тб...

@Fisico, ваш опыт не универсален, и я бы посоветовал вам учитывать это, когда вы просите кого-то оправдать само существование своего проекта.

К вашему всеобъемлющему замечанию о том, что «запуск от имени другого пользователя» не существует / не работает: это ограничение платформы, которое мы пытаемся снять. Мы не поддерживаем его не по злому умыслу или некомпетентности.

Что касается того, почему другие консольные приложения _поддерживают_ его, это не является небезопасным, когда они это делают, потому что они специально не размещают разные уровни прав в одном и том же окне. Это основная проблема здесь. Поскольку они размещаются в автономных процессах с автономными окнами, на них не распространяются ограничения на манипуляции на уровне целостности.

@DHowett-MSFT
Извините, если обидел вас своим постом, это не было моей целью, я вложил в него слишком много эмоций.
Я думаю, что Терминал — отличная идея и у него очень большой потенциал, и я рад, что вы разрабатываете его вместе с сообществом, чтобы получить от него максимальную отдачу.

На данный момент так много путаницы в том, что реализовано, а что нет.
«Запуск от имени администратора» для всего приложения в данный момент работает, это останется?

Насколько я понимаю, «Запуск от имени администратора» для каждой вкладки/профиля — это не то, что вы хотите реализовать. Я думаю, что это нормально для большинства из нас.

«Запуск от имени другого пользователя» невозможен, потому что Windows не поддерживает его для приложений, и вам/нам приходится ждать, пока Windows его не поддержит? Если да, то мы говорим о годах?

«Запуск от имени другого пользователя» для каждой вкладки/профиля — это тоже то, что вы не хотите реализовывать?

@DHDHowett-MSFT
Как многие здесь писали, если новый терминал не может запуститься с опцией "запустить от имени другого пользователя"
чем для большого числа пользователей, это не очень удобно, ... Я всегда думал, что новое приложение терминала будет
замените все отдельные окна cmd/PS/…, но, похоже, это непригодно для использования во многих реальных сценариях. Это как-то грустно, тб...

Я не согласен. Это огромный шаг вперед по сравнению с тем, что было раньше. К сожалению, большинство из нас, вероятно, привыкли запускать наши оболочки приподнятыми из-за отсутствия более детального подхода... и мы все еще можем. Мы не можем _смешивать_ их... но мы никогда этого не делали. Серьезно, в _последних трех_ компаниях, в которых я работал, вики для разработчиков выполняла все сборки/тесты в командной строке VS с повышенными правами. Мы реализуем безопасность с помощью сканирования в режиме реального времени, агрессивных активных брандмауэров и зная, что наши разработчики редко ошибаются. _Не-разработчики_ никогда не работают с повышенными правами, потому что (1) мы не можем им доверять и (2) им это не нужно.

Так что я, например, благодарен за этот новый Терминал. Это не идеально, но и Take Command / TCC тоже. По крайней мере, это стандарт.

@DHDHowett-MSFT
Как многие здесь писали, если новый терминал не может запуститься с опцией "запустить от имени другого пользователя"
чем для большого числа пользователей, это не очень удобно, ... Я всегда думал, что новое приложение терминала будет
замените все отдельные окна cmd/PS/…, но, похоже, это непригодно для использования во многих реальных сценариях. Это как-то грустно, тб...

Я не согласен. Это огромный шаг вперед по сравнению с тем, что было раньше. К сожалению, большинство из нас, вероятно, привыкли запускать наши оболочки приподнятыми из-за отсутствия более детального подхода... и мы все еще можем. Мы не можем _смешивать_ их... но мы никогда этого не делали. Серьезно, в _последних трех_ компаниях, в которых я работал, вики для разработчиков выполняла все сборки/тесты в командной строке VS с повышенными правами. Мы реализуем безопасность с помощью сканирования в режиме реального времени, агрессивных активных брандмауэров и зная, что наши разработчики редко ошибаются. _Не-разработчики_ никогда не работают с повышенными правами, потому что (1) мы не можем им доверять и (2) им это не нужно.

Так что я, например, благодарен за этот новый Терминал. Это не идеально, но и Take Command / TCC тоже. По крайней мере, это стандарт.

повышенный != работать от имени другого пользователя.
Я использую PowerShell больше с другими пользователями AD, чем со своим.
Я с вами, что вы часто запускаете cmd или PS от имени администратора, даже если вам это не нужно, но есть так много случаев, когда вам нужно запускать его от имени администратора. Для большинства задач системного администратора требуются права администратора или другой пользователь с какими-либо привилегиями.
Конечно, если вам нужно запустить cmd в контексте пользователя, все в порядке.

Я понимаю, что «с повышенными правами! = работать от имени другого пользователя». Я просто не верю, что «запуск от имени другого пользователя» почти так же распространен, как вы утверждаете.

Я понимаю, что «с повышенными правами! = работать от имени другого пользователя». Я просто не верю, что «запуск от имени другого пользователя» почти так же распространен, как вы утверждаете.

Если у вас есть какое-то отношение к вселенной Microsoft, вам это абсолютно необходимо.
Например, не лучшая идея входить на машины Windows с правами администратора домена.
Запуск сценариев PS от пользователя с правами администратора домена или некоторыми другими правами очень распространен.

@Fisico, почему бы тогда не использовать команду New-PSSession ?

Автоматизированные скрипты, требующие определенного типа повышения прав для службы, обычно требуют «запускать от имени другого пользователя». Другое дело, относится ли это к Терминалу. Вы всегда можете изменить свой логин один раз в сеансе CMD или PS, используя команду runas . Это не изменит состояние привилегий вкладки, поскольку оно использует базовый логин, который является вашим обычным пользователем. Кроме того, любые сценарии, которые вы запускаете с помощью планировщика заданий или задания cron, не потребуют запуска терминала, если только вы не используете его для получения функций, которые почему-то не существуют в обычном сеансе консоли. Если это так, то решением будет использование параметров для запуска этого скрипта с терминалом, который запускается как фоновый процесс.

Поэтому смешанная высота для вкладок не нужна. У нас есть обходной путь, и достаточно просто скопировать определенные команды runas, которые вам нужны, в текстовый файл, который вы можете скопировать / вставить в терминал, а затем ввести свой пароль (вы никогда не должны сохранять свой пароль для чего-либо незашифрованного).

@SamuelEnglard
я не хочу подключаться к удаленному хосту, чтобы запустить скрипт.

@WSLUser да, можно использовать runas, но гораздо удобнее просто запустить терминал или PS от имени другого пользователя. Я не понимаю, почему это должно быть проблемой.

@Fisico New-PSSession не нужно подключаться к удаленному компьютеру, см. вторую первую запись синтаксиса.

@SamuelEnglard
я не хочу подключаться к удаленному хосту, чтобы запустить скрипт.

@WSLUser да, можно использовать runas, но гораздо удобнее просто запустить терминал или PS от имени другого пользователя. Я не понимаю, почему это должно быть проблемой.

Это довольно стандартная операция для пользователя — закрепить PowerShell на панели задач и щелкнуть правой кнопкой мыши для запуска от имени администратора или в некоторых средах запустить от имени другого пользователя, поскольку для запуска сценария уровня предприятия требуется учетная запись с повышенными правами. Сказать, что терминал невозможен, похоже на среды, которые используют PSLockDown и заставляют администратора RunAs просто загрузить оболочку или VSCode.
по моему мнению

Если вам действительно нужно, чтобы вкладка запускалась от имени другого пользователя, у вас может быть профиль, который запускает New-PSSession -Credential | Enter-PSSession при запуске.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ : Я не несу ответственности за компьютеры, испорченные этим.

Если вам действительно нужно, чтобы вкладка запускалась от имени другого пользователя, у вас может быть профиль, который запускает New-PSSession -Credential | Enter-PSSession при запуске.

> ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ : я не несу ответственности за компьютеры, испорченные этим.

Конечно, иначе можно было бы пересмотреть стоящую здесь "охрану". Опять же, я прикрепляю PowerShell к своей панели задач, оттуда я могу запускать PowerShell без повышенных прав; Я могу щелкнуть правой кнопкой мыши и выбрать «Запуск от имени администратора», и если в корпоративной среде я могу щелкнуть правой кнопкой мыши значок, затем Shift-щелкнуть правой кнопкой мыши «Windows PowerShell» и выбрать «Запуск от имени другого пользователя», чтобы запустить PowerShell. с альтернативными полномочиями. Никаких сессий, никакого RDP-соединения с другим хостом для получения этих кредитов.

Конечно, иначе можно было бы пересмотреть стоящую здесь "охрану". Опять же, я прикрепляю PowerShell к своей панели задач, оттуда я могу запускать PowerShell без повышенных прав; Я могу щелкнуть правой кнопкой мыши и выбрать «Запуск от имени администратора», и если в корпоративной среде я могу щелкнуть правой кнопкой мыши значок, затем Shift-щелкнуть правой кнопкой мыши «Windows PowerShell» и выбрать «Запуск от имени другого пользователя», чтобы запустить PowerShell. с альтернативными полномочиями. Никаких сессий, никакого RDP-соединения с другим хостом для получения этих кредитов.

Да, и я также могу сделать это с помощью Windows Terminal. Согласованный. Я не понимаю, как это поможет тем, кто хочет иметь несколько вкладок, работающих от имени разных пользователей (или разных прав).

Помимо «смешанных вкладок», я просто хочу уточнить, что вы НЕ МОЖЕТЕ сделать это с (выпущенным предварительным просмотром) Windows Terminal из-за дизайна приложений Windows Store. Вы можете работать только как пользователь, который установил это приложение и вошел в систему как тот же пользователь.

Все, что я хочу, это иметь возможность делать то, что я делаю сегодня, заходить на ПК как обычный пользователь и запускать оболочки с повышенными правами. Если Windows Terminal выпущен как есть, мне от него мало пользы.

Очень хороший момент. Это ограничение отсутствует в частных (не хранящихся) сборках Windows Terminal.

Помимо «смешанных вкладок», я просто хочу уточнить, что вы НЕ МОЖЕТЕ сделать это с (выпущенным предварительным просмотром) Windows Terminal из-за дизайна приложений Windows Store. Вы можете работать только как пользователь, который установил это приложение и вошел в систему как тот же пользователь.

Все, что я хочу, это иметь возможность делать то, что я делаю сегодня, заходить на ПК как обычный пользователь и запускать оболочки с повышенными правами. Если Windows Terminal выпущен как есть, мне от него мало пользы.

Я только что открыл 2 экземпляра сборки Windows Terminal в магазине — один с повышенными правами, а другой — нет. Так что я не знаю, почему это не работает для вас.

Хорошо, я должен поверить, что вы являетесь локальным администратором на своем ПК. Чтобы быть ясным, может быть, я должен уточнить. Я никогда не был локальным администратором на своей рабочей станции. Поэтому, когда я перехожу к «запуску от имени администратора», мне предлагается ввести пользователя/пароль.

Учетная запись администратора, которую я использую, отличается от моей обычной учетной записи для чтения вредоносных программ и электронной почты. Так что технически я работаю под другим пользователем. Это ограничение приложения Магазина Windows. Решение (и, возможно, они это сделают) состоит в том, чтобы выпустить это как компонент Windows, у которого не будет этих ограничений.

* [СРОЧНО] ВСЁ НАШЕЛ РЕШЕНИЕ ЭТОЙ ПРОБЛЕМЫ! * *

Следуя этому руководству
https://www.maketecheasier.com/access-windowsapps-folder-windows-10/
вы можете сделать папку приложения Windows своей собственной!

как только вы это сделаете, вы сможете найти папку Microsoft.WindowsTerminal._blahblahYourVersion_ . Оказавшись внутри, найдите WindowsTerminal.exe , как показано ниже.

Найдя его, создайте ярлык этого файла и поместите его в любое место. После этого установите его для запуска от имени администратора. Вы можете сделать это, щелкнув правой кнопкой мыши и выбрав «Свойства»> «Дополнительно»> «Запуск от имени администратора». После этого нажмите «ОК», и все готово!

Лично мне это нужно, потому что я использую ярлык на панели задач, чтобы просто нажать _Windows+1_, чтобы запустить его от имени администратора. Не долгий путь навигации по меню «Пуск», чтобы запустить его правильно.

Вы также можете просто разархивировать пакет, который мы разместили на странице релизов. Это просто ZIP-файл. Обратите внимание, мы _не поддерживаем_ официально_ неупакованное исполнение!

Но это по-прежнему означает, что нет _поддерживаемого_ способа запуска с повышенными правами! Я считаю, что это обязательная функция.

Действительно, я исправляюсь.

Чего _is_ не хватает, так это записи «запуск от имени администратора» в контекстном меню ярлыка панели задач.

Вчера разговаривал с несколькими людьми на встрече, и несколько человек сказали, что они в основном запускают powershell с Windows + X и хотели бы иметь там терминал / терминал в качестве администратора.

Очень хороший момент!

Это точно моя точка зрения! Это решение для запуска его с панели задач
с правами администратора!

Вс, 25 августа 2019 г., 1:08 Stéphane BARIZIEN [email protected]
написал:

Очень хороший момент!

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/microsoft/terminal/issues/632?email_source=notifications&email_token=AKO4CP6JWWDNLGCHWNIJGFTQGIOULA5CNFSM4HL5EE72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CNA6Q#issuecomment-5124
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AKO4CPZ6YRX5V3ERW4L2GWLQGIOULANCNFSM4HL5EE7Q
.

Действительно, я исправляюсь.

Чего _is_ не хватает, так это записи «запуск от имени администратора» в контекстном меню ярлыка панели задач.

На панели задач дважды щелкните правой кнопкой мыши. Один раз на значке, чтобы появилось контекстное меню, затем второй раз на имени приложения. например, «Терминал Windows (предварительная версия)» и выберите «Запуск от имени администратора».

Я чувствую себя сбитым с толку.

Краснея.

Стыдящийся.

Как же я не подумал об этом?

В любом случае спасибо, что поделились со всеми нами!

Посмотрим на проблему с другой стороны...
Windows позволяет процессам без повышенных прав управлять другими процессами без повышенных прав, отправляя нажатия клавиш, захватывая их пользовательский интерфейс и т. д., но не позволяет процессу без повышенных прав делать это в окне процесса с повышенными правами.
Терминал Windows также предназначен для управления удаленными серверами через ssh, удаленное взаимодействие PowerShell и т. д.
Это означает, что терминал Windows становится дырой в безопасности, как только он используется для администрирования, поскольку локальная вредоносная программа может ждать сеанса терминала Windows, чтобы шпионить за действиями пользователя, и как только обнаружит удаленную оболочку, попытается вводить команды для заражения сервера с правами администратора.

Предотвращение запуска терминала Windows от имени администратора вообще не похоже на улучшение безопасности, поскольку запуск его от имени администратора вместо этого защитит пользователя от процессов без повышенных прав, перехватывающих их сеансы удаленной оболочки. Запуск его от имени администратора следует рекомендовать пользователю всякий раз, когда он использует инструмент, который дает им командную строку с повышенными правами, локально или удаленно.

А что касается sudo для Windows, разве запуск службы sshd и последующее подключение к локальному хосту из оболочки без повышенных прав не вызывает ту же проблему безопасности?

Это означает, что терминал Windows становится дырой в безопасности, как только он используется для администрирования, поскольку локальная вредоносная программа может ждать сеанса терминала Windows, чтобы шпионить за действиями пользователя, и как только обнаружит удаленную оболочку, попытается вводить команды для заражения сервера с правами администратора.

Хотя верно то, что удаленная система может быть заражена (при условии, что удаленный процесс имеет права администратора), это не означает, что мы также должны позволить ему заразить и локальную систему.

Предотвращение запуска терминала Windows от имени администратора вообще не похоже на улучшение безопасности, поскольку запуск его от имени администратора вместо этого защитит пользователя от процессов без повышенных прав, перехватывающих их сеансы удаленной оболочки. Запуск его от имени администратора следует рекомендовать пользователю всякий раз, когда он использует инструмент, который дает им командную строку с повышенными правами, локально или удаленно.

Ничто не мешает вам прямо сейчас запустить Windows Terminal с правами администратора. Проблема заключается в том, чтобы смешать вкладки с повышенными и неповышенными правами.

@SamuelEnglard прямо в ответ.

Чтобы добавить, что мы пытаемся сделать, это избежать добавления _new_ дыр в безопасности. У исходной консоли были те же проблемы с удаленным управлением сервером. Мы ничего не можем с этим поделать, к сожалению. Пользователи, выполняющие удаленное управление сервером, всегда запускают свои консоли/терминалы с повышенными правами, и это дает им некоторую дополнительную безопасность (хотя я не эксперт по безопасности и не стал бы толковать это утверждение как совет)

Идея для продвижения по этой проблеме: попробуйте запустить все _app_ с повышенными правами, и если это удастся, добавьте кнопку рядом с каждой кнопкой «открыть» со значком щита UAC и добавьте префиксную привязку клавиш для открытия вкладки с повышенными правами: Ctrl Shift E . (Я проверил, и это не было привязано.) Это работает только для следующей открытой вкладки.

В любом случае, открытые вкладки имеют значок UAC перед своим обычным значком и запускаются от имени администратора. (Помните, программы больше не могут отправлять эти ключи. Мы запускали приложение от имени администратора.)

Приложение должно попытаться автоматически подняться, и если это не удастся, запуститься в обычном режиме и игнорировать весь этот поток.

Действительно, я исправляюсь.
Чего _is_ не хватает, так это записи «запуск от имени администратора» в контекстном меню ярлыка панели задач.

На панели задач дважды щелкните правой кнопкой мыши. Один раз на значке, чтобы появилось контекстное меню, затем второй раз на имени приложения. например, «Терминал Windows (предварительная версия)» и выберите «Запуск от имени администратора».

Только что заметил, что в этом случае в подсказке UAC говорится: «Неизвестная программа».

Довольно неожиданно, если вы спросите меня...

@sba923 это #2289 :smile:

@ DHowett-MSFT спасибо за информацию; приятно знать, что это (уже) отслеживается.

Лучший ответ на это, который я могу придумать, - это иметь возможность иметь профиль, который должен быть повышен, и если текущие окна не повышены, запустить новый экземпляр с повышенными правами с этим профилем. (Подумайте, как работают приватные сеансы просмотра)

Очень хорошая идея

Я использовал этот способ, чтобы добавить Терминал в меню Win + X:
Создайте новый ярлык с целью:
C:\Windows\explorer.exe shell:appsFolder\Microsoft.WindowsTerminal_xxxxxxxxxxxx!App
редактировать:
Извините, это не сработает, если вы хотите запустить приложение от имени администратора.
Вместо этого вы можете использовать nircmd и создать ярлык с
cmd.exe /q /c nircmd elevate "shell:appsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App"

(правильный путь для "Microsoft.WindowsTerminal_xxxxxxxxxxxx" можно узнать с помощью команды PS "Get-appxpackage *WindowsTerminal*", используйте запись в PackageFamilyName)

Этот ярлык можно использовать для запуска терминала с правами администратора простым двойным щелчком мыши, а с помощью WinXEditor его можно добавить в меню Win+X.
Примечание: Терминал также должен быть установлен под учетной записью администратора.

Идея загружать каждый профиль от имени администратора или только определенные? В идеале я хотел бы иметь его по индивидуальному профилю. Может быть, свойство, которое является учетной записью «runas», а другое - «iselevated»?

Как подробно обсуждалось в этой теме, вы не можете иметь сочетание повышенных и неповышенных прав в одном и том же экземпляре терминала Windows, и это не будет добавлено.

Действительно, я исправляюсь.
Чего _is_ не хватает, так это записи «запуск от имени администратора» в контекстном меню ярлыка панели задач.

На панели задач дважды щелкните правой кнопкой мыши. Один раз на значке, чтобы появилось контекстное меню, затем второй раз на имени приложения. например, «Терминал Windows (предварительная версия)» и выберите «Запуск от имени администратора».

FWIW, я только что протестировал сдвиг и щелчок правой кнопкой мыши, который сразу же дает опцию «Запуск от имени администратора» - лишь немного быстрее, чем вариант с двумя щелчками правой кнопкой мыши, который раньше был моим выбором.

Эй, ребята, вы забыли UAC? Приложение не может нажимать объекты на безопасном рабочем столе.

FWIW, я только что протестировал сдвиг и щелчок правой кнопкой мыши, который сразу же дает опцию «Запуск от имени администратора» - лишь немного быстрее, чем вариант с двумя щелчками правой кнопкой мыши, который раньше был моим выбором.

Вы также можете Ctrl + Shift + щелчок левой кнопкой мыши по значку, чтобы мгновенно вызвать UAC.

Потрясающе, спасибо большое! Сколько ярлыков мы должны запомнить? ;-)

К вашему всеобъемлющему замечанию о том, что «запуск от имени другого пользователя» не существует / не работает: это ограничение платформы, которое мы пытаемся снять. Мы не поддерживаем его не по злому умыслу или некомпетентности.

Что касается того, почему другие консольные приложения _поддерживают_ его, это не является небезопасным, когда они это делают, потому что они специально не размещают разные уровни прав в одном и том же окне. Это основная проблема здесь. Поскольку они размещаются в автономных процессах с автономными окнами, на них не распространяются ограничения на манипуляции на уровне целостности.

Определенно надеюсь, что когда-нибудь появится возможность работать под другим пользователем. Хотя это не большая часть моей повседневной деятельности, некоторые командлеты powershell требуют повышения прав (и я работаю с разными пользователями, думаю, с администратором защищенного пользователя).

Это не конец света, но, безусловно, будет раздражать необходимость вернуться к устаревшим оболочкам.

Думаю, со временем!

Нет абсолютно никаких проблем / ограничений с использованием Windows Terminal с повышенными правами, поэтому нет необходимости придерживаться «устаревших оболочек» (или, если быть более точным: устаревшего хоста консоли).

Просто вы не можете смешивать повышенные и неповышенные права в (на разных вкладках внутри) одного и того же экземпляра .

Нет абсолютно никаких проблем / ограничений с использованием Windows Terminal с повышенными правами, поэтому нет необходимости придерживаться «устаревших оболочек» (или, если быть более точным: устаревшего хоста консоли).

Просто вы не можете смешивать повышенные и неповышенные права в (на разных вкладках внутри) одного и того же экземпляра .

Я предполагаю, что, возможно, неправильно истолковал вышеизложенное, но есть ограничение платформы, связанное с запуском терминала в совершенно другом пользовательском контексте, чем то, что я читаю.

Я предполагаю, что, возможно, неправильно истолковал вышеизложенное, но есть ограничение платформы, связанное с запуском терминала в совершенно другом пользовательском контексте, чем то, что я читаю.

Да, эта тема была повсюду на доске по этому вопросу. Я не являюсь администратором на своих рабочих станциях, поэтому «запуск от имени администратора» просто предлагает мне ввести мои «повышенные учетные данные».

Вероятно, нам следует просто создать новую ветку об этом варианте использования.

Чтобы было ясно, я имею в виду (и я думаю, что это нужно многим «админам») возможность войти на нашу рабочую станцию ​​как обычный пользователь. Затем запустите «некоторую оболочку» от имени пользователя с повышенными правами, например, администратора домена, чтобы выполнить работу с AD.

Правильно это или неправильно, это то, что некоторые из нас делают и в чем нуждаются. Все ухищрения с установкой Консоли из магазина под этим пользователем и придумыванием хитрых ярлыков у меня не особо сработали.

И да, я могу сделать это несколькими способами, и, возможно, мне следует ограничить некоторые из этих действий защищенной рабочей станцией, но на самом деле, как обычному пользователю, мне вообще не нужна оболочка.

IMVHO путаница возникает из-за того факта, что люди (удерживая привычки, предшествующие Vista, сильно умирают) более или менее взаимозаменяемо используют термины «повышенный» и «как другой [домен] [администратор] пользователь».

Запуск от имени другого пользователя — это не то же самое, что запуск с повышенными правами.

1. Некоторым участникам этой темы при входе в систему с правами администратора необходимо запускать рабочие нагрузки Windows Terminal с повышением прав.

2. Некоторым другим людям необходимо при входе в систему как обычный пользователь (или не администратор домена) запускать рабочие нагрузки Windows Terminal от имени другого пользователя-администратора, обычно с правами доступа.

3. Можно также рассмотреть случай, когда люди вошли в систему как обычный пользователь A и хотят запускать рабочие нагрузки Windows Terminal от имени пользователя B без повышения прав.

В № 2 и № 3 развертывание на основе Магазина Windows делает историю более сложной, потому что Терминал Windows не будет работать от имени пользователя, вошедшего в систему, где для этого пользователя развернуты «приложения магазина».

Надеюсь, я правильно понимаю ситуацию. Если я это сделаю, я надеюсь, что это немного прояснит вопрос.

Вы точно поняли.

Просто к вашему сведению, именно эта проблема: невозможность повышения («Запуск от имени администратора», в отличие от запуска от имени другого пользователя с правами администратора, «Запуск от имени другого пользователя»), когда учетная запись, с которой вы вошли в систему, не является локальным администратором в системе, в соответствии с передовой практикой) был кратко рассмотрен в другом выпуске: https://github.com/microsoft/terminal/issues/1538 . Это было закрыто с объяснением того, что это проблема Windows, а не проблема Терминала, поскольку это кажется ограничением приложений Магазина.

Не вдаваясь в дебаты о том, нужно ли было выпускать это как установку MSI вместо использования Магазина, в той ветке, которую я использовал, есть обходной путь; ненадолго войдите в систему под своей учетной записью администратора, установите приложение из Магазина, а затем снова выйдите из системы. Затем запуск от имени администратора работал для моей обычной учетной записи пользователя (до следующего обновления, когда это нужно будет сделать снова).

Да, должен быть доступен MSI. Мой новый работодатель запрещает (общедоступные) установки из Магазина, поэтому единственным способом, которым я смогу использовать Windows Terminal, будет сборка из исходного кода...

Разочарован, увидев, что вы не можете запустить Windows Terminal «от имени администратора» без ошибок, а затем вам нужно реализовать обходной путь. Я бы сказал, что многие компании реализуют подход с разделением привилегий для удостоверений (с сотрудниками ИКТ, имеющими привилегированную и непривилегированную учетную запись). Таким образом, возможность удовлетворить это требование, предоставив дополнительное развертывание MSI в соответствии с предложением @ sba923 , была бы аккуратным подходом до тех пор, пока связанные с магазином приложения не смогут справиться с разделением привилегий?

Это ПРЕДВАРИТЕЛЬНЫЙ ПРОСМОТР, даже не версия 1.0...

Я чувствую, что эта тема была достаточно хорошо обсуждена на данный момент, но есть одна точка зрения, которую я еще не понял: почему мы не можем создать ярлык Windows для этого приложения? Это типичный обходной путь «всегда запускать от имени администратора» — типичный обходной путь — создать ярлык и изменить ярлык, чтобы использовать повышенный доступ по умолчанию.

Может кто-нибудь объяснить мне, почему мы не можем создать ярлык для этого приложения? Это, вероятно, больше связано с внутренней работой Windows, чем с внутренней работой Терминала, но я чувствую, что мы ходим вокруг да около, если я не спрошу об этом прямо.

Спасибо.

Я держу nircmd в своей папке c:\utils вместе со многими другими часто используемыми инструментами.
Я добавил профиль, который выглядит так:

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

Он вызывает запрос на повышение прав UAC, а затем открывает административный экземпляр Windows Terminal. На данный момент это достойный обходной путь.

Честно говоря, меня бы устроила возможность помечать сеансы как повышенные и открывать их в новом окне.

Я пришел сюда в поисках аккуратного решения, но, похоже, его не существует, поэтому я просто поделюсь своим хакерским решением. Я добавил профиль для запуска powershell с повышенными правами:

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

Он открывается в отдельном окне, но выполняет свою работу.

Я чувствую, что эта тема была достаточно хорошо обсуждена на данный момент, но есть одна точка зрения, которую я еще не понял: почему мы не можем создать ярлык Windows для этого приложения? Это типичный обходной путь «всегда запускать от имени администратора» — типичный обходной путь — создать ярлык и изменить ярлык, чтобы использовать повышенный доступ по умолчанию.

Может кто-нибудь объяснить мне, почему мы не можем создать ярлык для этого приложения? Это, вероятно, больше связано с внутренней работой Windows, чем с внутренней работой Терминала, но я чувствую, что мы ходим вокруг да около, если я не спрошу об этом прямо.

Спасибо.

@aaronsteers , вы правы, это больше о Windows, чем о Терминале. Основная проблема здесь в том, что мы распространяются и устанавливаются как «современный пакет приложений». У них есть ряд ограничений и случайных ограничений по сравнению с собственными приложениями, но это необходимо для терминала, поскольку это также наименее сложный способ использования компонентов «современного Windows API» (WinRT). Это ужасно расстраивает всех в команде почти все время. :улыбка:

Мы пытаемся превратить это разочарование и разочарование сообщества в продвижение платформы. Я приношу извинения, однако, это изменение не быстро здесь, в Windows!

@DHowett Я действительно пытаюсь понять, потому что мне на 2/3 нравится Терминал, но он не делает некоторых основ, к которым я привык с TakeCommand или ConEmu и т. д.

Я не могу смешивать высоты на разных вкладках. Насколько я понимаю, это потому, что вы представляете собой приложение другого типа и на самом деле не размещаете оболочку?

Буфер обратной прокрутки никогда не очищается ни в одной из трех сред (cmd, PowerShell, wsl bash). Это происходит в моих обычных оболочках. Опять же, из-за того, как он размещен?

И было бы неплохо иметь более доступное контекстное или выпадающее меню. Например, чтобы очистить эту прокрутку, учитывая, что даже трюк с выходом из консоли у меня не сработал.

Интеграция сред и то, насколько хорошо он воспринимает оболочки WSL Linux, действительно хороши. Но это дорого обходится из-за проблем с повышением прав и прокруткой, поэтому я редко его использую.

@robomac Здесь есть отличный пост от @DHowett-MSFT , в котором объясняется, почему мы не можем смешивать вкладки с повышенными и неповышенными правами в одном и том же окне без повышенных прав.

Вкратце: если мы разрешили пользователям подключаться к командным строкам с повышенными правами из окна терминала без повышенных прав, то это создало бы гигантскую дыру в безопасности, где другие приложения без повышенных прав могли бы эффективно управлять процессом с повышенными правами через окно терминала.

Я не знаю, как ConEmu снижает этот риск, если вообще снижает. Вполне возможно, что conemu создает дыру в безопасности, которую нам неудобно поставлять как часть Windows Terminal.

Остальные ваши проблемы — это все проблемы, которые отслеживаются в других местах этого репозитория, я предлагаю искать их, чтобы отслеживать их прогресс по отдельности. Мы бы предпочли, чтобы эта ветка была посвящена одной теме «смешанное повышение прав вкладок» / «наличие профиля, который запускает повышенные права».

По теме: я хочу поэкспериментировать с маршрутом «запустить другой экземпляр с повышенными правами» для «повышенных» профилей. Если пользовательский опыт не так уж плох, то это возможный путь вперед, по крайней мере, как вариант.

ConEmu не снижает этот риск. Они перекладывают этот риск на своих пользователей. (Я даже не уверен, что они документируют этот риск.)

По теме «запустить другой экземпляр с повышенными правами»: я бы не возражал против такого поведения, если он может использовать один и тот же экземпляр терминала с повышенными правами для этих вкладок и не запускать новый экземпляр каждый раз, когда я вызываю «повышенный» профиль.

На мой взгляд, "великанство" этой дыры в безопасности несколько преувеличено. Ненормально иметь вредоносное ПО на своем компьютере, которое сидит и ждет возможности получить повышенные права, поэтому жертвовать удобством ради безопасности не кажется правильным.

С другой стороны, если конечная цель состоит в том, чтобы WT поставлялся с Windows в качестве терминала по умолчанию, это значительно увеличило бы поверхность атаки. Но опять же, в этом случае лично я бы снизил риск, используя непопулярную альтернативу, которая вряд ли станет целью такой атаки и обеспечивает требуемое удобство (при условии, что обнаружение наличия привилегированной вкладки в терминале достаточно нетривиально). быть специфичным для терминала).

Кое-что из этого для меня tl;dr, но если вы возьмете и сделаете дамп пакета, вы сможете запустить wt вне песочницы, что означает повышение прав, и работать под разными пользователями без проблем. Я говорил об этом с MSFT в ignite, и мне сказали отправить запрос на включение, но мои навыки VS довольно слабы. Что было бы достаточно просто сделать, так это правильно подписать его (пришлось сделать это с моей собственной внутренней pki, чтобы я мог работать на applocker) и поместить его в распространяемый формат MSI или MSIX. Здесь или там есть странная ошибка, которая может быть специфичной для этого способа, но в целом он работает очень хорошо. На данный момент у меня есть только функция для извлечения, подписи и замены/обновления версии на основе программных файлов из версии на основе магазина.

Я понимаю риск этой функции «подключения» вкладок с повышенными правами к процессу без повышенных прав, но нельзя ли пойти наоборот?
Имею в виду людей, как это нужно, пусть сам Терминал также работает с повышенными правами и позволяет запускать вкладки без повышенных прав?
Конечно, есть и другие минусы, но для меня (и, думаю, для других тоже) они приемлемы.
(конечно, это может быть «интересно», так как терминал — это приложение для магазина Windows, не уверен, что это работает)

Пс. Извините за повторное открытие этой проблемы (также, если другой человек уже сделал это предложение, и я «перечитал» его).

Благодаря @EmTschi я сделал простое и на 100% удобное решение
Он использует контекстное меню и действует почти так же, как PowerShell 7.
https://github.com/nt4f04uNd/wt-контекстное меню
Там вы можете найти руководство по его реализации и все необходимые файлы.

Спасибо за подсказку, позже попробую.
В настоящее время я работаю с двумя ярлыками на своем рабочем столе, которые сопоставлены с клавишами Ctrl+Alt+T и Ctrl+Alt+Shift+T для терминала с повышенными правами, это также нормально в качестве обходного пути, но... не так приятно как это могло бы быть и далеко от чего-то вроде sudo.

@

Всякий раз, когда я пытаюсь запустить приложение «Терминал» с учетной записью администратора, щелкните правой кнопкой мыши -> запустить от имени администратора, UAC появляется дважды, и возникает ошибка:
«Windows не может найти (путь\WindowsTerminal.exe) Убедитесь, что вы ввели ...".
Путь существует, и приложение работает правильно для пользователя без прав администратора, создавшего приложение, но другой пользователь с правами администратора не может его запустить.
Если я вхожу в систему с правами администратора, приложение терминала отсутствует ни в настройках, ни в меню «Пуск», как будто оно никогда не устанавливалось в системе.
Есть ли способ создать приложение, чтобы оно устанавливалось для всех пользователей? Или корень проекта должен находиться в каталоге, не зависящем от пользователя?

Я также вижу ту же проблему.

Версия Windows 18922.1000

Только что установил на Win10 обновление 1909, и у меня та же проблема с попыткой запустить от имени администратора.

Та же проблема здесь. Теперь я не могу использовать терминал Windows, потому что мне всегда нужно запускать докер, а затем мне всегда нужно быть администратором в терминале...

У меня есть обходное решение для всех, кто хочет:

1. загрузите msixbundle со страницы выпуска
2. разархивируйте его, найдите там msix для своей платформы (обычно x64)
3. распаковать куда-нибудь в папку
4. скопируйте эту папку куда угодно и запустите WindowsTerminal.exe с повышенными правами или как угодно

Похоже, что многие из этих недостатков связаны с удобством использования этого приложения в качестве магазина. Это обсуждалось на #1386, и кто-то там упомянул, возможно, об установке с помощью Scoop, который автоматизирует описанный выше процесс извлечения.

Было бы неплохо, если бы к следующим гражданам относились как к гражданам первого сорта:

1. Переносимые установки (zip-файлы — даже если конфигурация еще не является переносимой, так как она находится в папке AppData\Local при запуске из области установки магазина Windows)
2. Обычный старый установщик .exe (или, если нужно, .msi) для людей, которым не нужен магазин или не нужен установщик магазина.

И то, и другое не так сложно реализовать из текущей процедуры сборки, о чем свидетельствует автоматизация Scoop. И теперь, когда Windows Terminal становится действительно довольно хорошим, я хотел бы иметь возможность использовать его так же, как и любой другой терминал.

Пока мы на этом: если нет несовместимости API, было бы здорово иметь возможность установить Терминал Windows без Магазина (даже «портативный») в более ранних версиях Windows 10 (мой работодатель блокирует нас по адресу 1809/ RS5, а установка из Магазина заблокирована).

@ sba923 , если бы мы не полагались на API, которые существовали только в 1903 году, нам бы не потребовался 1903 год.

Конечно... было моим предположением 😜

Придется лоббировать апгрейд в масштабах всей компании, возможно, упрется в стену...

Это так глупо.

Давайте создадим новый унифицированный терминал для командной строки, powershell и bash для Windows.
Могу ли я запустить cmd.exe от имени администратора?
Нет.

Думаю, я просто оставлю свои значки cmd.exe и powershell предустановленными для запуска от имени администратора на панели задач на неопределенный срок.

Подобные глупости — вот почему моя основная рабочая машина по-прежнему остается Macbook.

Это так глупо.

Давайте создадим новый унифицированный терминал для командной строки, powershell и bash для Windows.
Могу ли я запустить cmd.exe от имени администратора?
Нет.

Думаю, я просто оставлю свои значки cmd.exe и powershell предустановленными для запуска от имени администратора на панели задач на неопределенный срок.

Подобные глупости — вот почему моя основная рабочая машина по-прежнему остается Macbook.

Я согласен в этом случае. Мне нужно одно окно терминала Windows, в котором размещены все необходимые мне вкладки терминала, где каждая вкладка терминала может быть одной из нескольких установленных хостов терминалов, а также быть повышена или нет.

Действительно кажется, что эта функция смешанной высоты сдерживается техническим решением по размещению всех вкладок на одном дескрипторе HWND.

1) Можно ли запустить новый терминал от имени администратора? ДА (есть проблемы, связанные с этим, в зависимости от того, как вы его установили / запустили, но нет желания, чтобы это не работало). (Если вы не знаете, как это сделать, см. несколько сообщений выше о том, как это сделать.

2) Может ли у вас быть одна вкладка с повышенными правами, а другая нет? нет . См. https://github.com/microsoft/terminal/issues/632#issuecomment -519375707, почему.

Люди, пожалуйста, помните, что эта проблема касается вкладок со смешанными высотами?!? Если вы хотите запустить весь процесс с повышенными правами и не можете открыть новую проблему.

@ DHowett-MSFT Можем ли мы переименовать эту проблему, чтобы она касалась смешанных вкладок высоты?

Независимо от того, как это обрабатывается или нет, повышенные терминалы или вкладки должны иметь какой-то индикатор. Теперь, если я запускаю новый терминал с помощью «Запуск от имени администратора», невозможно легко заметить, что мои вкладки cmd имеют повышенный доступ по сравнению с вкладками в следующем окне.

РЕДАКТИРОВАТЬ после комментария @SamuelEnglard : Очевидно, я поспешно выбрал cmd в качестве плохого примера. Да, cmd показывает «Администратор:» в заголовке вкладки. Но WSL Ubuntu bash на моей вкладке по умолчанию перезаписывает все, что может быть в заголовке этой вкладки. Я предполагаю, что bash не знает (или даже не заботится) о повышении прав Windows Terminal, поэтому эту информацию нельзя использовать при обновлении заголовка из bash (конечно, sudo ситуация, но это другое дело).

В Терминале profiles.json есть
"showTabsInTitlebar": false
но с этой настройкой строка заголовка терминала не сигнализирует о высоте.

@janilahti , вкладки CMD с повышенными правами не похожи
для тебя?

Безопасность - спорный вопрос, если никто не хочет использовать ваш инструмент...

Вам нужно просто сделать команду sudo для Windows, которая работает как в cmd.exe, так и в powershell. Это избавило бы меня от необходимости иметь ярлык для обоих, настроенных для запуска от имени администратора.

К вашему сведению, я написал sudo for windows под названием gsudo : https://github.com/gerardog/gsudo

Он поддерживает повышение прав команд cmd / powershell / pwsh или всей оболочки. Его легко установить и использовать, и он должен напоминать оригинальный * nix sudo. Существуют и другие реализации sudo , но, ИМХО, gsudo является наиболее универсальной и простой в использовании.

Вы можете использовать его, например, для создания профиля WT, который вызывает gsudo cmd / gsudo pwsh или gsudo WhateverShell для запуска повышенных вкладок. Установите gsudo и добавьте профиль WT:

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

Это клиент-серверное приложение C#, которое действует как клиент, когда не имеет повышенных прав, и запускает себя с повышенными правами как сервер. Оба экземпляра обмениваются данными через защищенные именованные каналы. Другие sudo в Windows в дикой природе в основном похожи на сценарии PowerShell «runas», которые открывают новое окно, но, будучи полноценным приложением, я мог добавить гораздо больше функций.

Я прочитал ветку, и безопасность команды sudo обсуждалась, и были сделаны некоторые обоснованные замечания. Я предпринял все меры безопасности, о которых только мог подумать, и я готов (и планирую) ввести больше таких мер. На этом этапе он должен быть таким же безопасным/небезопасным, как если бы вы открывали сеанс удаленного администрирования PS или выполняли ssh root@server с консоли без повышенных прав. (например, уязвим для нажатия клавиш или очистки экрана, и поправьте меня, если я ошибаюсь, но я понимаю, что * nix sudo также уязвим в этом отношении). Существует также кеш учетных данных, который уменьшает количество всплывающих окон UAC в течение 5-минутного сеанса (вдохновлено * nix sudo), что явно является вектором атаки, который можно отключить с помощью конфигурации. Для тех, кто беспокоится о безопасности, я планирую добавить очень простой способ ужесточить ее (путем отключения таких функций, как кеш учетных данных) с помощью простой команды или через настройку корпоративной групповой политики/реестра.

Один интересный момент, сделанный в этом комментарии , заключается в том, что Microsoft не может позволить себе «принятие на себя риска ради удобства пользователя». Если это последнее слово от MS, то, по крайней мере, это выглядит как достойное (полнофункциональное) обходное решение, и все отзывы/ проблемы или идеи о том, как улучшить безопасность, приветствуются.

Не может быть что-то, что я должен установить, что официально не поддерживается. Убивает любую возможность использовать его в корпоративной среде.

Тогда @hparadiz вам придется подождать, пока не будет выпущена новая версия Windows с новым дизайном безопасности, который позволяет использовать официальные вкладки sudo (или вкладки со смешанными правами) без угроз безопасности. Похоже, это произойдет не скоро. Лучше всего подождать, пока весь WT не будет запущен от имени администратора, отслеживаемый в # 4217, который, вероятно, будет выпущен раньше.

Нашел хороший хак из блога:

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

@gerardog , у тебя есть ведро на gsudo ? или это в одном из известных? Я сейчас на Linux, так что не могу проверить.

@fluffynuts Это в основном репозитории. Так что просто «scoop install gsudo». Также другие способы установки перечислены на https://github.com/gerardog/gsudo . Но давайте продолжим это обсуждение на тему WT. 😉

Открытый вопрос: если смешивание вкладок с повышенными и неповышенными правами представляет угрозу безопасности, то присутствует ли этот риск в ConEmu ? Потому что он может сделать именно это. Или ConEmu реализует эту функцию иначе, чем в Терминале? И в более широком смысле я хотел бы отметить, что многие из запрашиваемых здесь функций (в этой теме и других) уже существуют в других терминалах, ConEmu является лишь одним из примеров, поэтому, когда разработчики терминала предполагают, что эти функции либо никогда не будут реализованы, либо не будут реализованы для очень долгое время, вы просто косвенно подтверждаете, что мы не должны использовать Терминал.

если бы мы не полагались на API, которые существовали только в 1903 году, нам бы не потребовался 1903 год.

@ DHowett-MSFT Есть ли общедоступная документация о том, что это за API и зачем они нужны? Потому что как сторонний наблюдатель, когда я вижу это решение и решение использовать UWP, я не вижу добавленной стоимости. Я просто вижу препятствия на пути добавления того, что многие корпоративные пользователи считают базовой функциональностью.

@dadpolice См. https://github.com/microsoft/terminal/issues/632#issuecomment -518888895, чтобы узнать, что делает ComEmu.

Я думал, что «UAC не является барьером безопасности», согласно Microsoft? Это рассматривалось как одно в Висте. Затем нам сказали, что это не так, и любые подобные проблемы были шуткой в ​​​​Windows 7. Теперь это снова сегодня?

Возможно, вам нужно пересмотреть дизайн File Explorer и белый список UAC в этом случае. :)

Или это просто зависит от того, является ли это предлогом для упрощения разработки чего-то, что не разрешено делать обычным разработчикам (Проводник), или не реализации важной функции (в данном случае)?

не реализовать важную функцию (в данном случае)?

Хочу пояснить: мы не пытаемся _не_ реализовать эту функцию. Это, безусловно, важная функция, которую мы _хотим_ реализовать. Это то, с чем я сталкиваюсь ежедневно прямо сейчас — иметь второе окно с повышенными правами — это _хорошо_, но это не _хорошо_.

Просто нам потребуется некоторое время, чтобы спроектировать безопасное решение, а затем приложить инженерные усилия для его фактической реализации. Это то, что мы нарисовали на доске даже на этой неделе.

@zadjii-msft

[...]
Я не думаю, что мы планируем поддерживать смешанные вкладки с повышенными и неповышенными правами, потому что это немного дыра в безопасности.
[...]

(чтобы связать связанные темы, # 146)

Странно, что у людей сложилось впечатление, что эта функция не будет реализована. знак сарказма

@ kort3x Есть разница между «Нет плана» (иначе говоря, мы этого не обещаем) и нежеланием и тем, что они могут сделать, найти способ реализовать это.

Как сказал @zadjii-msft:

Просто нам потребуется некоторое время, чтобы спроектировать безопасное решение, а затем приложить инженерные усилия для его фактической реализации. Это то, что мы нарисовали на доске даже на этой неделе.

Пока у них нет безопасного решения, они не будут планировать (т. е. обещать) поддержку вкладок со смешанными правами. Я готов быть уверенным, что, как только появится безопасное решение, они добавят его в план (хотя я ничего не обещаю).

Я думал, что «UAC не является барьером безопасности», согласно Microsoft? Это рассматривалось как одно в Висте. Затем нам сказали, что это не так, и любые подобные проблемы были шуткой в ​​​​Windows 7. Теперь это снова сегодня?

Насколько я понимаю, это барьер безопасности, если он настроен как «Всегда уведомлять», иначе это не так.

Что ж, это разочаровывает. Мне нравится терминал (что говорит о многом, так как я вообще в восторге от инструментов, отличных от MS), но невозможность плавного повышения уровня является реальным препятствием для того, чтобы я мог больше работать с этой ОС.

LOL хорошо, да, я вижу, как это сбивает с толку. Первоначально я написал этот комментарий через несколько дней после того, как мы впервые объявили об этом, когда еще не было плана. После нескольких месяцев обсуждений я, конечно же, пришел к мысли, что это возможно, если приложить больше усилий. Я обновлю комментарий, чтобы отразить это. @SamuelEnglard прав, хотя трудно _обязаться_ сделать это, пока мы _знаем_, что это возможно сделать правильно.

Это обнадеживает. Можно ли распространить этот энтузиазм на другие команды, чтобы #3581 действительно можно было исправить?

Было бы неплохо, если бы вкладкам было разрешено быть разными процессами (аналогично тому, как хром управляет этим), в первую очередь, потому что тогда мне не пришлось бы перезапускать все вкладки после их красивой группировки, просто чтобы получить обновленную среду в одном вкладка команд...
Когда терминал Windows становится просто менеджером, он может работать в режиме без повышенных прав, сохраняя при этом командные строки с повышенными правами. Это было бы чудесно. (ну, если wt работает с повышенными правами, удерживая терминалы без повышенных прав, для меня это тоже нормально)

@ rapus95 технически это вкладки, поскольку «консоль» - это другой процесс. Windows Terminal уже просто менеджер

РЕДАКТИРОВАТЬ (14 февраля 2020 г.)
Итак, этот комментарий не очень хорошо устарел. Первоначально не было плана по поддержке этого, так как это не сработает с единственным HWND , который у нас был. Мы работаем над созданием решения, которое _могло бы_ поддерживать это в будущем, но мы не можем брать на себя никаких обязательств, пока не будем уверены, что сможем предложить достаточно безопасное решение, которое гарантирует, что процесс с более низким уровнем привилегий не сможет управлять терминалом с более высокими привилегиями.

Помимо некоторых других моментов, это основная причина, по которой я все еще использую ConEmu . И я уверен, что когда-нибудь буду.
https://conemu.github.io/ @Maximus5

Это так глупо.

Давайте создадим новый унифицированный терминал для командной строки, powershell и bash для Windows.
Могу ли я запустить cmd.exe от имени администратора?
Нет.

Подобные глупости — вот почему моя основная рабочая машина по-прежнему остается Macbook.

@hparadiz Взгляните на ConEmu :-D Нет проблем с запуском нескольких оболочек как вкладок в ОДНОМ окне; даже запуск сеансов Powershell и cmd.exe с повышенными правами помимо сеансов без повышенных прав.

@tmeckel мы уверены, что у conemu нет уязвимостей безопасности, о которых беспокоится команда терминала? пользователи часто выбирают менее безопасное программное обеспечение, потому что оно делает то, что им нужно, но на свой страх и риск.

@drdamour @tmeckel Так и есть. Я задал тот же вопрос выше, на него ответили в другой ветке: https://github.com/microsoft/terminal/issues/632#issuecomment -518888895

До сих пор я довольно критически относился к Terminal, но, честно говоря, ConEmu, ConsoleZ и другие подобные инструменты уже существуют. В Microsoft мало смысла просто копировать их, но есть большая ценность в воссоздании этих функций безопасным способом. Тем не менее, я все еще думаю, что очень глупо создавать эмулятор терминала как приложение UWP только для магазина, особенно сейчас, когда Microsoft, похоже, отходит от UWP (например, новый Edge — это приложение Win32).

Тем не менее, я все еще думаю, что очень глупо создавать эмулятор терминала как приложение UWP только для магазина, особенно сейчас, когда Microsoft, похоже, отходит от UWP (например, новый Edge — это приложение Win32).

Чтобы было ясно, терминал не предназначен только для магазина ( здесь доступны файлы .msix ) и не является приложением UWP. Это приложение Win32, использующее UWP XAML в качестве инфраструктуры пользовательского интерфейса.

@ rapus95 технически это вкладки, поскольку «консоль» - это другой процесс. Windows Terminal уже просто менеджер

Тогда почему среда не обновляется для нового экземпляра cmd? Мне всегда нужно открывать новый терминал Windows, что в некотором смысле снижает общее удобство использования нескольких вкладок...

@ rapus95 , хотя я не уверен (мне придется копаться в коде), я почти уверен, что каждый подпроцесс запускается с родительской средой, а не с новой.

это не похоже на управление терминалом 🤔

@rapus95 На самом деле это ошибка, которую мы отслеживаем здесь: #1125.

Чтобы было ясно, терминал не предназначен только для магазина ( здесь доступны файлы .msix ) и не является приложением UWP. Это приложение Win32, использующее UWP XAML в качестве инфраструктуры пользовательского интерфейса.

Это просто звучит как UWP с дополнительными шагами. Что бы это ни было, я не могу щелкнуть правой кнопкой мыши Терминал и запустить его от имени другого пользователя, как я могу с любым обычным приложением Win32, это был странный выбор.

Это не приложение UWP и не приложение только для магазина.
Просто так получилось, что одним из способов распространения является Магазин, для которого требуется пакет UWP.
Только те, кто установил его с помощью магазина, не могут Right click -> Run As Admin .
Удалите и используйте msix или через совок

Удалите и используйте msix или через совок

Или chocolatey .

@gerardog Я не говорил «запуск от имени администратора», я сказал «запуск от имени другого пользователя».

Вам не подходит Shift + Right Click ?

(Обратите внимание, что я установил с помощью scoop )

Нет. Я установил с помощью пакета msix, и этой опции там нет.

Я установил как шоколадный и не запускал от имени администратора.

Чтобы было ясно, терминал не предназначен только для магазина ( здесь доступны файлы .msix ) и не является приложением UWP. Это приложение Win32, использующее UWP XAML в качестве инфраструктуры пользовательского интерфейса.

Это просто звучит как UWP с дополнительными шагами. Что бы это ни было, я не могу щелкнуть правой кнопкой мыши Терминал и запустить его от имени другого пользователя, как я могу с любым обычным приложением Win32, это был странный выбор.

То же самое здесь, я пробовал и msix, и магазин приложений. У меня по-прежнему нет опции «Запуск от имени другого пользователя».

Как насчет того, чтобы сделать цвет фона всех повышенных вкладок красным, чтобы было очевидно, что он повышен?

Я бы предпочел, чтобы это настраивалось: цвет фона, заголовок вкладки...

https://github.com/gerardog/gsudo прекрасно работает как временное решение.

Возможно, реализовать что-то вроде wt elevated , которое открывает новое окно с повышенными правами с текущей оболочкой в ​​той же среде.
РЕДАКТИРОВАТЬ: или # 3158, но как новое окно и с повышенными правами

Я не понимаю, почему бы вам не скопировать так, как это делает Linux.

Насколько я понимаю или в мире Linux (поправьте меня, если я ошибаюсь), терминальные приложения (gnome-terminal, mate-terminal...) не нужно повышать, даже если вы вводите su или sudo и выполняете команду как пользователь root. Единственная задача терминального приложения — запустить оболочку в другом процессе (bash, ksh...), который имеет или не имеет повышенных прав, и перенаправить ввод и вывод оболочки, чтобы мы могли взаимодействовать с оболочкой.

Если вы наберете «su» или начнете команду с «sudo» в терминале Linux, другое окно не откроется.

@gabsoftware Я не уверен в безопасности этого даже в Linux. В Linux также можно отправлять нажатия клавиш в X-окнах, и я предполагаю, что можно отправлять нажатия клавиш терминальным клиентам, работающим в X-окне, даже если работающий терминал повышен с помощью sudo или su. Возможно, даже можно будет отправлять нажатия клавиш на X-окна с повышенными правами, но я точно не знаю.

Чтобы было ясно, терминал не предназначен только для магазина ( здесь доступны файлы .msix ) и не является приложением UWP. Это приложение Win32, использующее UWP XAML в качестве инфраструктуры пользовательского интерфейса.

Это просто звучит как UWP с дополнительными шагами. Что бы это ни было, я не могу щелкнуть правой кнопкой мыши Терминал и запустить его от имени другого пользователя, как я могу с любым обычным приложением Win32, это был странный выбор.

То же самое здесь, я пробовал и msix, и магазин приложений. У меня по-прежнему нет опции «Запуск от имени другого пользователя».

Я не могу «Запустить от имени другого пользователя», щелкнув правой кнопкой мыши плитку в меню «Пуск», но могу, если щелкну правой кнопкой мыши WindowsTerminal.exe

@gabsoftware Я не уверен в безопасности этого даже в Linux. В Linux также можно отправлять нажатия клавиш в X-окнах, и я предполагаю, что можно отправлять нажатия клавиш терминальным клиентам, работающим в X-окне, даже если работающий терминал повышен с помощью sudo или su. Возможно, даже можно будет отправлять нажатия клавиш на X-окна с повышенными правами, но я точно не знаю.

Я провел несколько экспериментов, и теперь я уверен в небезопасности этого в Linux. Я не эксперт по безопасности, поэтому я не уверен в последствиях этого (кто-нибудь?). Оказывается, очень легко отправлять нажатия клавиш в окна X, которые только что запустили sudo и открыты для новых команд sudo, не запрашивая пароль. Сообщение в блоге здесь , извините за позорную вилку...

Мой вывод будет заключаться в том, что если нет способа запретить отправку нажатий клавиш в окна со смешанными высотами, это должно быть реализовано только как вариант для пользователей, готовых принять риск (большие толстые предупреждающие знаки и т. д.).

В качестве примечания, как экранная клавиатура Windows отправляет нажатия клавиш в окна с повышенными правами?

Я выпустил gsudo v0.7 и имеет отношение к этой теме:

РЕДАКТИРОВАТЬ: Для контекста: gsudo — это sudo для Windows, который позволяет поднять простую команду или оболочку в текущей консоли. При вызове из Cmd/Pwsh в WT поднимает вкладку. Кроме того, вы можете отредактировать свой профиль, назвать его «Elevated Powershell» и изменить свою команду на gsudo Powershell и вуаля, у вас есть профиль с повышенными правами. Смотрите здесь .

Но поскольку gsudo или любой другой sudo для Windows преодолевает изоляцию UAC, он был помечен как «небезопасный». Далее следует более сложный обходной путь, который позволяет вам выполнять смешанные возвышения вкладок, сохраняя при этом безопасность. /КОНЕЦ ИЗМЕНЕНИЯ

gsudo теперь может запускать приложения с любым уровнем целостности. Например, мы можем запустить Windows Terminal с уровнем целостности MediumPlus , что означает «полу-повышенный» режим: без прав администратора, но изолированный, недоступный для других обычных (средний уровень целостности) процессов. (появится всплывающее окно UAC)

Итак, первый шаг должен состоять в том, чтобы всегда запускать WT с помощью: gsudo -i MediumPlus WT
(Вы можете изменить ярлык WT). Это защищает WT от вредоносных процессов, очистки экрана, отправки ключей, внедрения dll и т. д.
(EDIT: если это не работает, используйте: gsudo -n -i MediumPlus cmd /c cmd /c start wt )

Затем вы можете безопасно использовать gsudo в WT для повышения прав команд или даже создать профиль с повышенными правами с помощью: "commandline": "gsudo cmd.exe" в profiles.json

Мой вывод будет заключаться в том, что если нет способа запретить отправку нажатий клавиш в окна со смешанными высотами... это должно быть реализовано только как вариант для пользователей, готовых принять риск (большие толстые предупреждающие знаки и т. д.).

Готово и сделано. (Я добавил предупреждения безопасности в gsudo).

Кроме того, поскольку я узнал, что если пользователь вызывает gsudo из процесса обычной/средней целостности , то кеш учетных данных gsudo (функция для отображения меньшего количества всплывающих окон UAC) никогда не может быть полностью защищен... Итак, теперь учетные данные кеш должен быть явно включен через gsudo cache on/off или gsudo config cachemode auto .

Оказывается, "Changing your WT shortcut" вовсе не тривиально: учитывая модель MSIX/AppStore, вы столкнулись с #4217 и #4459.

Следующий сценарий powershell решает эти проблемы, создавая ярлык Windows Terminal на рабочем столе и связывая его с горячей клавишей 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()

После того, как вы запустили WT как MediumPlus (т.е. Ctrl+Alt+T), вы можете использовать gsudo, как указано выше (https://github.com/microsoft/terminal/issues/632#issuecomment-613751789) для повышения команд. в чем AFAIK должен быть безопасным.

В качестве обходного пути я использую _Sudo for Windows_ Люка Самсона . Конфигурация профиля:
"commandline": "pwsh.exe -Command sudo.ps1 pwsh.exe",
При открытии новой вкладки с этим профилем появляется всплывающее окно UAC, после чего вы оказываетесь в ядре Powershell с повышенными правами. Также работает с любым другим терминалом.
"commandline": "powershell.exe -Command sudo.ps1 powershell.exe",
"commandline": "powershell.exe -Command sudo.ps1 cmd.exe",
Если вы не используете scoop , я уверен, что эту концепцию можно извлечь и использовать независимо. Ознакомьтесь с исходным кодом здесь: https://github.com/lukesampson/psutils/blob/master/sudo.ps1 .

Я использую обходной путь schtasks для запуска Windows Terminal от имени администратора и обхода UAC:

1. Запустите планировщик заданий.
2. Создайте новую задачу. Дайте ему имя и установите флажок «Выполнять с наивысшими привилегиями».
   

3. На вкладке Действия выберите для запуска программы: wt

4. На вкладке «Настройки» убедитесь, что установлен флажок «Разрешить выполнение задачи по запросу», и снимите флажок «Остановить задачу, если она выполняется дольше».

5. Создайте ярлык, щелкнув правой кнопкой мыши на рабочем столе, выберите «Создать» -> «Ярлык» и введите schtasks.exe /run /TN "{task name}"
   
6. При желании измените значок ярлыка и перетащите его на панель задач.

Похоже, мне придется придерживаться cmder, пока это не будет исправлено.

теперь, когда есть намек на план, можем ли мы получить документы
обновлено, чтобы больше не говорить об отсутствии текущего плана?

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

@drdamour Когда _есть_ план, я бы хотел удалить этот раздел. Однако прямо сейчас есть только план исследования способа составить план. Как только появится реальный план и способ, которым мы сможем безопасно его реализовать, я удалю этот раздел.

Метод, описанный @KMoraz , на данный момент отлично работает в качестве обходного пути. Спасибо за публикацию.

Привет, народ,

Я использовал ConsoleZ, пока вчера не обнаружил это.
ConsoleZ имеет некоторые функции, и одна из них — открыть новую вкладку от имени администратора с помощью UAC (открывается диалоговое окно UAC).
Я нахожу это очень полезным, потому что вам не нужно отрывать руки от клавиатуры, чтобы открыть новую вкладку с повышенными правами.

Что, если бы это была конфигурация внутри конфигурации профиля? Вот как это делается в ConsoleZ.

Всем привет,

Я нашел еще один простой обходной путь, который отлично работает для тех, кому нужно вводить учетные данные локального администратора при запуске чего-либо от имени администратора.

Эта ссылка объясняет, но нужен полный путь для ссылки на wt.exe:
http://nuts4.net/post/windows-terminal-run-as-admin

Моя полная строка быстрого доступа: C:\Windows\System32\cmd.exe /c start /b C:\Users\myUserName\AppData\Local\Microsoft\WindowsApps\wt.exe

ОБНОВЛЕНИЕ 21 мая 2020 г.:
Вышеупомянутое работало до версии 1.0.1401.0.

См. также эту новую проблему: https://github.com/microsoft/terminal/issues/6013 .

Теперь щелчок Crtl-Shift НЕ работает, когда вам нужно повысить права с помощью локальной учетной записи администратора.

См. приведенный ниже снимок экрана с ошибкой, который я получаю после двойного запроса на повышение разрешений:

Для информации, imho gsudo идеально подходит для этого, спасибо https://github.com/microsoft/terminal/issues/632#issuecomment -613751789

В моей конфигурации есть только этот профиль для получения привилегий:

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

Для меня самый простой способ открыть Windows Terminal от имени администратора — закрепить его в качестве первого элемента на панели задач. Затем Win+Ctrl+Shift+1 открывает его как администратор

Для меня самый простой способ открыть Windows Terminal от имени администратора — закрепить его в качестве первого элемента на панели задач. Затем Win+Ctrl+Shift+1 открывает его как администратор

Действительно очень удобно, но это работает только для учетных записей, которые входят в группу администраторов.

Если вы выступаете в качестве администратора для кого-то другого, вы не сможете запускать Windows Terminal в качестве своего пользователя (администратора) из его учетной записи.

Я думаю, было бы неплохо иметь одну настройку вкладки для запуска cmd от имени администратора, а не всего.

Я думаю, было бы неплохо иметь одну настройку вкладки для запуска cmd от имени администратора, а не всего.

Как объяснялось в другом месте здесь, это невозможно с текущим дизайном.

есть ли флаг, который можно использовать для запуска от имени администратора? Тогда мы могли бы просто создать для него ярлык.

Если вы закрепите Терминал Windows на панели задач, вы сможете запустить его с повышенными правами, используя Ctrl+Shift+щелчок.

Это будет делать то же самое, что щелкнуть правой кнопкой мыши значок, щелкнуть правой кнопкой мыши «Терминал Windows», а затем «Запуск от имени администратора».

Примечание. Терминал Windows является приложением Магазина, и вы не можете запустить его от имени _другого пользователя_.

Я хотел бы видеть возможность иметь «вкладки со смешанным уровнем целостности» в Windows Terminal, с уровнем целостности в качестве опции в каждом профиле. Это в основном для удобства моей обычной работы системного администратора/разработчика, чтобы свести к минимуму прерывания рабочего процесса и переключение контекста.

Я нашел простую альтернативу, которая работает для меня на данный момент. Это не касается всех сценариев, представленных здесь другими пользователями. Это не зависит от сторонних приложений, файлов ярлыков, комбинаций клавиш или запланированных задач. Это не требует определения местоположения исполняемого файла терминала Windows. Он просто делает отдельную запись в списке профилей Windows Terminal, которая запускает второй экземпляр Windows Terminal с повышенными правами. Это вызывает запрос UAC один раз. Я использую это только тогда, когда мне нужно повышение.

В результате два терминала Windows. В одном все стандартно, а в другом повышено. Для меня это приемлемый уровень прерывания и переключения контекста. Терминал Windows с повышенными правами также добавляет к заголовку каждой вкладки «Администратор:», что дает хорошее визуальное подтверждение разницы.

Изменить: у меня установлен Powershell 7,

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

@IarwainBen-adar, кажется, я недавно читал в новых документах, что вы не можете использовать элемент commandline и элемент source вместе. Работает ли он должным образом без элемента source ?

Я попробовал его код и не могу даже заставить новый элемент появиться в вытягивании
вниз меню.

@shem-sargent извините за это, я удалил свой комментарий здесь, потому что постороннее объявление source действительно было проблемой. Хотя теперь, когда у меня работает вход в меню, к сожалению, я все еще не могу запустить экземпляр Windows Terminal с повышенными правами — я столкнулся с проблемой № 3145 со сбоем The file cannot be accessed by the system.

@IarwainBen-adar Извините, я не могу воспроизвести № 3145. В противном случае я бы попытался устранить неполадки со своей стороны.

закрепить на панели задач и Shift+щелчок правой кнопкой мыши

Ура @LordFPL и, конечно же, @gerardog , я никогда раньше не слышал о gsudo (https://github.com/gerardog/gsudo для тех, кому это интересно), но теперь это делает сеансы с повышенными правами легким делом. Спасибо! Либо добавьте его в объект профиля в файле настроек, либо просто используйте псевдоним sudo , как в системе Linux. Идеально!

@zadjii-msft приношу свои извинения, но я не совсем понимаю, в чем здесь проблема. Windows поддерживает манипулирование токенами и олицетворение, не так ли работает runas? используя gsudo от @gerardog , я могу иметь низкую (более) целостность при размещении оболочки с высокой (более) целостностью в то же время, что и любую другую оболочку целостности уровня, будь то powershell, pwsh, cmd или любая оболочка wsl. Из моего ограниченного тестирования ни одна из оболочек с низкой (более) целостностью не может отлаживать эту оболочку с более высокой целостностью. Что препятствует использованию этой функции в качестве встроенного терминала или даже более предпочтительной на уровне ОС?

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

Окно с низкой (е) целостностью, принимающее входные данные и направляющее их непосредственно в процесс с высокой (е) целостностью, открывает этот процесс с высокой (е) целостностью для управления другими объектами с низкой (е) целостностью в системе.

Это означает, что потенциально вредоносному процессу требуется только горизонтальное перемещение на том же уровне привилегий, чтобы получить EoP.

@smokeintheshell #632 (комментарий)

Окно с низкой (е) целостностью, принимающее входные данные и направляющее их непосредственно в процесс с высокой (е) целостностью, открывает этот процесс с высокой (е) целостностью для управления другими объектами с низкой (е) целостностью в системе.

Это означает, что потенциально вредоносному процессу требуется только горизонтальное перемещение на том же уровне привилегий, чтобы получить EoP.

да, я прочитал это объяснение в начале темы, но я не понимаю, почему это нормально для Linux и, возможно, Mac, но не подходит для Windows? В настоящее время Windows защищает входные данные для процессов с повышенными правами от процессов без повышенных прав. Либо в этой проблеме, либо в связанной, кто-то предположил, что нам нужен отдельный процесс для каждой вкладки. Я думаю, что это уже так, поскольку каждая вкладка имеет свою собственную команду для выполнения (например, pwsh.exe). Это потому, что все они являются дочерними элементами одного и того же корневого процесса под одним HWND?

Страдает ли терминал Ubuntu от той же проблемы с вкладками, если я:

• открыть вкладку с su
• есть вкладка, на которой я уже повысил уровень с помощью sudo и мне не нужно снова вводить свой пароль для политики конфигурации?

Или архитектура Ubuntu каким-то образом защищена от атак с внедрением ввода между процессами?

Страдает ли терминал Ubuntu от той же проблемы с вкладками, если я:

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

Или архитектура Ubuntu каким-то образом защищена от атак с внедрением ввода между процессами?

Если вы посмотрите на мой комментарий здесь , я фактически воспроизвел/эксплуатировал проблему в Linux. И su, и sudo, вероятно, одинаково «уязвимы», поскольку вы можете отправлять нажатия клавиш в окна с более низкой целостностью, выполняющие эти команды. Тайм-аут пароля sudo (не нужно вводить пароль при следующей команде sudo в течение 15 минут) делает это еще проще. Вы можете усилить защиту Ubuntu, отключив расширение X, необходимое для атаки. Не уверен, что это возможно в среде Wayland (атака и/или усиление).

Я полностью понимаю решение не реализовывать вкладки со смешанными высотами, если только нет способа отключить виртуальные клавиатуры и другие программные методы ввода.

Я думаю, что это уже так, поскольку каждая вкладка имеет свою собственную команду для выполнения (например, pwsh.exe). Это потому, что все они являются дочерними элементами одного и того же корневого процесса под одним HWND?

@kbirger Да, для каждой вкладки есть отдельные процессы, но все ваши действия с мышью и клавиатурой по-прежнему отправляются в окно терминала Windows (с низкой степенью целостности), а затем направляются в каждый процесс оболочки через стандартные входные потоки. Так работают все сочетания клавиш Windows Terminal.

Интересно, можно ли определить, подделан ли вход, например, с помощью API GetCurrentInputMessageSource . Я не могу найти много информации об этом API, кроме официального примера , но из описания он должен быть в состоянии идентифицировать источник ввода (аппаратное обеспечение/из процессов с uiAccess, в основном программное обеспечение специальных возможностей/из процессов без uiAccess, возможно, вредоносное)

почему это нормально для Linux и, возможно, для Mac, но не для Windows?

Я почти уверен, что одна из трех причин заключается в том, что Microsoft продает безопасность как функцию другим крупным корпорациям или правительствам.

Есть также несколько других причин, которые приходят мне на ум, почему это могло не быть проблемой до сих пор:

• Долгое время и по многим причинам (таким как «хакеры» не любят Windows, и «все» используют Windows ^^), Windows была основной (≈ единственной) целью всех видов вредоносных программ. Это нуждалось в большей безопасности (защита приподнятых окон), в то время как другим было все равно.
• Как объяснялось ранее в этом выпуске, вредоносное ПО не должно было легко получить доступ к вашему хосту консоли с повышенными правами в Windows, поэтому, вероятно, не многие вложили средства в эту проблему (я не эксперт по безопасности, поэтому я не знаю если у кого есть)
• Вредоносные программы обычно имели другие способы повышения своего уровня, чем попытки найти командную строку с повышенными правами в выбранной вами ОС.
• Только разработчики и системные администраторы используют терминалы (это только снижает целевую демографическую группу атаки; правительства и крупные корпорации по-прежнему вызывают озабоченность).

Теперь, вводя эту функцию наивно (как мы все сделали бы, я уверен 😄), вы внесете новый (огромный) недостаток в некоторые установки Windows. Поскольку разработка ведется открыто, вы можете быть уверены, что все, кто в ней нуждается, узнают об ошибке и начнут программировать против нее.
Быстрой контрмерой является запрет Windows Terminal (и, вероятно, всех других эмуляторов терминала, которые существуют теперь, когда уязвимость стала общедоступной), и вы можете попрощаться со своими мечтами об использовании Windows Terminal в любой корпоративной среде 😟

Я все еще очень надеюсь, что безопасная версия этой функции увидит свет 🤞

Понимаю. Спасибо за объяснения!

В качестве примечания, как экранная клавиатура Windows отправляет нажатия клавиш в окна с повышенными правами?

@mrwensveen AFAIK есть три способа отправки входных данных в окна с повышенными правами:

1. Поднимите себя. Однако вы по-прежнему не можете отправлять входные данные системным процессам (например, диспетчеру задач, диалогу UAC, экрану входа в систему).
2. Зарегистрируйте службу Windows. Теперь ваша программа работает как SYSTEM, поэтому вы можете делать все, что захотите. Я видел, как это делают некоторые программы удаленного доступа.
3. Объявите флаг uiAccess , подпишите свой двоичный файл цифровой подписью, установите его в папку, недоступную для записи текущему пользователю. Это «черный ход» для специальных программ, позволяющий им читать/записывать любые другие программы (включая системные процессы) и отображать поверх любых других окон (включая безопасный рабочий стол, где отображаются всплывающие окна UAC и экран входа в систему), и все это без запуска с повышенными правами. См . https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverview.

Экранная клавиатура (osk.exe), Narrator.exe (и, возможно, другие программы чтения с экрана) используют метод 3.

(Снимок экрана, показывающий манифест встроенной программы osk.exe с uiAccess=true )

Похоже, что флаг uiAccess также может защитить программу от доступа к ней со стороны других программ с низким уровнем целостности (несмотря на то, что она все еще работает без повышенных прав), может быть, мы можем использовать эту «функцию» для защиты WT?

@yume-chan Круто, очень интересно, спасибо! Разрешено ли программам uiAccess отправлять нажатия клавиш другим программам uiAccess ? Мы по-прежнему хотим, чтобы OSK могла взаимодействовать с терминалом Windows, и если это означает, что другие программы должны быть по крайней мере подписаны, прежде чем им будет разрешено отправлять ввод на терминал Windows, является ли это достаточно высоким барьером?

Разрешено ли программам uiAccess отправлять нажатия клавиш другим программам uiAccess?

@mrwensveen Да, программы с привилегиями uiAccess могут получать доступ друг к другу.

Я предпочитаю способ API GetCurrentInputMessageSource (https://github.com/microsoft/terminal/issues/632#issuecomment-651114562), потому что это не предназначено для uiAccess . Кроме того, с помощью API мы по-прежнему можем разрешить программам с низким уровнем целостности отправлять нажатия клавиш на вкладки без повышенных прав, а не на вкладки с повышенными правами.

Небольшой обходной путь, который я сделал здесь:

Я установил PowerToys , у которого есть несколько интересных функций. Одним из них является отображение ярлыков Windows, и я обнаружил, что когда вы нажимаете Win + число, оно открывает приложение на панели окон, соответствующее номеру, который отображается на панели.

Итак, я поместил терминал в панель как первую иконку
.

Когда я нажимаю Win + 1, открывается терминал.

Когда я нажимаю Win + Ctrl + Shift + 1, он открывается с повышенными правами.

Я также помещу сюда свою конфигурацию терминала и профиль powershell , если вы хотите получить функции отображения ветки git и среды conda в приглашении, а пользователя - красным, если это терминал с повышенными правами...

Это существует по крайней мере с Windows 7; это не вещь PowerToys.

@Firehawke Да, я только что узнал из-за PowerToys ... в этом нет необходимости.

Вот профиль для запуска с повышенными правами, который работает в Магазине Windows и имеет правильный значок:

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

РЕДАКТИРОВАТЬ: Отдайте должное @glooms , @shem-sargent, @LordFPL и @Firehawke за различные компоненты этого фрагмента. Поскольку эта команда вызывает pwsh.exe , похоже, что некоторые люди столкнулись с #4228 (ошибка 0x80070002 при запуске) из-за поврежденных переменных среды PATH или странных двоичных файлов в их пути с именем powershell.exe или pwsh.exe . @zurkz исправил это, сославшись на powershell.exe , но я не думаю, что теперь это надежно. # 6684 решает эту проблему для Windows Terminal, и вы найдете исправленную версию ниже, следуя этому решению, которое вообще не должно иметь этой проблемы.

Вот профиль для запуска с повышенными правами, который работает в Магазине Windows и имеет правильный значок:

{
    "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 Это хорошо работает! Спасибо.

Вот профиль для запуска с повышенными правами, который работает в Магазине Windows и имеет правильный значок:

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

Вот профиль для запуска с повышенными правами, который работает в Магазине Windows и имеет правильный значок:

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

@anyone Простите мое невежество, это удаляется в конфигурации Магазина Windows? Если да, то может ли кто-нибудь указать путь? Если нет, то где этот плохой мальчик должен жить?

ТИЯ!

@Казамарио
Он находится в файле settings.json терминала Windows, в разделе профилей.

Вызывает ошибку: 0x80070002 при запуске. пвш 7.1.

Я изменил его на:

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

и UAC предложил повысить разрешения.

Я изменил его на:

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

и UAC предложил повысить разрешения.

это сработало для меня довольно хорошо. Спасибо!

Вот как запустить Терминал Windows с повышенными правами, если он был прикреплен к Пуску.
https://github.com/farag2/Utilities/blob/master/Windows%20Terminal/Pin%20to%20Start.ps1

@narfanar Похоже, вы столкнулись с # 4228, где Windows Terminal выдает ошибку 0x80070002 при запуске, когда переменная среды PATH перепутана или другие двоичные файлы плавают по пути с именем powershell.exe или pwsh.exe . Я не думаю, что фрагмент @zurkz действительно исправляет это, поскольку он просто перемещает потенциальные проблемы с pwsh.exe на powershell.exe . # 6684 исправил это для WT, поэтому вот фрагмент, адаптированный к этому решению:

{
    "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 делает это хорошо

Обратите внимание, что Cmder имеет эту функцию, которая невероятно полезна. Хотелось бы, чтобы это было реализовано в Windows Terminal. Даже если он должен запускать отдельное окно для вкладок администратора или что-то в этом роде.

мой профиль по умолчанию настроен на bash, а не на powershell, и я бы хотел, чтобы он оставался таким. фрагмент выше работает отлично, но мне нравится запускать новый терминал с повышенными правами с загруженным профилем powershell. Я потратил около 3 часов, пытаясь понять это (не большой поклонник / имею большой опыт работы с powershell), и я не могу понять это - пожалуйста, помогите. кажется, что есть некоторая комбинация одинарных кавычек, двойных кавычек, экранирования, пробелов, новых строк, которые могут заставить это работать, но я не могу заставить процесс запуска и список аргументов делать то, что я хочу. я свел это к:

Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p "Windows PowerShell"'
это работает в файле .ps1, если я запускаю его сам, я получаю новый терминал Windows с повышенными правами с загруженным профилем powershell. но это не работает в параметре командной строки settings.json, как бы я ни пытался его изменить, явно вызывая список аргументов вместо использования cmd /c, различные формы экранирования и использования кавычек и т. д.

"commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p \"Windows PowerShell\"'",
не работает. лучшее, что я могу сделать, это запустить странный гибрид того, что я хочу. я загрузил окно «Администратор: Ubuntu», которое выглядит как мой профиль bash, но на самом деле работает с powershell. неправильный шрифт и все. если я использую это окно, чтобы открыть новую вкладку powershell, она будет поднята по желанию. когда это так, я могу вставить любой мусор, который я хочу, в часть «Windows PowerShell» загрузки профиля, и я получаю точно такое же поведение, поэтому я знаю, что на самом деле он не пытается загрузить профиль, который я передаю.

Итак, у меня возникла проблема с попыткой запустить это с повышенными правами, я сделал все перечисленные выше варианты и либо получаю ошибку «Не могу найти файл», либо это.

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

Кто-нибудь еще имеет проблему или не смог заставить их работать нормально?

мой профиль по умолчанию настроен на bash, а не на powershell, и я бы хотел, чтобы он оставался таким.

Я тоже. Я запускаю WSL большую часть времени, но время от времени мне нужно запускать PS с повышенными правами, и я хотел бы сделать это на вкладке нового WT.

Мне также не удалось заставить работать ни один из примеров — даже с исправлением путей к файлам. Я нашел и установил gsudo , который может повышать уровень текущей вкладки или использоваться в качестве профиля для открытия вкладки с повышенными правами в том же окне. Я не уверен, что приведенные выше решения запускаются в новом окне (некоторые попытки, которые я предпринял до использования gsudo , начинались только в новом окне). Откроется всплывающее окно UAC.

Это профиль, который я использую:

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

Я использую supressApplicationTitle , чтобы заголовок вкладки не отображал Administrator: как избыточный с Elevated .

@ayfine Если https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 действительно не работает для вас, не могли бы вы отправить расшифровку точных ошибок / неожиданного поведения, которые вы получаете с этой конфигурацией? (Обязательно добавьте дополнительную конфигурацию, например suppressApplicationTitle , с минимальными шагами, чтобы, если какая-либо из ваших конфигураций нарушает WT, было легче определить, где и когда это происходит.)

Если какие-либо другие конфигурации здесь продвинулись немного дальше, чем связанная для вас, также будут оценены подробности о том, как они ломаются.

@ bb010g bb010g Я не получаю никаких сообщений об ошибках - приношу извинения за то, что не был точен в своем ответе. При использовании https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 я столкнулся с проблемой Windows Terminal, загружающей мою оболочку WSL Ubuntu (по умолчанию). Первоначально я понял, что это означает, что оно работает неправильно, но теперь я вижу, что в этом новом окне, если я открываю новую (профиль по умолчанию) вкладку Powershell, она фактически повышается. Несмотря на это, открывая новое окно и открывая в нем новую вкладку, это ничуть не проще, чем запуск процесса с повышенными правами из моего меню «Пуск». То, что я описал в своем первоначальном ответе, дает точное поведение, которое я себе представлял.

@ayfine - и я скопировал ваш пример gsudo. Это достаточно хорошее решение, пока не будет закодировано что-то встроенное. Спасибо.

@ayfine Я пробовал gsudo, но это довольно ужасный опыт. Кажется, что любое завершение TAB прерывается, а символы Unicode (не ASCII), похоже, не отображаются. Я предполагаю, что это какой-то процесс, который перенаправляет ввод и вывод и делает при этом ужасную работу. Я думаю, что решение с отдельным окном работает лучше.

Если у вас возникли проблемы с gsudo, сообщите о них @gerardog, а не в этой ветке. Каждое сообщение в этой ветке (включая и это; извините!) рассылается сотням подписчиков по электронной почте.

Я собираюсь заблокировать эту ветку для дальнейших комментариев, не связанных с сопровождающим, поскольку мы достигли точки, когда дальнейшие комментарии не продвигают обсуждение вперед в значимой степени.

Если у вас есть проблемы, не описанные здесь, отправьте новые вопросы.