Powershell: Поддержка sudo<powershell cmdlet=""/>

Хм! Очень интересно. Но я думаю, что реальное поведение соответствует ожиданиям. Как и в Windows, у нас нет такой команды, как sudo.
Но вы можете использовать sudo powershell, а затем удалить foo.txt (который был создан с помощью sudo powershell), тогда он работает при использовании Remove-Item. Конечно, это не сработает с разрешением без повышенных прав.

Я бы использовал sudo только в командах Linux («sudo nautilus») из PowerShell.

:)

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

Эта функция была бы полезна для обхода # 3506.

Если проблема не будет решена, это станет для меня препятствием для адаптации Linux. Нам не разрешено использовать sudo bash, и точно так же мы не сможем выполнить sudo powershell.

Я согласен с Maximo, мы должны оставить sudo на bash и создать новый командлет для повышения прав в PowerShell с использованием sudo в качестве основы для ожидаемой функциональности.

@dantraMSFT изучает это, Дэн, не могли бы вы

@pixelrebirth. Не могли бы вы подробнее рассказать о своих ожиданиях? Ожидаете ли вы простого выполнения с ожиданием, перенаправлением вывода или перенаправлением конвейера?
Также было бы полезно использовать некоторые примеры использования.

@dantraMSFT Ради аргумента я собираюсь назвать новый sudo-подобный командлет: Invoke-Elevated
Вот как работает sudo, и его можно перевести на Invoke-Elevated в формате PowerShell.

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

В этом примере все в блоке сценария будет выполнено с повышенными правами, а затем будет передано по конвейеру в Get-SomeCmdlet НЕ с повышенными правами.
Cred может быть другим пользователем или вами как пользователем с повышенными привилегиями (разрешения должны храниться где-то, например файл sudoers, также известный как белый список)

Ведение журнала должно быть включено по умолчанию для случаев, когда выполняется Invoke-Elevated:
Пользователь | Команда | Регистрация в формате DateTime или аналогичном формате

Возможно, что-то из этого будет расширено или изменено позже, но это то, что удалит мои блокираторы

Он также должен работать так:

Get-ChildItem ./test | Invoke-Elevated -command {Remove-Item -force}
Где учетные данные - это ваш текущий пользователь, и он просто запрашивает пароль ...

Get-ChildItem НЕ повышен, Remove-Item в этом примере повышен

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

Я помогу, чем смогу, и окажу давление везде, где нужно.

@pixelrebirth надеюсь, что она в порядке! Мы сделаем запись разговора через день или два, так что вы можете наверстать упущенное, если хотите.

Основное заключение состоит в том, что @dantraMSFT проводит первоначальное расследование, чтобы выяснить, как это сделать без взлома. Сегодня вы можете sudo powershell -c "invoke-foo" из другой оболочки, но это явно не работает.

@dantraMSFT : в ходе расследования, может быть,

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

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

@pixelrebirth Для справки, sudo использует бит setuid, подробности см. на https://unix.stackexchange.com/a/80350/86669 . Однако, вероятно, было бы плохой идеей устанавливать это для всей оболочки.

Должен быть родной Windows sudo (так что проблема, вероятно, не здесь, хотя вариант, когда его можно использовать только через Powershell, для меня приемлем). Я использовал Powershell с самого начала и видел 99 вариантов сценария sudo, например Invoke-Elevated выше (или мой собственный, который я использую каждый день). Включение подобного командлета в Powershell было бы шагом вперед, однако все они кажутся громоздкими по сравнению с тем, как это работает в Linux.

Одна из неприятных вещей для меня заключается в том, что он запускает новое окно оболочки (не в Linux), которое я хотел бы видеть реализованным в Powershell / Windows, но не уверен, что это технически возможно в Windows.

Хотя мне нравится идея другого командлета («Invoke-Elevated»), который, возможно, можно было бы использовать в Windows, но я не могу понять, почему бы не придерживаться открытия PowerShell с помощью «sudo», если вам нужно создать сценарий для запуска с высоким привилегия?

Особенно, если вы автоматизируете задачу, которая в любом случае будет запланирована для запуска с некоторыми учетными данными с высокими привилегиями.
:)

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

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

Мой рабочий процесс заключался в следующем: команда запуска, он жалуется на привилегии, я sudo -L который снова выполнит последнюю команду с привилегией. Поскольку posh так медленно запускается, я просто запускаю административную оболочку и постоянно живу в ней, что явно не лучшая идея.

Спасибо @majkinetor!
:)

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

@majkinetor : Насколько я знаю, единственный способ запустить процесс с повышенными
FWIW: вы можете сделать это в Windows без изменения PowerShell, используя ShellExecuteEx.
Однако, если вы ожидаете потоковой передачи результатов; это совсем другая история.

Насколько мне известно, единственный способ запустить процесс с повышенными правами - это запрос UAC.

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

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

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

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

В модуле Sudo есть три функции:

• New-SudoSession
• Удалить-SudoSession
• Старт-SudoSession

Start-SudoSession (псевдоним sudo) предназначен для одноразовых команд, которые необходимо повысить. Он запросит учетные данные и выдаст приглашение UAC перед выполнением команды.

.ПРИМЕР

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

New-SudoSession, если для открытия ElevatedPSSession, в который могут быть введены команды с повышенными правами. Идея состоит в том, что в более длинном сценарии с несколькими операциями, требующими повышения прав, вы создаете ElevatedPSSession в начале и получаете приглашение UAC ОДИН РАЗ, а затем при необходимости вводите эти повышенные команды с помощью Invoke-Command в этот ElevatedPSSession.

.ПРИМЕР

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

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

Наконец, Remove-SudoSession удаляет ElevatedPSSession, созданный функцией New-SudoSession. Идея состоит в том, чтобы поместить это в конец вашего скрипта, после чего вы получите приглашение UAC. Таким образом, в целом, чтобы запустить любое количество операций с повышенными правами в конкретном скрипте, вы получите только два приглашения UAC - одно для открытия ElevatedPSSession, а второе для его закрытия. Использование Remove-PSSession:

.ПРИМЕР

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

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

Под капотом вот что он делает из сеанса PowerShell без повышенных прав (если сеанс уже повышен, он ничего не делает):

• Проверяет, включен ли WinRM / WSMan и настроен ли он для разрешения аутентификации CredSSP (если нет, то
  внесены изменения в конфигурацию)

