Как стать автором
Обновить

[Конспект админа] Что делать, если программа хочет прав администратора, а вы нет

Время на прочтение 7 мин
Количество просмотров 189K
Всего голосов 86: ↑86 и ↓0 +86
Комментарии 88

Комментарии 88

С картинками беда — они не подгружаются в пост.
Спасибо, поправили
Время от времени сталкиваюсь с инсталляторами, которые, несмотря на поддерживаемый портабельный режим, при запуске требуют обязательных админских прав. Хак с __COMPAT_LAYER иногда помогает, но часть инсталляторов оказываются хитромудрыми и сами себя перезапускают с требованием повышенных привилегий, игнорируя эту переменную.
а это точно инсталлятор перезапускается, а не инсталлятор распаковывается и запускает бинарник? во втором случае хак может не помочь, в отличие от фикса через тулкит
Последний раз, когда я на это наткнулся, в диалоге UAC было указано, что запускается тот же самый файл, что стартанул я, но с дополнительными параметрами. Но да, бывает, что и распакованный файл стартует; я забыл про такой сценарий, хотя тоже сталкивался.
Если запускается тот же файл, то, скорее всего, это инсталлятор от InnoSetup. Его можно распаковать программой innounp
Да, я обычно в таких случаях как раз и пытаюсь распаковать. Но не всегда это оказывается Inno. Бывает, что и UniExtract не справляется.
а это точно инсталлятор перезапускается, а не инсталлятор распаковывается и запускает бинарник? во втором случае хак может не помочь, в отличие от фикса через тулкит

А разве переменные среды окружения не наследуются дочерними процесами?
Во-первых, зависит от аргументов, переданных функции запуска процесса.
Во-вторых, если программа явным образом запускает другую с повышенными привилегиями, то, насколько я понимаю, переменная игнорируется.
Скажите, что со скайпом делать? Он без админских прав не обновляется.
Попробуйте дать пользователю права на папку со Skype, либо устанавливать не в Program Files.
Насколько я помню, скайп по умолчанию туда ставит (он вообще не спрашивает куда его поставить)
Использовать web.skype.com, создать ярлык из Chrome, выглядит практически как скайп-standalone — пользователи не видят разницы

Использую плиточный Скайп, но он глючит

> Ведь bnk.exe — самораспаковывающийся архив, в котором зачем-то прописано «Требовать права администратора».

— Скажите, а как Вы справляетесь со стрессами?
— Нахожу источник стресса и ломаю ему ноги

Там в bnk.exe координаты автора не указаны, не?

В powershell для шифрования можно использовать сертификат, который будет распространяться через pki, а работать с ними можно через командлеты *-cmsmessage

А вам приходилось городить странные костыли?

Было несколько лет назад такое: написали сервис, который требовал для работы минимум IE10, а лучше хромиумное что-то или Fx.
У пользователей есть в лучшем случае IE9. Безопасники лютуют: приложения запускаются только по белому списку, а хром официально запрещено запускать (даже если установить переносную версию). Пользователи тоже не всегда отличаются умом и сообразительностью, им чем проще — тем лучше.
При этом безопасники готовы разрешить запуск одного проверенного ими приложения, с условием, что с его помощью за пределы указанного сервиса выбраться будет нельзя; если приложение будет хотя бы выглядеть как один цельный бинарник, шанс пройти проверку у него будет выше.
То есть нужно этакое окно на один-единственный сайт. Тупо sitename.exe, можно даже без браузерного интерфейса, вся навигация вполне обеспечивается самим сайтом.

Мысль нулевая: допилить ресурс, чтобы работал в старых версиях IE. С негодованием отвергается всеми, ещё полчаса разработческий чатик кипит ненавистью.
Мысль первая: взять хромиум, допилить, собрать на его базе sitename.exe. Отказано по очевидным причинам.
Мысль вторая: сваять на чём-то вроде Delphi приложение с веб-контролом. Для Дельфи есть хромиумный компонент, так что идея не выглядела нереализуемой. Но хотелось ещё проще, и без добавления сущностей.
Мысль третья: доработать сам сервис, впилив в него какое-нибудь REST API, а потом на любом ЯП под любую платформу пилить нативные приложения. В целом идея зашибись, но требует времени (а sitename.exe нужен послезавтра) и сил на поддержку (каждую клиентскую фичу нужно дублировать в API и в приложении).
Мысль четвёртая: взять браузер, и виртуализировать его в чём-то наподобие XenApp. Идея ложится со скрипом — добавляется новая сущность в виде среды виртуализации, на которую безопасники могут залупиться ещё сильнее, например.
Мысль пятая: сделать приложение на каком-нибудь специально созданном для этого инструменте, типа электрона или что там в те годы было. Но дико не хочется тащить за собой весь обвес и поддерживать тоже.

