понедельник, 2 июня 2008 г.

UAC: Elevation: Как сделать жизнь проще

Еще на Платформе, кажется, да и на Запуске тоже, мне был задан неоднократно вопрос про то, как сделать работу с командной строкой более удобной и при этом не отключать UAC. Известно же, что для того, чтобы выполнить административное действие в командной строке нужно предварительно запустить эту "строку" с повышенными привилегиями. Иначе будет как всегда:

image Так вот, в июньском номере журнала TechNet Magazine была статья Michael Murgolo, которая сводит воедино несколько инструментов, которые облегчат работу с повышением привилегий в Vista/Windows 2008.

Надеюсь, это кому-то поможет.

10 комментариев:

Анонимный комментирует...

угу, собственно, этот скрипт я и имел ввиду, когда говорил о том, как можно обойти «silently deny». Достаточно запустить этот скрипт через RunAs из-под администратора. Таким образом, сначала меняется учётная запись на административную (а ей уже разрешено повышение полномочий), а затем уже выдаётся запрос на это повышение =)

ЗЫ. Про твой вопрос насчёт UAC и виртуализации я помню. Надо перечитать Руссиновича, а за выходные никак руки не дошли. Сегодня напишу чего-нибудь =)

Alexander Trofimov комментирует...

Я уже понял, но по прежнему считаю, что лучшей защитой является отсутствие у пользователя даже теоретической возможности обратиться к чему-то с повышенными привилегиями =)
З.Ы. Введение проверки на основе графического кода сильно раздражает? может убрать?

Анонимный комментирует...

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

моя идея с обходом «silently deny» (которую фактически «узаконила» эта новая статья) является ущербной — хотя бы потому, что это именно обход запрета. Это хорошо как эксперимент, но его ни в коем случае не стоит воспринимать как предлагаемое решение. Наоборот, это иллюстрация того, почему одного только «Silently Deny» недостаточно — а требуется комплексный запрет повышения полномочий. То есть необходимо зарубить всё — и UAC, и RunAs, и Sysinternals ShallRunAs, и все эти мелкие приблуды.

а если бы капча напрягала — я бы давно зарегистрировался =). Это ерунда, вот некоторые другие блогодвижки вообще все мои каменты считают спамом и сжирают без остатка.

Alexander Trofimov комментирует...

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

Анонимный комментирует...

ну круто. А если у него нету пароля — зачем ему приглашение? Только смущать будет. Это для нас понятно, что оно значит и чего хочет. А кто-нибудь начнёт пробовать все известные ему пароли — от своей доменной учётной записи, от личной веб-почты, от компьютера племянницы… Зачем это надо? Лушчая практика — не перегружать пользователя лишней информацей и не вводить во искушение заниматься хакерством. А то начнёт ещё по форумам луркать — и кто-нибудь добрый быстренько подскажет, как сбросить пароль локального администратора =)).

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

Alexander Trofimov комментирует...

Тьпху, блин. нет пароля + подавлено сообщение о повышении прав. Попробуй - поймешь о чем я. =)
А пользователи, которые в корпоративной среде сбрасывают какие-то пароли очень быстро изнашиваются - менять их приходится =)

Анонимный комментирует...

В таком случае, я не очень понимаю твою логику. Да, мы предполагаем и надеемся, что пользователь не станет ничего ломать и пользоваться runas. Но это не значит, что мы должны на это полагаться. Точно так же, как в Windows существует множество настроек, которые по умолчанию уже установлены безопасно. Но это не значит, что мы должны полагаться на это. Лучшей практикой безопасности является «усиление» этих настроек — то есть принудительное задание их через политики. Даже не смотря на то, что настройки в политиках повторяют установки по умолчанию. Это делается с очевидной целью — не допустить случайной или намеренной смены установок из этого безопасного состояния по умолчанию. Совершенно аналогично, мы знаем, что с помощью runas существует *возможность* повышать привелегии, но мы исключаем *необходимость* такой операции для пользователей. С моей точки зрения, единственным логичным следствием из этого является сделать повышение привелегий не только излишним, но ещё и невозможным.

Alexander Trofimov комментирует...

Все так. Только есть другой подход. Ты предлагаешь закрутить все гайки, что отнюдь не всегда возможно. А есть второй подход: запретить некоторые вещи организационно и следить за исполнением нормативов с помощью других утилит. NAP, аудит, You name it.
Дело в том, что если пользователь имеет физический доступ к компьютеру, то задача о "залочивании всего" не имеет решения в только технической плоскости. Мало того, 70-80% этой проблемы рано или поздно переходит в нормотворческую и организационную плоскость =)

Анонимный комментирует...

Что-то блоггер сегодня тормозит =)

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

я также не утверждаю, что применять «зверские» меры возможно и необходимо всегда и везде. Как недавно писал господин Каганов — если я полярник и живу один на льдине со своим ноутбуком, то для меня и пароль в шесть символов будет чересчур. С другой стороны, если я сотрудник банка, и мой компьютер подключён к сети с информацией о тысячах клиентов — даже 18-символьного пароля, наверное, не хватит. Ведь для чего-то придуманы смарт-карты и биометрия.

но говоря о любой теме, всегда надо ставить рамки — потому что объять необъятное невозможно. Так, обсуждая UAC, я считаю, что и аппаратные средства, и огранизационные меры находятся за пределами темы. Но вот полностью раскрыть тему настройки компонентов ОС вполне реально. И если в одной крайности здесь лежит полярник с его простым паролем, то другой крайностью как раз и будет исповедуемый мною подход «закручивания гаек». И понятно, что между этими крайностями существует много промежуточных стадий, из которых надо находить подходящее сочетание сложности и эффективности для каждого конкретного случая.

Alexander Trofimov комментирует...

Опечатывать компы - сильно. Подойдет, наверное, где-то. Для упомянутого не к ночи SSLF =)
Но в любом случае - если пользователь имеет "доступ к телу", а ты нет - нужны оргмеры и аудит. Аудит осуществляется техническими средствами. Оргмеры - организационными. И, между прочим, технические средства служат лишь для облегчения и/или обеспечения нормативов. Неважно, существуют эти нормативы в виде документации и постановлений, или они лишь в образе фольклора корпоративного витают.
ИМХО, ессно.
А наворачивать security можно до бесконечности - лишь бы было коммерчески выгодно. =)