• Проверяет объект локальной групповой политики ...

  Конфигурация компьютера -> Административные шаблоны -> Система -> Делегирование учетных данных -> Разрешить делегирование новых учетных данных

  ... чтобы убедиться, что он включен и настроен для разрешения подключений через WSMAN / LocalHostFQDN

• Создает сеанс PSSession с повышенными правами с помощью командлета New-PSSession

• Запускает выражение, переданное параметру -Expression в расширенном сеансе PSSession

• Удаляет повышенный сеанс PSSession и отменяет все изменения, внесенные (если таковые были) в локальную групповую политику и конфигурацию WSMAN / WinRM.

РЕДАКТИРОВАТЬ: обновлена ​​опечатка в примере Remove-SudoSession.

@pldmgg Я не вижу лицензии на ваш код, поэтому мы даже не можем посмотреть, что вы сделали. Вы можете добавить ЛИЦЕНЗИОННЫЙ файл? MIT будет самым дружелюбным и позволит нам использовать ваш код или заимствовать его. Благодаря!

@pldmgg В https://choosealicense.com/.

tl; dr - Трудно ошибиться со следующими лицензиями:

• Apache 2.0
• Массачусетский технологический институт

Подробнее

Apache 2.0 имеет некоторые дополнительные преимущества по сравнению с MIT, но в целом они очень снисходительны, легко используются с другими лицензиями с открытым исходным кодом и очень удобны для бизнеса. Если вы выберете какие-либо лицензии с авторским левом (GPL), код не сможет использоваться с другими инструментами без перехода этих других инструментов на лицензию GPL (также известную как вирусное лицензирование - LGPL является здесь исключением, где модули / двоичные файлы с лицензией LGPL могут быть размещенным рядом с другими инструментами, не требуя изменения лицензии на другой код).

@pldmgg тоже, очень-очень круто!

@ferventcoder Спасибо за ссылку https://choosealicense.com! Как вы, ребята (+ @ SteveL-MSFT), вероятно, подозревали, я не совсем уверен, какую лицензию выбрать. Я обновил весь свой репозиторий misc-powershell, чтобы использовать Apache 2.0, и обновил Sudo.psd1, чтобы он ссылался на Apache 2.0 (в моем репозитории git, а также в галерее PowerShell). Надеюсь, это будет полезно людям! Все советы / критика приветствуются!

@ SteveL-MSFT Можете ли вы использовать его, если лицензия - Apache 2.0? Если вам нужен MIT, дайте мне знать, и я обновлюсь.

@pldmgg Моя самая большая проблема с вашим решением - это использование CredSSP. Это менее безопасный метод обработки учетных данных, и я думаю, что он представляет большой риск для границы UAC.

По словам Powershell Magaize ,

«Использование CredSSP для аутентификации на рабочей станции пользователя с учетной записью администратора домена - плохая идея; по сути, вы отдаете ключи от королевства».

«Не помещайте учетные данные с высоким уровнем доверия на компьютеры с низким уровнем доверия»

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

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

@pldmgg Я считаю, что Apache 2.0 достаточно. Благодаря!

@ dragonwolf83 Это общая проблема. Я фактически изложил весь свой аргумент о том, что в этой конкретной ситуации все нормально в этой теме:

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

Но, подытоживая, я считаю, что здесь все нормально, потому что:

• Он подключается к локальному хосту (не удаленному)

• Начиная с Windows 8.1 / Server 2012R2, CredSSP больше не отправляет пароли в виде открытого текста.

• Протокол удаленного рабочего стола по-прежнему уязвим для атак с передачей хэша, как и CredSSP, поэтому, если вы беспокоитесь об этом для CredSSP, вам также следует беспокоиться об этом для RDP. (Конечно, есть режим RDP Restricted Admin или новый Credential Guard)

PS Эта статья стала моим справочником по PowerShell Security (и именно там я узнал о Credential Guard) .. Я очень рекомендую ее.

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

Что касается 6.0.0, я думаю, что мы закончим:

Функция сценария под названием sudo, которая существует только в Linux (мы откладываем поддержку повышения прав Windows). Если аргумент - это командлет / блок сценария, он будет использовать sudo powershell с этими аргументами. Это означает, что пока конвейерная обработка объектов работать не будет. Если аргумент является собственной командой, мы просто передаем его непосредственно в sudo.

После 6.0.0 мы хотели бы в конечном итоге получить такие впечатления, как:

Get-Item foo.txt | sudo Remove-Item

и пусть он работает как в Windows, так и в Linux. cc @joeyaiello

На основании обсуждения @ PowerShell / powershell-Committee это не требуется для 6.0.0, и рекомендуется инвестировать в командлет типа Invoke-AsUser

Чтобы изменить высоту в целом, вам понадобится что-то с битом setuid под UNIX, и это будет сам sudo. sudo - это специальный двоичный файл, который нелегко эмулировать и не следует эмулировать в целях безопасности. Пожалуйста, позвольте фактическому sudo использоваться для запуска временного экземпляра powershell, который выполняет указанную команду. Кроме того, выполнение sudo для всей оболочки довольно небезопасно, учитывая, что можно забыть, что оболочка открыта на удаленном сервере. У sudo есть механизм, позволяющий забыть о том, что пользователь повысил уровень доступа через несколько минут, что защищает машину в долгосрочной перспективе. Решение этой проблемы позволит большему количеству людей использовать PowerShell в производственной среде на серверах Linux. В настоящее время powershell останется второстепенной новинкой, поскольку безопасность имеет первостепенное значение в производстве.

@borgdylan сегодня вы можете сделать sudo pwsh -c foo в PowerShell Core (или просто sudo nativecmd ). Я думаю, что желание состоит в том, чтобы иметь возможность использовать командлет sudo в рамках существующего сеанса PowerShell Core. Мы не пытаемся воссоздать здесь sudo , а скорее добавляем синтаксический сахар, чтобы упростить его использование.

С номером 1527 и тем, что эта проблема отодвигается все дальше и дальше от вех, я начинаю задаваться вопросом: действительно ли всем так комфортно входить в корневые сеансы, чтобы заниматься администрированием? Практически нет удобного способа вызывать команды PowerShell, когда PS каким-либо образом задействован.

@MathiasMagnus Я не тестировал это тщательно, но вы можете настроить общие или повторно используемые команды, чтобы не требовать пароль в sudo. Чтобы проверить, я добавил это с помощью visudo:

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