Остановился я вот на чём: взял браузер Vivaldi, интерфейс которого написан на HTML+JS+CSS, а кишки — всё тот же хромиум. Не буду отдельно расписывать все манипуляции (они здесь, кому интересно), но в итоге получилось выкинуть из браузера весь интерфейс и меню, убрать хоткеи, впилить в него белый список и отучить ходить за пределы собственного каталога. Получилось просто окно, в котором открывался и нормально работал нужный сайт:
image

Каталог с браузером убирался в sfx-архив sitename.exe. Безопасники внесли в белый список этот файл и %tmpdir%\vivaldi.exe — и voilà, задача решена с приемлимым количеством приседаний.

И, в общем, этим костылём пользовались, пока пользователей не перевели на яндекс.браузер.

А почему это проще, чем


сваять на чём-то вроде Delphi приложение с веб-контролом.
Такого на Delphi я не делал (речь не о дефолтном контроле, наследуемом, вроде бы, из системного IE, а о чём-то хромиумном), да и сам язык на тот момент уже подзабыл. Ловить ошибки на чужих компах (а они, в такой ситуации, неизбежны), опять же, — ну, не то, чтоб нереализуемо, но… Стоило сначала попробовать другие варианты.
И с вивальди сразу и хорошо получилось, буквально за час времени.

А почему в таком случае CEF не попробовали?

CEF

Я сейчас впервые вижу эту аббревиатуру.
Нет, я слышал, что встраивать хром как-то можно, но и тогда, и сейчас не знал, как. Соответственно, такое решение просто не пришло мне в голову. А опыт деконструкции Вивальди уже был, вот и всплыло.
CEF, он же Chromium Embedded Framework. Сам написан на C++, но есть множество форков. Хороший вариант, когда нужна автоматизация при отсутствии API, или когда нужен двиг браузера, но не нужен его обвес по UI.
Для личных проектов раньше пользовался еще Awesonium, сейчас кажется они Ultralight называются. Единственный минус: free for non-commerce. В остальном очень похож был на CEF.

PS. А IE контрол обычно дергает установленный в системе IE, а это привет той же проблеме, от которой вы хотели сбежать.

А чем это концептуально отличается от electron?

Тем что electron — фреймворк для создания приложений вокруг браузера, а CEF — для встраивания браузера в приложения.

Electron - это фронтенд и бэкенд в одном флаконе (Node.js для логики + Chromium для рендера). CEF - это чисто браузер.

Странно, что хром запретили, а Вивальди — нет. Он же на том же движке, если не ошибаюсь?

Не ошибаетесь. Я махнул рукой на поиски логики в тех решениях.
НЛО прилетело и опубликовало эту надпись здесь
<sarcasmmode=on>
Уже пора написать что в линуксе таких проблем нет?
<sarcasmmode=off>
chroot?
Я читал, что в Windows теперь есть sandbox. Очень было бы интересно, если бы можно было бы что-то по аналогии с flatpak в Windows использовать. Одна из проблем, которую я вижу у друзей — это при слетании системы или вылетании диска все нужно переустанавливать. Было бы круто, если бы просто были файлы с контейнерами с софтом, все упростилось бы.
В одной из контор где я работал админские права на собственную рабочую станцию были у всех пользователей. Ииии… И ничего, ни одного происшествия связанного именно с этим.
Намекаете что те, у кого случилась таки неприятность — погибли, и не могут нам об этом рассказать?
В данном случае можно трактовать чуть шире — если я чего-то не видел/не знаю, то это не значит что это не случалось. При желании впрочем можно придумать сценарии когда не вовремя вышедший из строя компьютер может стоить кому-то жизни.
Ну а если серьёзно, то мой не малый опыт админства говорит о том, что ничего хорошего с админскими правами не случится. С появлением UAC конечно в этом плане стало гораздо легче, а вот во времена XP это была реально беда. К полностью неработоспособной системе это может приводило и не столь часто, но зоопарки были знатные. Тут ведь опять же как оценивать происшествие, есть оно или нет? Вот сидит скажем среднестатистический бухгалтер среднестатистической конторы и всё у него вроде и хорошо, ему-то какое дело, что на машине зоопарк? Потом во всей конторе перестаёт почта отправляться и оказывается, что провайдер TCP 25 заблокировал потому что спам валил. Шифровальщиков-вымогателей тогда не придумали ещё и незамедлительный эффект не наступал.
Я тоже видел админские права у обычных пользователей, хотя постойте — это же была вирлаба ЛК, так что пользователи были не такие и простые
Я рискну предположить, что тут иная ситуация.
Система считается надежной, потому что она работает и при этом не ломается. А не ломается она просто потому, что ее никто особо и не пытается ломать. (Эдакий Неуловимый Джо — его никто не ловит, потому что он задаром никому не нужен). Хотя сломать можно все что угодно, если хорошо постараться, но принцип разумной достаточности никто не отменял.

