Комментарии 88
а это точно инсталлятор перезапускается, а не инсталлятор распаковывается и запускает бинарник? во втором случае хак может не помочь, в отличие от фикса через тулкит
А разве переменные среды окружения не наследуются дочерними процесами?
— Скажите, а как Вы справляетесь со стрессами?
— Нахожу источник стресса и ломаю ему ноги
Там в bnk.exe координаты автора не указаны, не?
В powershell для шифрования можно использовать сертификат, который будет распространяться через pki, а работать с ними можно через командлеты *-cmsmessage
А вам приходилось городить странные костыли?
Было несколько лет назад такое: написали сервис, который требовал для работы минимум IE10, а лучше хромиумное что-то или Fx.
У пользователей есть в лучшем случае IE9. Безопасники лютуют: приложения запускаются только по белому списку, а хром официально запрещено запускать (даже если установить переносную версию). Пользователи тоже не всегда отличаются умом и сообразительностью, им чем проще — тем лучше.
При этом безопасники готовы разрешить запуск одного проверенного ими приложения, с условием, что с его помощью за пределы указанного сервиса выбраться будет нельзя; если приложение будет хотя бы выглядеть как один цельный бинарник, шанс пройти проверку у него будет выше.
То есть нужно этакое окно на один-единственный сайт. Тупо sitename.exe, можно даже без браузерного интерфейса, вся навигация вполне обеспечивается самим сайтом.
Мысль нулевая: допилить ресурс, чтобы работал в старых версиях IE. С негодованием отвергается всеми, ещё полчаса разработческий чатик кипит ненавистью.
Мысль первая: взять хромиум, допилить, собрать на его базе sitename.exe. Отказано по очевидным причинам.
Мысль вторая: сваять на чём-то вроде Delphi приложение с веб-контролом. Для Дельфи есть хромиумный компонент, так что идея не выглядела нереализуемой. Но хотелось ещё проще, и без добавления сущностей.
Мысль третья: доработать сам сервис, впилив в него какое-нибудь REST API, а потом на любом ЯП под любую платформу пилить нативные приложения. В целом идея зашибись, но требует времени (а sitename.exe нужен послезавтра) и сил на поддержку (каждую клиентскую фичу нужно дублировать в API и в приложении).
Мысль четвёртая: взять браузер, и виртуализировать его в чём-то наподобие XenApp. Идея ложится со скрипом — добавляется новая сущность в виде среды виртуализации, на которую безопасники могут залупиться ещё сильнее, например.
Мысль пятая: сделать приложение на каком-нибудь специально созданном для этого инструменте, типа электрона или что там в те годы было. Но дико не хочется тащить за собой весь обвес и поддерживать тоже.
Остановился я вот на чём: взял браузер Vivaldi, интерфейс которого написан на HTML+JS+CSS, а кишки — всё тот же хромиум. Не буду отдельно расписывать все манипуляции (они здесь, кому интересно), но в итоге получилось выкинуть из браузера весь интерфейс и меню, убрать хоткеи, впилить в него белый список и отучить ходить за пределы собственного каталога. Получилось просто окно, в котором открывался и нормально работал нужный сайт:
Каталог с браузером убирался в sfx-архив sitename.exe. Безопасники внесли в белый список этот файл и %tmpdir%\vivaldi.exe — и voilà, задача решена с приемлимым количеством приседаний.
И, в общем, этим костылём пользовались, пока пользователей не перевели на яндекс.браузер.
А почему это проще, чем
сваять на чём-то вроде Delphi приложение с веб-контролом.
И с вивальди сразу и хорошо получилось, буквально за час времени.
А почему в таком случае CEF не попробовали?
CEF
Я сейчас впервые вижу эту аббревиатуру.
Нет, я слышал, что встраивать хром как-то можно, но и тогда, и сейчас не знал, как. Соответственно, такое решение просто не пришло мне в голову. А опыт деконструкции Вивальди уже был, вот и всплыло.
Для личных проектов раньше пользовался еще Awesonium, сейчас кажется они Ultralight называются. Единственный минус: free for non-commerce. В остальном очень похож был на CEF.
PS. А IE контрол обычно дергает установленный в системе IE, а это привет той же проблеме, от которой вы хотели сбежать.
Странно, что хром запретили, а Вивальди — нет. Он же на том же движке, если не ошибаюсь?
Уже пора написать что в линуксе таких проблем нет?
<sarcasmmode=off>
Ну а если серьёзно, то мой не малый опыт админства говорит о том, что ничего хорошего с админскими правами не случится. С появлением UAC конечно в этом плане стало гораздо легче, а вот во времена XP это была реально беда. К полностью неработоспособной системе это может приводило и не столь часто, но зоопарки были знатные. Тут ведь опять же как оценивать происшествие, есть оно или нет? Вот сидит скажем среднестатистический бухгалтер среднестатистической конторы и всё у него вроде и хорошо, ему-то какое дело, что на машине зоопарк? Потом во всей конторе перестаёт почта отправляться и оказывается, что провайдер TCP 25 заблокировал потому что спам валил. Шифровальщиков-вымогателей тогда не придумали ещё и незамедлительный эффект не наступал.
Система считается надежной, потому что она работает и при этом не ломается. А не ломается она просто потому, что ее никто особо и не пытается ломать. (Эдакий Неуловимый Джо — его никто не ловит, потому что он задаром никому не нужен). Хотя сломать можно все что угодно, если хорошо постараться, но принцип разумной достаточности никто не отменял.
Это я к тому, что если организация небольшая, работа преимущественно конторская, и все сотрудники на виду и все грамотные, то такой подход (да пускай все работают под админскими аккаунтами с пустыми паролями, главное чтобы у всех антивирусы работали, обновления ставились, и резервные копии создавались своевременно) — вполне допустим. Для крупной организации, (например, для банка) — уже категорически недопустим.
Я бы последнюю фразу сформулировал немножко по другому:
Пока еще не было ни одного происшествия, связанного с этим.
Потому что теория вероятности — это наука точная: если неприятность может произойти, то она когда-нибудь обязательно произойдет. Причем в самый неподходящий момент.
Вторая часть утверждения:
Если неприятность не может произойти, то она всё равно где-нибудь произойдет. Причем произойдет в таком месте, где её никто не ожидает...
10 лет езжу на летней резине круглый год (снег/лёд присутствуют) без происшествий — подход можно считать безопасным и проверенным временем.
Я не автомобилист, но, кмк, вполне себе разумный подход, если аккуратно водить: самая низкая температура в январе, но и она колеблется от -2 до +3 по Цельсию, то есть днём льда на дорогах, наверное, мало. Погода с 1971 по 2000
Ну, и я надеюсь, что 10 лет не на одних и тех же шинах. :)
что 10 лет не на одних и тех же шинахПочему нет? Если пробег в пару тыщ в год…
В общем, моё ИМХО — самое ценное на компе это то, что делает пользователь под своими правами. Если это не защищено, то оно выстрелит и без админ прав. А если защищено, то локальное админство не страшно ни разу.
Вам сюда: https://qna.habr.com/
Существует windows-версия Wine.
Зависит от требуемой широты решения.
Если надо иногда некоторым пользователям на время давать права администратора, то есть, например, Avecto Defpoint. Можно разрешить пользователю запускать только определенное ПО от админа, или же давать это право только на пару часов (например).
Более самостоятельно решение — можно создавать виртуальный аккаунт с нужными правами. Он будет удален, если я не ошибаюсь, когда завершатся все потоки с ним. Например, IIS использует эту технику, чтобы разделять разные пулы (чтобы сайты не лезли в память друг другу).
1. Есть некое проприетарное ERP-ПО (например DATEV немецкий), они связывают логины в ДЦ с Windows SID юзера. Профиль пользователя локальный лежит в %APPDATA% и зашифрован ключом, который приходит с ДЦ для нужного SID.
2. Пользователь рапортует о проблеме внутри этого ПО.
3. Админ входит под своей учеткой (ессна получает другой профиль), у него проблема не воспроизводится (все работает штатно).
4. Ему нужно зайти к пользователю, чтобы воспроизвести проблему, которая завязана на его профиль и разобраться в ней. Можно бы залезть как-то удаленно к пользователю, но сам пользователь уже оффлайн.
Как быть?
Понял, Вы правы. Тогда у меня нет ответа для решения задачи в общем случае. Могу только посоветовать Windows Remote Assistance — если все компы в домене, можно удаленно попросить пользователя дать управление. Будет такой аналог RDP, однако пользователь будет физически видеть всё, что Вы делаете (ну т.е. курсор будет сам ездить). Хотя уверен, вы уже это опробовали, так что каких-то новых идей нет...
Как я уже сказал — что делать если пользователь оффлайн
Заходить от имени пользователя без его ведома, да еще и не оставляя следов — опасно, так как по сути это дыра в безопасности. Условно, перестает работать аудит, так как теперь учетная запись человека уже не аутентифицирует её.
Однако и тут есть путь, хоть он и более сложный. В новом Active Directory можно добавить свой authentication method. В этом случае проверка пароля может быть делегирована внешнему сервису. Этот метод используется, например, для нестандартных удаленных рабочих столов (когда у пользователя только тонкий клиент, так что при старте удаленного строла сам пароль может не спрашиваться).
Получается следующая схема:
- Сначала необходимо создать сервис, который будет аутентифицировать пользователя. В теории, если админ хочет зайти под чужим именем, ему надо запросить временный ключ у этой компоненты (конечно, с ttl и так далее).
- Необходимо настроить Active Directory, чтобы она доверяла этому сервису.
- Если админу надо зайти полностью под именем другого пользователя, он может запросить ключ у сервиса выше, а потом, с помощью него, зайти на машину. Мне пока непонятно, как самой клиентской винде сообщить об этом, однако, я думаю, здесь есть решение.
Очень важно: это в прямом смысле дыра в системе и нарушение кучи политик. Подобный сервис должен пройти строгий аудит. Надеюсь, что на рынке уже есть коробочные решения.
Дав даже один раз запустить софт от админа, юзеру не проблема (в Windows точно) тут же нарулить себе на данной машине права локального админа навсегда. Если это удаленный рабочий стол, то юзер станет админом этого терминального сервера… Класс!
Вы 100% правы, подобная техника может худо-бедно работать только в случае, когда есть иное следящее ПО (которое следит за изменениями чувствительных компонентов системы, плюс само по себе является трудновзламываемым).
Математически, подобные действия приводят к мгновенной компрометации системы (как вы и сказали, всё верно).
С моей точки зрения, админам необходимо четко различать: или пользователь на компе может быть хотя бы иногда админом (тогда политика безопасности выстраивается так, что данный комп уже скомпрометирован, т.е. ему не доверяют). Или же нет (тогда проще; например, можно доверять работе программ, до которых пользователю не добраться). И если пользователь хоть иногда бывает админом, тогда в чем проблема разрешить ему всегда им быть (UAC оградит от детских ошибок)?
Однако я отвечал на конкретный вопрос. Я уверен, что Programmierus в курсе, что даже временные админские права опасны.
Почему бы просто не использовать fakeroot?
А есть ли эквивалент его под Винду?
Управляется все это дело либо через Active Directory, либо через Mac OS Server (есть и такой, оказывается: www.apple.com/ru/macos/server), либо через сторонние продукты, например:
Это все хорошо, когда админ сам знает, как настроить доступы и разбирается с неисправностями. А на практике, ты должен полдня гуглить, чтобы потом обьяснить админу, какие кнопки надо нажать, чтобы, например, docker desktop на винде заработал без админских прав и за непрозрачной проксей. В итоге вместотрешения ннпосредственной задачи, ты работаешь за админа. А админ потом за тебя — не работает. И так везде. А статья хорошая. В вакууме.
Да админ-то опытный, а вот руководство далеко и безопасники советской закалки. И специфика работы моей такая, что я не могу заранее сказать, что мне нужно, я ставлю эксперименты, пробую, создаю, удаляю. За каждым чихом админа звать неудобно. Если бы суперадмин знал почему утилита х в конкретно в нашей сети в линуксе не работает с моей машины — было бы круто. А так я должен это загуглить, провести пару проверок гипотез (для которых требуются права админа) и потом сработавшую гипотезу применить, несработавшие почистить. Админ стоит над плечом чисто для ввода пароля. В итоге человекочасы*2. А безопасность налицо — пароли всевозможных проксей в открытом виде в куче линукс-конфигов. Даешь интернет, б… ть!
1. Поиск конкретных мест где нужны права. Это хорошо если права нужны только на запуск, а если в процессе работы появляются такие моменты, то нужно заново траблшутить. И это еще хорошо если ПО прямо говорит «permission denied», а то бывает просто падает без конкретных ошибок.
2. Запуск разными средствами от имени админской УЗ это рабочий вариант, но только если идет локальная работа. Что делать при сетевом доступе, когда каждый пользователь состоит в десятках разных групп, а где-то прописан напрямую. Создавать 2 УЗ на каждого пользователя? Как то не очень…
3. Что делать с софтом, у которого права администратора прописаны в системных требованиях? А ТП сразу отклоняет все запросы если их софт работает без прав администратора. Каждую проблему тестировать с правами, а потом убирать назад?
Да на виртуалке её запустить типа Virtual PC. И всё.
А если ей требуется взаимодействие с другим ПО, ну или это программа ставится как дополнение/расширение функционала имеющегося ПО?
Так оно обычно и бывает, если это не основная программа, а вспомогательная утилита.
А если основная, то ей нужен доступ к сетевым принтерам, сетевым папкам и т.п. — еще раз настраивать полноценную рабочую станцию.
Еще есть вопрос про стоимость лицензии Windows, той, что запускается в виртуальной машине.
[Конспект админа] Что делать, если программа хочет прав администратора, а вы нет