Затем я смог вызвать sudo pwsh -c 'cat /etc/sudoers' через сеанс удаленного взаимодействия PowerShell SSH. В зависимости от того, как вы обеспечиваете безопасность и что именно вы настраиваете в sudoers (например, All=(ALL:ALL) немного открыт ...), это может быть безопасно или опасно.

Если вы используете ssh для Linux (то есть для bash shell вместо удаленного взаимодействия SSH PowerShell), вы можете запустить sudo с обычным запросом пароля в pwsh, насколько я могу судить.

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

@MathiasMagnus # 1527 по-прежнему нацелен на 6.1.0, поскольку для этого нет хорошего обходного пути. Для командлетов основной проблемой является сложность конвейерной передачи в / из командлета sudo'd. Для одиночных операций sudo pwsh -c приемлемо. Конечно, если кто-то из сообщества отправит PR, мы будем более чем счастливы принять его.

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

Я знаю, что легко жаловаться на то, что что-то не работает и не предпринимает никаких действий, но мой опыт лежал в другом месте. Я в основном участвую в библиотеках C ++ и GPGPU, а также в Vcpkg, много портируя CMake. Я никогда не писал C # и не думаю, что у меня будет возможность. Однако я администрирую небольшой кластер из ~ 12 машин. Он находится на грани управляемости вручную, но возможности sudo явно отсутствуют, то есть, если я не собираюсь создавать логин для пользователя root в Ubuntu, что не одобряется. Решение DSC Core было бы решением, но, несмотря на то, что оно было объявлено год назад, недавно оно было отложено на неопределенный срок.

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

@MathiasMagnus - это то, чего хотят все, но sudo против собственных команд работает нормально, на самом деле просто невозможно запустить sudo против командлетов. Обходной путь - вызвать pwsh внутри pwsh:

sudo pwsh -c remove-item something

Основная сложность - это когда что-то внутри конвейера:

get-item foo * | sudo remove-item

@ SteveL-MSFT По крайней мере, концепция не такая уж сложная. Пожалуйста, скажите мне, что вы думаете.

Нам просто нужна комбинация двоичных файлов sudo, su и входа в систему для обработки всех случаев.

Для этого нужно:

• Создайте сокет unix для обратных вызовов и разрешите доступ к нему только конечному пользователю.
• Убедитесь, что вызывающему абоненту разрешен доступ sudo (я думаю, что можно просто скопировать исходный код su , sudo и войти в систему )
  
  
  
  • Если существует / etc / sudoers, его необходимо проанализировать
    
    
    
    
    
    • Только определенные команды
    
    
    
    • Используя пароль целевого пользователя
    
    
    
    • Без проверки учетных данных (без пароля)
    
    
    
  
  
  • Если это не так, нужно вызвать pem, чтобы проверить, "знает ли пользователь" учетные данные для пользователя root напрямую.
  
  
  • Если он также не знает учетные данные конечных пользователей, запретите доступ и вызовите исключение в PowerShell.
  
  
• Если проверка прошла успешно, нам нужно переключить контекст пользователя либо на пользователя root, либо на пользователя назначения.
• После переключения пользовательского контекста новый процесс должен установить связь с исходной запущенной оболочкой PowerShell, подключив ее к сокету unix.
• Если пользователь вводит "exit", мы сигнализируем через сокет unix, что мы закончили, и когда мы выходим, пользователь автоматически вернется к привилегиям вызывающих абонентов, поэтому нам нужна только командная оболочка хоста для отображения приглашения или выполнения следующего инструкция.
• Если вместо этого Powershell хоста завершает работу, сокет unix закрывается, и Powershell с повышенными привилегиями должен остановить выполнение и завершить работу, как если бы кто-то закрыл терминал.

Поток выполнения будет выглядеть так:
PWSH (создает сокет /proc/self/change-user.socket) => PWSH-SU (вызывается с помощью сокета и целевого пользователя в качестве параметра; PWSH-SU устанавливается suid для запуска от имени самого root) => PWSH при подключении целевого пользователя в сокет unix.

Самая трудоемкая часть - это позволить PowerShell внутренне подключаться через сокет unix. Простого перенаправления входных и выходных линков, которые делают другие приложения Unix, недостаточно, поскольку мы имеем дело с объектами, а не только со строками при вызове каналов.

Зачем использовать все три двоичных файла?
sudo требуется, чтобы несколько пользователей могли переключаться в корневой контекст без потери возможности аудита .
su используется для переключения на любого другого пользователя с использованием учетных данных конечных пользователей.
login используется для создания совершенно нового сеанса входа в систему.
Наличие всех этих функций также в PowerShell может быть полезно во многих случаях по сравнению с наличием только одного.

Использование каналов также может сделать эту работу в Windows менее удивительной и более удобной - мне неприятно, что я получаю другую оболочку со всеми скриптами «sudo» + щелчком UAC, но с такими каналами это можно сделать в той же оболочке, просто например, в linux, общаясь по каналу с другим интерпретатором, уже работающим как администратор, и, возможно, реализуя некоторые реальные вещи sudo (например, тайм-аут запроса или файл sudoers с командами в качестве альтернативы пользовательским конечным точкам PowerShell)

Я действительно рад видеть мысли по этому поводу, но что касается фактической реализации, мне кажется, что мы немного забегаем вперед. Во-первых, системе нужен способ создания процесса, потока с повышенными правами, чего угодно, из процесса с повышенными правами. Ни одна из проблем, связанных с командлетами, не может быть решена по-настоящему, если мы не можем создать экземпляр PowerShell с повышенными привилегиями для начала без использования UAC. ИМО, первый сценарий, который следует рассмотреть здесь, должен быть - у вас ограниченный сеанс SSH - как вы выполняете обычный exe с разрешениями администратора?

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

Ни одна из проблем, связанных с командлетами, не может быть решена, если мы не можем создать экземпляр PowerShell с повышенными привилегиями для начала без прохождения UAC.

Одна из возможностей сделать это включает использование запланированной задачи с опцией «запускать с наивысшим приоритетом».

Да, но для этого у вас уже должны быть права администратора, верно? Это то, что делает psexec. Насколько я знаю, прямо сейчас надо в какой-то момент пройти UAC. Я бы хотел увидеть это изменение, и поскольку все сеансы SSH повышаются, это своего рода проблема безопасности. Если какое-то отрывочное программное обеспечение пытается подключиться к моему компьютеру с Windows по SSH, скажем, с другого компьютера, на котором у меня настроен закрытый ключ (или сценарий обратной связи), оно может делать все, что захочет.