Это я к тому, что если организация небольшая, работа преимущественно конторская, и все сотрудники на виду и все грамотные, то такой подход (да пускай все работают под админскими аккаунтами с пустыми паролями, главное чтобы у всех антивирусы работали, обновления ставились, и резервные копии создавались своевременно) — вполне допустим. Для крупной организации, (например, для банка) — уже категорически недопустим.
Знаю пару мест, где тоже так думали… пока не грохнуло. Времени на всё про всё уходило 10-15 лет. Ресурсы злоумышленникам нужны всегда; не найдут сами, что с ними делать, так коллегам доступы продадут. И по фигу, крупная это контора или никому не нужная мелочь.
Это примерно как пользователи говорят мол я 7 лет без антивируса и ничего. И приэтом куча тех, кто стал жертвами вымогателей тоже работая и не защищаясь.
Как и куча тех, кто с любыми системами защиты умудряется поналовить всякого разного, от рекламы проституток, до локера. В реале люди думают куда и где идут и с кем контактируют, но в интернете им на все пофиг и принцип один: если что-то вылезло, значит надо ткнуть, и пофиг, что оно ведет не пойми куда.

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

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

Вторая часть утверждения:
Если неприятность не может произойти, то она всё равно где-нибудь произойдет. Причем произойдет в таком месте, где её никто не ожидает...

10 лет езжу на летней резине круглый год (снег/лёд присутствуют) без происшествий — подход можно считать безопасным и проверенным временем.

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

Я не автомобилист, но, кмк, вполне себе разумный подход, если аккуратно водить: самая низкая температура в январе, но и она колеблется от -2 до +3 по Цельсию, то есть днём льда на дорогах, наверное, мало. Погода с 1971 по 2000


Ну, и я надеюсь, что 10 лет не на одних и тех же шинах. :)

что 10 лет не на одних и тех же шинах
Почему нет? Если пробег в пару тыщ в год…
от времени на ней появляются трещины
Если чистый асфальт, то не страшно, а если каша, то риски возрастают многократно, особенно учитывая, что мало кто из водителей (практически никто) вообще умеет управлять машиной в заносе и сносе. Первый снег каждый год это подтверждает, ибо заранее почти никто не переобувается.
И шито может произойти? убить свои документы можно и без админских прав. Убитая станция расскатывается из образа за время сравнимое с его копированием, то есть это не трабл. Антивирь управляемый доменными политиками не даёт локальному админу разгуляться слишком сильно.

В общем, моё ИМХО — самое ценное на компе это то, что делает пользователь под своими правами. Если это не защищено, то оно выстрелит и без админ прав. А если защищено, то локальное админство не страшно ни разу.

С антивирусом — особо ничего

Вот бы еще кто объяснил как «Брат 2: Обратно в Америку» запустить из-под свежей винды :)
Да там глухо — это древняя игрушка, в которой захардкодена проверка на версию винды = 98 и если не совпадает, то не идет ни в какую. Там уже копий на форумах много сломано и в определенной мере название игры стало именем нарицательным в том смысле, что «не работает чуть менее, чем полностью»

Если 98/95, то её можно навернуть поверх DosBox.

Существует windows-версия Wine.