@parkovski Моим решением были только Linux / MacOS и все остальные * NIX OS. Windows не поддерживает SUID и GUID.
Поскольку sudo в настоящее время также не существует в Windows, для меня это выходит за рамки этой проблемы.

И чтобы решить проблему UAC, в будущем Windows должна реализовывать SUID и GUID. Все остальное - всего лишь грязный способ решения давней проблемы ...

Да, но для этого у вас уже должны быть права администратора, верно?

Верно, но это не вызывает всплывающее окно UAC.

UAC также можно пропустить официальным способом с помощью Microsoft Application Compatibility Toolkit.

Windows не поддерживает SUID и GUID.

Windows не обязана поддерживать его, и эта концепция не подходит для этой ОС.
Его модель разрешений основана на списках ACL и не имеет единого группового владения.

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

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

@ SteveL-MSFT

также, вероятно, сосредоточится на простом включении sudo для root, а не на произвольном пользователе

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

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

Большинство людей, с которыми я работал, просто отключали UAC, если могли.

К сожалению, это не вариант во многих средах, и я очень сомневаюсь, что MS собирается полностью отказаться от UAC. 😕

Этот вопрос не о UAC. Но, с моей точки зрения, от него следует отказаться полностью и либо заменить его строгими двумя учетными записями, одним администратором, одним пользователем (и один администратор не может использоваться для входа в систему), философия (установка по умолчанию заставляет вас создавать их) или для та же концепция, что и в NIX, вы начинаете как пользователь и при необходимости повышаете уровень с помощью sudo и SUID / SGID-Flags.

Недавно я добавил следующее в свой $profile . Я рассмотрел это более подробно на https://stackoverflow.com/a/56265080/118098

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

По крайней мере, на первый взгляд, это работает для меня и позволяет "sudo". Это не касается случая" возможности sudo командлета в существующем сеансе PowerShell Core "согласно https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -354853084

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

Я реализовал базовое sudo, которое хорошо работает для запуска команд от имени администратора в Windows. Я не уверен, будет ли это работать и на linux / mac, так как я не знаю, правильно ли повышает уровень "RunAs" на этих платформах.

Редактировать профиль:

PS > notepad $PROFILE

Добавьте следующую функцию sudo :

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

Затем вызовите в своей оболочке. Поддерживает командлеты, исполняемые файлы и все, что обычно можно ввести в командной строке PS:

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

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

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

Удалите "-NoExit" из функции sudo, если вы предпочитаете, чтобы окно администратора закрывалось после завершения.

@vsalvino Это полезный обходной путь, когда доступен графический интерфейс, и пока он полезен, но это все еще не настоящее sudo, потому что оно не работает без доступа к графическому интерфейсу. В удаленной оболочке (ssh) буквально единственный способ сделать эту работу - это служба и клиент, как я пытался продемонстрировать здесь .

Чтобы ответить на некоторые общие предложения, потому что поверьте мне, я рассмотрел все возможности:

• Отключение UAC - не решение. Это обходной путь, который можно выбрать самостоятельно, но это не общее решение этой проблемы.
• Все, что вызывает UAC (каждый сценарий "sudo", который я видел), не является решением, в том числе выполнение его один раз для запуска удаленного сеанса с повышенными правами.
• Все, что требует графического интерфейса _ вообще_, не является решением. Предположим, мы используем здесь ssh, а графический интерфейс недоступен.
• Все, что требует серьезных изменений в Windows, не является решением. Мы не можем рассчитывать на то, что UAC превратится в нечто лучшее.
• Даже подписанный двоичный файл от Microsoft не является решением, потому что он не будет работать, когда UAC установлен на высокий уровень (я ошибся в wsudo readme; я исправлю это позже).
• Единственное реальное решение для sudo в Windows - это служба, повышающая уровень пользовательских процессов при успешной аутентификации. Я хотел бы услышать другие идеи, но, пожалуйста, сначала исследуйте их.

По сути, кому-то придется проделать много работы, и никак иначе. Нам нужно что-то, что, как только PowerShell поддерживает это в Unix, станет заменой в Windows и будет работать так, как вы ожидаете от sudo (без GUI, без UAC).

Не могли бы мы сначала прояснить масштаб этого вопроса? Я думаю, что сейчас несколько человек говорят на разные темы.
Это проблема:
а) О реализации sudo в PowerShell для систем Linux / Mac?
б) Реализовать реплику sudo в окнах?
в) Разрешить повышать привилегии при psremoting?
г) Разрешить выдавать себя за других пользователей в windows?
д) Разрешить переключение с учетной записи непривилегированного пользователя на учетную запись привилегированного пользователя?
е) что-то совсем другое?

Для а) https://github.com/PowerShell/PowerShell/issues/3232#issuecomment-444849067
Для б) То же, что и (в Windows также есть сокеты unix), но вместо двоичного файла suid он должен быть порожден службой (выполняемой в рамках пользователя, имеющего право «действовать как часть операционной системы», например, пользовательская система) и эта служба также должна проверять привилегии. Или реализовать концепцию SUID / GUID в Windows.
Для c) не требуется, у вас уже есть наивысшие привилегии при удаленном взаимодействии. При доступе к удаленным хостам нет разделения привилегий (также уже были некоторые обходы UAC с обратной связью localhost, которые работали таким образом).
Для d) Также может быть использован подход из a / b, но я не знаю, как это должно работать при попытке доступа к сетевым ресурсам, не зная учетных данных пользователей или не создавая новый сервер аутентификации windows / activedirectory.
Для e) То же, что и b, но также требуется проверка учетных данных, в качестве альтернативы можно ослабить runas api, чтобы позволить одному знающему имя пользователя и пароль получить новый токен пользователя и сохранить контроль над этим процессом. (Вряд ли с учетом концепций и соображений безопасности UAC, поэтому мы вернулись к b).

ИМО, эта проблема должна быть связана с реализацией sudo в PowerShell, где базовая функциональность уже существует. Обсуждение эквивалента sudo для Windows, вероятно, более уместно в этой проблеме с терминалом .

Обсуждение эквивалента sudo для Windows, вероятно, более уместно в этой проблеме с терминалом.

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

ИМО, эта проблема должна быть связана с реализацией sudo в PowerShell, где базовая функциональность уже существует.

Одним из достоинств следующего Powershell является меньшее количество проблем совместимости между системами, использующими его. В связи с этим выполнение чего-либо только в системе X IMO неприемлемо.

Мне, как пользователю CLI, все равно, если sudo - это полноценный linux sudo с использованием файла suders или некоторых других окон. Sudo - это просто интерфейс к функциям повышения прав ОС. Такой интерфейс можно заставить работать почти одинаково, независимо от «бэкэнда».

В противном случае, @parkovski указывает на стойки с графическим интерфейсом - я бы просто добавил Windows Core среди причин, почему.

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

Потому что это репо - это не просто «терминальное приложение»; Команда, которая его запускает, в основном владеет текстовыми частями Windows и уже сказала, что они заинтересованы во внедрении sudo, когда найдут время. С другой стороны, никто из команды PowerShell или ConEmu не предлагал.

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

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

Мне, как пользователю CLI, наплевать, является ли sudo полноценным linux sudo с использованием файла suders или некоторых других окон. Sudo - это просто интерфейс к функциям повышения прав ОС. Такой интерфейс можно заставить работать почти одинаково, независимо от «бэкэнда».

Да, безусловно, должно. Просто sudo еще не существует в Windows, потребует много работы и, вероятно, не будет написан командой PowerShell. Когда такая вещь существует, будем надеяться, что PowerShell реализует ее таким образом, что она будет работать и в Windows.

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

Есть мнение по этому поводу?
http://blog.lukesampson.com/sudo-for-windows
Установлен с scoop install sudo , это самое близкое, что я могу придумать. Работает как unix sudo - запускать команды с повышением. Я использую его с pip или Install-Module для всех пользователей.

Люк Сэмпсон - Sudo для Windows

Sudo для Windows

@ Restia666Ashdoll Если он переименован в Invoke-ElevatedCommand меня это устраивает.
Это потому, что sudo отвечает не только за повышение прав команд, но также за выдачу себя за пользователей и «удаление» ( sudo -u nobody command ) привилегий. Также повторное использование уже существующих имен оказалось плохой идеей, особенно если функциональность и параметры различаются.
Выше я уже описал, как будет выглядеть настоящее sudo с олицетворением и как оно может работать.

@ Restia666Ashdoll Прочтите этот комментарий в этой теме.

@parkovski Это просто оболочка для -Verb RunAs, которая работает только с несколькими командами. Тот, с которым я связался, можно использовать почти со всем. Например, я использую это так - sudo pip install httpie .

Вы не читали мой пост?

Я не думаю, что есть какой-либо способ отредактировать заголовок, чтобы включить что-то вроде «НЕ СУДО В ОБСУЖДЕНИИ WINDOWS»? Я знаю, что лично я не обязан отвечать на этот вопрос, но люди продолжают говорить то же самое, не проводя исследования.

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

Я уже сообщил о @troymoore на GitHub

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

Вот работающий модуль, демонстрирующий, как это будет работать в NT: https://github.com/mmillar-bolis/Invoke-AsAdmin

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

РЕДАКТИРОВАТЬ: я должен также упомянуть, что это не выполнит запрос @parkovski для повышения уровня UACless.

Похоже на JEA.
Что касается сериализации, не все модули это поддерживают.

Похоже на JEA.

Да, это идея.

Что касается сериализации, не все модули это поддерживают.

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

Модуль предназначен для решения очень конкретной проблемы повышения уровня интерактивных команд в сеансах GUI на NT и не более того. Это началось примерно пять лет назад, прежде чем кто-либо мог представить себе, что нативный ssh ​​может быть полезен для NT. Я согласен с @parkovski, что это проблема, связанная с тем, как NT обрабатывает повышение

Тем не менее, вместо того, чтобы быть остановленным заблуждением нирваны о том, что реализация типа sudo должна существовать на NT до того, как PowerShell сможет поддерживать любую форму повышения прав для команд, почему бы нам сначала не продвинуть любую форму интерактивного повышения прав JEA в сеансе оболочки?

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

Я мог бы также добавить, что даже библиотека повышения уровня Python не может делать то, что делает этот модуль. Вы нашли другой модуль, который уже не работает? Потому что моя основная мысль заключается в том, что, возможно, более умные умы, чем мой, могут взять этот модуль и его идеи и работать с ними в направлении, подходящем для NT. После этого у нас может быть начальная платформа для NT и * nix, которая встретится посередине, что позволит нам пересмотреть более распространенную реализацию PowerShell для повышения команд.

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

Я на минуту отойду от своих разочарованных жалоб на объяснение сути sudo, потому что (а) да, это очень сложная проблема, (б) действительно может быть правильно решена только MS (спасибо за то, что не является открытым исходным кодом, Windows), (c) действительно здорово видеть, что другие тоже увлечены этим.

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

Что я лично хотел бы видеть в PowerShell, так это всестороннюю поддержку sudo для Unix, но предназначенную для поддержки некоторой формы сценария «псевдо-sudo» в том виде, в каком он есть сейчас, а также потенциального реального sudo для Windows в будущем. Я считаю, что если кто-то прототипирует, как в конечном итоге будет работать Windows sudo, но оставляет ограничение UAC, это должно быть довольно просто, дать нам что-то, что в основном так же хорошо, как и сейчас, и когда мы получим реальную вещь, это должно быть довольно многое будет просто заменой.

Очевидно, это означает, что кто-то должен будет предложить модель, которая понимает или, по крайней мере, транслирует как модель Unix uid / gid, так и модель sid / acl Windows. Надеюсь, этому человеку понравится вызов. Предположение, что это также потребует некоторых переговоров с группами безопасности терминала и Windows в MS.

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

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

Можно подумать о Start-Process pwsh -NoNewWindow -Credential $cred . Не работает, но могло.

Очевидно, это означает, что кто-то должен будет предложить модель, которая понимает или, по крайней мере, транслирует как модель Unix uid / gid, так и модель sid / acl Windows. Надеюсь, этому человеку понравится вызов. Предположение, что это также потребует некоторых переговоров с группами безопасности терминала и Windows в MS.

Unix также имеет acls, а окна имеют совместимость с posix, и, по крайней мере, если это соединение домена, есть также атрибут основной группы, который мы могли бы использовать (а также атрибуты posix). Это просто необходимо реализовать для клиентов Windows, не подключенных к домену (или на данный момент предполагается, что это User ).