Использовал неоднократно Admlink для выдачи прав админа на определённые программы (в частности для установки шрифтов в Windows через ПО FontManager) Благо что с 1903 поддерживается установка шрифтов в пространство пользователя и от этого элегантного «костыля» отказался. Хочу так же заметить что в домене прекрасно работает один и тот же ярлык, созданный с помощью Admlink на всех компьютерах без необходимости внесения дополнительных изменений.
Шрифты кладутся в произвольный каталог и динамически грузятся в сессию пользователя менеджером шрифтов. Оно так изначально спроектировано ещё с 2k (а то и с NT), нужно только подобрать по вкусу сторонний сторонний менеджер шрифтов.
Возможно вы правы, однако эмпирические тесты со встроенным менеджером шрифтов Corel Draw показали что без прав админа он не хочет запускаться.
Ну так это потому что генерируется строка запуска не от локального, а от доменного админа. А его идентификатор, внезапно, на всех пк в домене одинаков)
Используемая учётная запись имеет у меня только права локального админа, однако да. Ваш посыл про единый SID для пользователя верен. И именно поэтому я обратил на это внимание не вдаваясь в технические подробности. Факт в том, что программа исправно работает на иных компьютерах даже если на нём никогда не вводились админские учётные данные которые «зашиты» в ярлыке.
Возник вопрос в обратную тему, но тоже на тему костылей: никто не знает приемлемого способа залогиниться/запустить определённую программу под учёткой юзера от админа, не зная пароля юзера? Виндовый такой аналог su/sudo? Часто поддержке нужно, когда разбирают заявки, пришедшие с другого конца света, когда сессии юзера живой нет давно, а воспроизвести проблему нужно…
Если есть админиские права, то создать тестового юзера с аналогичными правами не проблема, и воспроизвести ситуацию из под него.
Вы прям КО… В нормально энтерпрайз среде очень часто нужно запустить определенное ПО с профилем определенного пользователя.
Побуду, ещё одним капитаном )
Имхо, если такое возможно — то это серьезная дырка в безопасности. Или у вас админы «святее папы римского»?
А так, сменить пароль пользователя на новый, сообщить пользователю чтобы сменил обратно.

Упс, поторопился написать — ниже уже обсуждено.
Все *nix системы с этой «дырой» как-то справляются :) Админ в любом случае практически все может прочитать, что не зашифровано.

Зависит от требуемой широты решения.


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


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

Не очень понял как мне помогут обозначенные решения. Сценарий моей постоянной головной боли таков:

1. Есть некое проприетарное ERP-ПО (например DATEV немецкий), они связывают логины в ДЦ с Windows SID юзера. Профиль пользователя локальный лежит в %APPDATA% и зашифрован ключом, который приходит с ДЦ для нужного SID.
2. Пользователь рапортует о проблеме внутри этого ПО.
3. Админ входит под своей учеткой (ессна получает другой профиль), у него проблема не воспроизводится (все работает штатно).
4. Ему нужно зайти к пользователю, чтобы воспроизвести проблему, которая завязана на его профиль и разобраться в ней. Можно бы залезть как-то удаленно к пользователю, но сам пользователь уже оффлайн.

Как быть?

Понял, Вы правы. Тогда у меня нет ответа для решения задачи в общем случае. Могу только посоветовать Windows Remote Assistance — если все компы в домене, можно удаленно попросить пользователя дать управление. Будет такой аналог RDP, однако пользователь будет физически видеть всё, что Вы делаете (ну т.е. курсор будет сам ездить). Хотя уверен, вы уже это опробовали, так что каких-то новых идей нет...

Как я уже сказал — что делать если пользователь оффлайн? Т.е. к моменту обработки его заявки он залогаутился и ушел домой. Удаленные сессии у нас давно настроены двумя разными способами…
Как я уже сказал — что делать если пользователь оффлайн

Заходить от имени пользователя без его ведома, да еще и не оставляя следов — опасно, так как по сути это дыра в безопасности. Условно, перестает работать аудит, так как теперь учетная запись человека уже не аутентифицирует её.


Однако и тут есть путь, хоть он и более сложный. В новом Active Directory можно добавить свой authentication method. В этом случае проверка пароля может быть делегирована внешнему сервису. Этот метод используется, например, для нестандартных удаленных рабочих столов (когда у пользователя только тонкий клиент, так что при старте удаленного строла сам пароль может не спрашиваться).


Получается следующая схема:


  1. Сначала необходимо создать сервис, который будет аутентифицировать пользователя. В теории, если админ хочет зайти под чужим именем, ему надо запросить временный ключ у этой компоненты (конечно, с ttl и так далее).
  2. Необходимо настроить Active Directory, чтобы она доверяла этому сервису.
  3. Если админу надо зайти полностью под именем другого пользователя, он может запросить ключ у сервиса выше, а потом, с помощью него, зайти на машину. Мне пока непонятно, как самой клиентской винде сообщить об этом, однако, я думаю, здесь есть решение.

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

Уже интересно. Изучу вопрос, спасибо за наводку.
«Если надо иногда некоторым пользователям на время давать права администратора. Можно разрешить пользователю запускать только определенное ПО от админа, или же давать это право только на пару часов (например).»
Дав даже один раз запустить софт от админа, юзеру не проблема (в Windows точно) тут же нарулить себе на данной машине права локального админа навсегда. Если это удаленный рабочий стол, то юзер станет админом этого терминального сервера… Класс!