Таким образом, общая модель для разрешений unix и windows в основном:
ACL с пользователем-владельцем и группой-владельцем с некоторыми ожидаемыми ACE (пользователь, группа и другие).

Тогда мы могли бы сопоставить разрешения unix как:
uid => Owner SID
gid => SID основной группы пользователя, создавшего объект.
user => Creator Owner ID S-1-3-0
group => ID группы авторов S-1-3-1
другой => Мир / Все S-1-1-0
Сопоставление uid из списка acl в unix немного сложнее, поскольку нам нужно учитывать, что система может быть частью ldap, активного каталога или любого другого каталога. Единственные два случая, которые я бы рассмотрел в рамках PowerShell, - это отсутствие каталога и каталог ldap / active.
В первом случае я бы предложил использовать S-1-6-1-uid и S-1-6-2-gid (при условии, что S-1-6 все еще доступен, и ответственная группа готова выделить его для этой цели. ).
И для второго случая нам просто нужно иметь какое-то разрешение uid через бэкэнд аутентификации. Сервер каталога ldap / active отвечает за предоставление sid.
И, наконец, есть несколько особых случаев для сопоставления:
uid 0 => S-1-5-32-544
gid 0 => S-1-6-500 (и S-1-5-21 - * - 500)
большинством других известных sid можно управлять через файл конфигурации или через какой-то api (или просто отбросьте их, поскольку они, скорее всего, все равно не используются)

Если мы сделаем это в сборке оболочки в таких командах, как Get-Acl / Set-Acl, то начнем работать в системах unix, не зная, как разрешения хранятся на диске.

@ mmillar-bolis Я уже предлагал здесь подход с использованием сокетов: https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

Мы могли бы подумать о Start-Process pwsh -NoNewWindow -Credential $ cred. Не работает, но могло.

Обновление: .Net Core (и, я думаю, Windows API тоже) не позволяет запускать новый процесс, подключенный к той же консоли.

Единственный способ, которым мы можем воспользоваться, - это служба Windows с повышенными правами. Но мы должны создать такой сервисный процесс для «sudo», чтобы быть безопасным.
Таким образом, решением будет New-PSSession (или вызов в PSSession) на localhost с повышенными учетными данными пользователя.

@iSazonov Одна из единственных вещей, которые позволят вам прикрепить его к той же консоли, - это то, что я уже упоминал здесь: https://github.com/PowerShell/PowerShell/issues/3232#issuecomment -444849067

Теперь, когда Windows поддерживает сокеты unix, мы могли бы использовать либо их, либо именованные каналы, и привилегированная служба будет отвечать за проверку учетных данных и должна будет работать все время (по сравнению с вызовом через suid, как указано в связанной публикации для * nix oses) .

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

@ agowa338 "де-факто" ваше предложение - удаленное взаимодействие PowerShell. Это уже реализовано.

Но

Таким образом, решением будет New-PSSession (или вызов в PSSession) на localhost с повышенными учетными данными пользователя.

не работает для localhost. Выдает только AccessDenied.

За исключением одного из них:

• UAC выключен
• вы пытаетесь подключиться к BUILDIN \ Administrator без включения режима утверждения администратором.
• процесс (powershell) уже повышен.

Вот хорошее объяснение, почему это от @ jborean93 : https://github.com/PowerShell/Win32-OpenSSH/issues/1308#issuecomment -448430464

Поэтому нам нужна привилегированная служба, действующая в качестве брокера, или необходимо изменить один из API-интерфейсов, но это не то, что мы могли бы сделать в PowerShell / PowerShell, и это должно быть делегировано сотрудниками Microsoft внутри компании.

@ agowa338 Комментарий, на который вы ссылались, касается локального Windows API, а не удаленного взаимодействия PowerShell, о котором шла речь.

@iSazonov : Вы хоть раз пробовали делать удаленное взаимодействие Powershell с localhost? Я сделал, и это не работает по причинам, изложенным выше. Назначение accesstoken заблокировано ОС.

Удаленное подключение PowerShell к localhost не позволяет получить повышенные привилегии на локальном компьютере.

Однако удаленное взаимодействие PowerShell предоставляет вам повышенные привилегии на всех других хостах в сети, кроме localhost (при условии, что вы являетесь членом Domain-Admins и т. Д.).

Вот почему нам нужен эквивалент sudo для Windows. Если удаленное взаимодействие PowerShell будет вести себя так, как вы думаете, этот билет можно было бы закрыть, написав пример в документации, поскольку эта функция уже существует.

@ agowa338 У вас не работает из-за защиты. Это не особенность ОС. Вы можете настроить WinRM, как описано в документации https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting . Проблема, на которую вы ссылались, также говорит, что это работает для SSH (шаги указаны в этой статье).

поскольку функциональность уже существует.

Просьба заставить работать «sudo Remove-Item foo.txt, где foo.txt принадлежит пользователю root».
Не работает, но хотелось бы.
Проблема состоит из двух частей: синтаксического сахара в языке и реализации.

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

about_Remote_Troubleshooting - PowerShell

Это не работает для вас из-за защиты. Это не особенность ОС. Вы можете настроить WinRM, как описано в документации.

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

Просьба заставить работать «sudo Remove-Item foo.txt, где foo.txt принадлежит пользователю root».

Для систем, отличных от Windows, мы могли бы использовать подход сокетов unix для реализации олицетворения / повышения прав для удаленного взаимодействия с PowerShell.

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

Большинство атак нацелены на местную возвышенность. Так что все конфиги "по умолчанию безопасны". WMI, WinRM, IIS loopback и т. Д. - все подсистемы отключают функции, которые позволяют локальное повышение прав.
Это не так важно для обсуждения. Даже если удаленное взаимодействие PowerShell не позволяет нам выполнять sudo по умолчанию, мы можем реализовать его отключенным по умолчанию или разрешить только интерактивный сеанс.

Вы начали говорить об окнах, для систем, отличных от Windows, мы могли бы использовать подход сокета unix для реализации олицетворения / повышения прав для удаленного взаимодействия с PowerShell.

У нас должен быть одинаковый UX для всех платформ. Действительно там PSRP работает поверх транспорта - WinRM или SSH. MSFT сказал, что им нравится SSH, но я не вижу заметного прогресса за последние два года. И невероятно, что они захотят третий протокол в _ ближайшем_ будущем - слишком много работы (необходимость поддерживать совместимость со старыми системами).

Большинство атак нацелены на местную возвышенность. Так что все конфиги "по умолчанию безопасны". WMI, WinRM, IIS loopback и т. Д. - все подсистемы отключают функции, которые позволяют локальное повышение прав.
Это не так важно для обсуждения. Даже если удаленное взаимодействие PowerShell не позволяет нам выполнять sudo по умолчанию, мы можем реализовать его отключенным по умолчанию или разрешить только интерактивный сеанс.

Некоторое время назад я пытался включить это, и многие другие неоднократно повторяли мне, что это ограничено внутренней ОС, и это невозможно ни в коем случае без подключения приложения к внутреннему устройству Windows. Фактически, многие указывали на упомянутые выше ограничения API Windows и использовали это как аргумент в пользу того, почему PowerShell никогда не мог предоставить такую ​​возможность. И кто-то даже сослался на CVE, в которой намеренно удалено повышение уровня обратной петли. Поэтому извиняюсь за то, что захожу в кроличью нору немного глубже, но что мне нужно настроить, чтобы она работала? Это хоть где-нибудь задокументировано?

У нас должен быть одинаковый UX для всех платформ. Действительно там PSRP работает поверх транспорта - WinRM или SSH. MSFT сказал, что им нравится SSH, но я не вижу заметного прогресса за последние два года. И невероятно, что в ближайшем будущем они захотят третий протокол - слишком много работы (необходимость поддерживать совместимость со старыми системами).

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

• PSRP: SSHing to localhost работает для повышения прав в Windows и Linux, поэтому при использовании подсистемы psrp у нас уже есть правильные разрешения, поэтому для передачи объектов необходимо унифицировать только уровень PowerShell. Правильно?
• Использование сокетов unix также обеспечит аналогичную функциональность, такую ​​как удаленное взаимодействие с PowerShell, но на момент написания я предположил, что это жесткое ограничение для выполнения локального повышения без какой-либо дополнительной службы, работающей как локальная система, для выполнения обмена токенов ...

Поэтому, поскольку удаленное взаимодействие с PowerShell уже существует (а также вроде уже работает по ssh), мы должны сделать это решение приоритетным.

И кто-то даже сослался на CVE, в которой намеренно удалено повышение уровня обратной петли.

Я не могу подтвердить. Я предполагаю, что CVE может просто отключить loopback по умолчанию, но не совсем.
См. Также https://github.com/PowerShell/PowerShell/issues/3874#issuecomment -510715727

@iSazonov : Это не работает, он предоставляет только токен доступа с низким уровнем привилегий, но не токен доступа с повышенными правами (например, Mandatory Label\High Mandatory Level ). Я не получаю административных разрешений из оболочки PowerShell с низким уровнем привилегий, хотя для TrustedHosts установлено значение * для меня. Маркер входа всегда имеет интерактивный тип, даже после Enter-PSSession.
На самом деле я могу Enter-PSSession localhost -ScriptBlock {} но передача учетных данных вызывает отказ в доступе. , нет, он всегда выдает "Доступ запрещен", если в другой системе отключен uac.

Но теперь я попробовал это также с использованием SSH, и он работает, как ожидалось, предоставляет токен с повышенными правами ( Mandatory Label\High Mandatory Level ) с типом входа в систему Network.

Следовательно, в PSCore мы можем полагаться на psrp для повышения прав (даже локально через Enter-PSSession -HostName localhost который также работает с явной передачей учетных данных.
Где Enter-PSSession -ComputerName localhost -Credential $foo - нет (даже если $ foo.Username совпадает с именем текущего пользователя)

@ agowa338 Я думаю, нам не следует здесь обсуждать обход функций безопасности WinRM (это область соответствия требованиям). Я могу только указать (1), что независимо от протокола, безопасность должна оставаться на том же уровне, что означает, что петля SSH должна вести себя так же, как для WinRM, с учетом того, как работают внутренние компоненты Windows, (2) реализация sudo PS должна работать поверх любой транспорт.

@iSazonov : Я не просил об эксплойте, а только о том, что нужно настроить для его включения. Кроме того, вы, кажется, единственный, кто понял, как настроить WinRM, чтобы разрешить повышение уровня обратной связи.
Я очень долго пытался включить это. Все вопросы (по stackoverflow, reddit, github issues, ...) я натыкаюсь на «windows is wird», «не знаю, что там делают окна», «нигде не задокументировано», «Windows не предоставляет эта возможность »,« Использовать Linux вместо этого »,« Отключить UAC »,« Вам необходимо написать брокерскую службу, работающую с системными привилегиями ». Так что если разобрались, поделитесь своими знаниями.

Я могу только указать (1), что независимо от протокола безопасность должна оставаться на том же уровне

Что вы имеете в виду?

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

Что ж, у SSH есть системная служба, которая действует как брокер в фоновом режиме, чтобы делать именно это. Он предоставляет токен доступа к сети ...

(2) PS sudo реализация должна работать на любом транспорте.

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

если разобрались, поделитесь знаниями.

@ agowa338 Команда MSFT попросила меня не обсуждать безопасность публично, и я следую CoC. Я поддерживаю ваше желание глубоко изучить эту тему, но в рамках этого обсуждения для MSFT является головной болью, как интегрировать это решение в Windows и обеспечить соответствие требованиям безопасности.

Ну это никому не помогает.

Чтобы вызвать это:

• Вы говорите, что в WinRM есть возможности, подобные sudo.
• Ни о том, что он существует, ни о том, как его включить / отключить, не задокументировано.
• Раскрытие того, как его использовать, было бы угрозой безопасности.

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

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

@ agowa338 Мы собрали достаточно информации, чтобы команда MSFT могла сделать вывод. Если они обнаружат проблемы с безопасностью, они покажут нам приемлемый альтернативный способ.

Это было возможно, но было исправлено ранее в этом году https://devblogs.microsoft.com/powershell/windows-security-change-affecting-powershell/ с помощью исправления KB4480116 и любых последующих кумулятивных обновлений. До этого обновления можно было повысить ваши привилегии, если для LocalAccountTokenFilterPolicy установлено значение 1, что и делает winrm quickconfig (и действительно требуется для WinRM).

Там есть примечание о том, что конечные точки JEA не затронуты, поэтому потенциально вы можете создать свой собственный PSSessionConfiguration и подключиться к нему, но я не тестировал это, чтобы проверить. Лично я считаю этот патч глупым, поскольку он просто останавливает клиент PowerShell от подключения к localhost, но вы можете легко его обойти, если знаете, что делаете. Например, я все еще могу перейти от ограниченного к повышенному, не касаясь UAC, используя SSH или другой клиент PSRemoting, например

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

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

Group Name                                                    Type             SID          Attributes

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

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

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

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

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

Group Name                                                    Type             SID          Attributes

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

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

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

Group Name                                                    Type             SID          Attributes

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

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

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

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

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

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

В конечном итоге это означает, что в Windows нет официального способа повысить ваши привилегии с ограниченных до администраторских неинтерактивным образом. Использовать Start-Process ... -Verb Runas довольно просто, но для отображения запроса UAC требуется интерактивный вход в систему. Наличие механизма, подобного sudo, помогло бы решить эту проблему, но для того, чтобы сделать это правильно, потребуется работа в самой Windows, а не только для PowerShell. Существуют «обходные пути», но я бы не стал называть их официальными, и они являются лишь известным побочным продуктом включения WinRM.

PowerShell

Изменение безопасности Windows, влияющее на PowerShell |

Изменение безопасности Windows, влияющее на PowerShell 9 января 2019 г. В недавнем (1/8/2019) исправлении безопасности Windows CVE-2019-0543 внесено критическое изменение для сценария удаленного взаимодействия PowerShell. Это узкий сценарий, который не должен иметь большого влияния на большинство пользователей. Критическое изменение влияет только на удаленное взаимодействие с локальной петлей,

Блог Марка

PsExec, Контроль учетных записей пользователей и границы безопасности

Я представил параметр -l для PsExec около полутора лет назад как простой способ выполнять процессы с правами обычного пользователя из административной учетной записи в Windows XP. В статье «Запуск от имени ограниченного пользователя - простой способ» Я описал, как PsExec использует API CreateRestrictedToken для создания контекста безопасности, который ...

Инженерная Windows 7

Обновление по UAC

Привет, Джон ДеВаан здесь, чтобы поговорить с вами о последних отзывах UAC, которые мы получаем. Большая часть нашей работы по завершению Windows 7 сосредоточена на реагировании на отзывы. Отзывы UAC интересны по нескольким аспектам процесса принятия инженерных решений. Я подумал, что изучение этих параметров приведет к интересному e7 ...

@iSazonov Ни одно из этих предложений не приведет к _пользовательскому-интерактивному_ повышению уровня команды из _в том же сеансе консоли_, особенно в среде, в которой _ отсутствует UAC_. Похоже, что вы можете выступать от имени Microsoft по этим вопросам, поэтому не могли бы вы пояснить, не заинтересованы ли они во введении такой функции, как я ее описал?

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

Похоже, что вы можете говорить от имени Microsoft по этим вопросам.

Я поддерживаю проект в сообществе, а не являюсь участником MSFT, и я не могу говорить от имени Microsoft.

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

_Все предложения имеют ценность; ни один из них не отвергнут. Обсуждение просто для сбора всех возможных предложений.

Сейчас я пытаюсь обобщить все предложения, чтобы мы могли двигаться вперед и не застаиваться.

Это я вижу.
Основной сценарий - внедрение пользователей Unix в Windows.

• Исторически пользователи Unix работали в одной консоли, и sudo изначально помогает им выполнять работу с повышенными правами в _same_ консоли.
• Исторически пользователи Windows при необходимости открывали новое окно с консолью с повышенными правами. Это хорошо работает много лет, потому что это удобно в многооконной среде. (Пользователи Windows также могут извлечь выгоду из pssudo, учитывая Windows Core и Nano)

Итак, ожидания таковы:

• pssudo работает только в интерактивных сессиях
• pssudo не открывает новую консоль (окно UAC приемлемо в Windows, мы не хотим нарушать безопасность и дух Windows)
• учетные данные своевременного псевдо-кеша
• pssudo не кэширует состояние сеанса в целях безопасности
• одинаковый UX (насколько это возможно) на всех платформах
• pssudo запускает собственные команды
• pssudo запускает блоки / файлы сценария PowerShell

Детали реализации:

• Удаленное взаимодействие PowerShell - наиболее мощное и функциональное решение. Он уже реализован и работает. Другим также пришлось бы эмулировать эту функциональность, чтобы исключить блоки сценария PowerShell для каждого пользователя / сеанса / пространства выполнения / состояния области.
• Предпочтительным транспортом является WinRM, потому что вся инфраструктура Windows основана на нем. В WinRM требуются некоторые инвестиции, хотя MSFT этого не хочет, потому что он основан на SOAP.
• SSH транспорт может быть. Это все еще не стандарт для Windows. Требуются большие вложения на внедрение и обслуживание. И есть проблема с поддержкой старых систем.
• Другие транспорты, такие как сокеты Unix. Требует больших вложений не только в инфраструктуру, но и в PowerShell.

@ mklement0 Интересно, что я делаю здесь то, что обычно у тебя получается отлично :-) Ты лишил меня возможности быть противником :-)

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

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

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

Следует иметь в виду, что независимо от того, как это будет реализовано, всегда существует переход к процессу с повышенными правами и обратно. Это означает, что у вас всегда будут десериализованные объекты в конвейере, и эти ограничения будут применяться. Во многих случаях это не будет проблемой, но если командлет ожидает живой объект .NET, он не будет работать.

Для поддержки JEA с SSH нам в конечном итоге понадобится универсальный демон / служба, которая в любом случае заменяет WinRM в качестве этой службы. В то время мы оценили бы, используя это, чтобы поднять часть трубопровода.

К вашему сведению: https://github.com/gerardog/gsudo

GitHub

gerardog / gsudo

Sudo для Windows - запускайте с повышенными правами, не перекрывая новое окно хоста консоли - gerardog / gsudo

К вашему сведению: https://github.com/gerardog/gsudo

GitHub gerardog / gsudo A Sudo для Windows - запускать с повышенными привилегиями без перекрытия нового окна хоста консоли - gerardog / gsudo

Даже лучше
http://blog.lukesampson.com/sudo-for-windows

GitHub

gerardog / gsudo

Sudo для Windows - запускайте с повышенными правами, не перекрывая новое окно хоста консоли - gerardog / gsudo

Люк Сэмпсон - Sudo для Windows

Sudo для Windows

Даже лучше

Нет.

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

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

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

@majkinetor эта проблема была выделена в https://github.com/PowerShell/PowerShell/issues/11343 для дальнейшего обсуждения дизайна