Вы 100% правы, подобная техника может худо-бедно работать только в случае, когда есть иное следящее ПО (которое следит за изменениями чувствительных компонентов системы, плюс само по себе является трудновзламываемым).
Математически, подобные действия приводят к мгновенной компрометации системы (как вы и сказали, всё верно).


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


Однако я отвечал на конкретный вопрос. Я уверен, что Programmierus в курсе, что даже временные админские права опасны.

Почему бы просто не использовать fakeroot?

А есть ли эквивалент его под Винду?

Sandboxie — собраются открыть свой код. Интересно.
Не давать админские права, принудительно запрещать/разрешать запуск тех или иных программ — это все мне понятно. Но мне решительно непонятно другое: ведь в МакОС подобных механизмов не существует (или я ошибаюсь?), как с ними-то в корпоративной среде справляются? Или просто забивают с учетом их малочисленности и малой распрострененности троянов и проч?
Тоже интересно было бы послушать как оно делается на самом деле, но пока можно предположить что поскольку макось unix-based, то и решается все аналогичными методами — дается sudo на нужные команды. Если такие кейсы с требованием повышенных привилегий вообще там случаются конечно.
Как меня просветили более опытные товарищи, МакОС тоже поддерживает ограничения на манер Винды: принудительная установка апдейтов, запрет/разрешение запуска тех или иных приложений и т.д. Зарулить можно так, что юзер вообще шагу в сторону ступить не сможет.

Управляется все это дело либо через Active Directory, либо через Mac OS Server (есть и такой, оказывается: www.apple.com/ru/macos/server), либо через сторонние продукты, например:


а есть какая-нибудь ссылка на документацию по управлению макосью чисто через AD? насколько мне известно, тут только сторонние продукты, которые дружат с AD (почти любой MDM, или монстры типа MS SCCM)…

Это все хорошо, когда админ сам знает, как настроить доступы и разбирается с неисправностями. А на практике, ты должен полдня гуглить, чтобы потом обьяснить админу, какие кнопки надо нажать, чтобы, например, docker desktop на винде заработал без админских прав и за непрозрачной проксей. В итоге вместотрешения ннпосредственной задачи, ты работаешь за админа. А админ потом за тебя — не работает. И так везде. А статья хорошая. В вакууме.

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

Да админ-то опытный, а вот руководство далеко и безопасники советской закалки. И специфика работы моей такая, что я не могу заранее сказать, что мне нужно, я ставлю эксперименты, пробую, создаю, удаляю. За каждым чихом админа звать неудобно. Если бы суперадмин знал почему утилита х в конкретно в нашей сети в линуксе не работает с моей машины — было бы круто. А так я должен это загуглить, провести пару проверок гипотез (для которых требуются права админа) и потом сработавшую гипотезу применить, несработавшие почистить. Админ стоит над плечом чисто для ввода пароля. В итоге человекочасы*2. А безопасность налицо — пароли всевозможных проксей в открытом виде в куче линукс-конфигов. Даешь интернет, б… ть!

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

1. Поиск конкретных мест где нужны права. Это хорошо если права нужны только на запуск, а если в процессе работы появляются такие моменты, то нужно заново траблшутить. И это еще хорошо если ПО прямо говорит «permission denied», а то бывает просто падает без конкретных ошибок.
2. Запуск разными средствами от имени админской УЗ это рабочий вариант, но только если идет локальная работа. Что делать при сетевом доступе, когда каждый пользователь состоит в десятках разных групп, а где-то прописан напрямую. Создавать 2 УЗ на каждого пользователя? Как то не очень…
3. Что делать с софтом, у которого права администратора прописаны в системных требованиях? А ТП сразу отклоняет все запросы если их софт работает без прав администратора. Каждую проблему тестировать с правами, а потом убирать назад?
Да на виртуалке её запустить типа Virtual PC. И всё.
Да на виртуалке её запустить типа Virtual PC. И всё.

А если ей требуется взаимодействие с другим ПО, ну или это программа ставится как дополнение/расширение функционала имеющегося ПО?
Так оно обычно и бывает, если это не основная программа, а вспомогательная утилита.
А если основная, то ей нужен доступ к сетевым принтерам, сетевым папкам и т.п. — еще раз настраивать полноценную рабочую станцию.
Еще есть вопрос про стоимость лицензии Windows, той, что запускается в виртуальной машине.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий