Главная Security, Windows, Без рубрики, Новое Так ли страшен контроль учетных записей
  • Так ли страшен контроль учетных записей

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

    С какими правами работать?

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

    Назначение контроля учетных записей

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

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

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

    Администратор или пользователь?

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

    image001
    Увеличить рисунок

    Рисунок 1 – При установке Windows создается административная учетная запись

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

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

    image002

    Рисунок 2 – Запуск командной строки от имени администратора из контекстного меню

    Это обусловлено тем, что при включенном контроле учетных записей администратор и пользователь поставляются «в одном флаконе». У административной учетной записи есть все необходимые права, но когда UAC включен, абсолютно все задачи запускаются с правами обычного пользователя. И происходит это до тех пор, пока для продолжения работы не потребуются полные права администратора. Именно в этот момент и появляется запрос контроля учетных записей, который служит сигналом о том, что программе необходимы административные полномочия. Когда UAC включен, вся разница между работой администратором и обычным пользователем сводится к тому, что в первом случае для продолжения работы вам достаточно нажать кнопку «Да», а во втором – потребуется ввести пароль любого имеющегося в системе администратора.

    image003
    Увеличить рисунок

    Рисунок 3 – Командую строку от имени администратора запускают: администратор (слева) и обычный пользователь (справа)

    Мимо контроля учетных записей, выдающего предупреждения, не проскочит ни одна программа, требующая полных прав, а предупрежден – значит вооружен, в чем и состоит информационная задача уведомлений UAC. При повседневных же действиях нажать кнопку «Да», конечно, быстрее, чем вводить пароль каждый раз, поэтому постоянная работа с ограниченными правами менее комфортна и при этом не обладает значительными преимуществами с точки зрения безопасности.

    Администратор или встроенная учетная запись «Администратор»?

    image004 Регулярно читая форумы Windows Vista и Windows 7, я обратил внимание, что некоторые пользователи мотивируют отключение контроля учетных записей тем, что хотят быть полными хозяевами своей системы. Другими словами, им претит тот факт, что запись в корень системного диска или папку Windows сопряжена с дополнительными действиями, а запросы контроля учетных записей вызывают страшную аллергию. На одну полку с ними можно поставить поклонников популярной мифологии о всемогуществе встроенной учетной записи «Администратор», чье единственное отличие от остальных администраторов в том, что на нее по умолчанию не распространяется UAC. В реальности отключение контроля учетных записей в панели управления уравнивает всех администраторов

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

    Резюме

    Появление контроля учетных записей подтолкнуло разработчиков к созданию программ, рассчитанных на работу с ограниченными правами. Однако в домашних условиях мы самостоятельно выполняем административные задачи, и в Windows 7 все-таки удобнее работать с правами администратора. Отключение UAC или использование встроенной учетной записью «Администратор» с точки зрения прав эквивалентно работе в Windows XP и сопряжено с риском потери контроля над системой в случае заражения. На мой взгляд, лучшее соотношение «безопасность / комфорт» в Windows 7 достигается при работе администратором с включенным контролем учетных записей.

    Повышение прав с запросом UAC и без него

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

    Компоненты Windows 7

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

    image005

    Рисунок 4 – Запрос UAC не выводится, когда администратор переходит по ссылке со щитом в панели управления

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

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

    image006

    Рисунок 5 – Чтобы настроить недоступные параметры, придется нажать ссылку со щитом

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

    Современные приложения

    У Microsoft есть рекомендации не только для пользователей, но и для разработчиков программ. Применительно к UAC один из главных советов – это хранение настроек программы и предпочтений пользователя только в расположениях, где для записи не требуются права администратора. В таком случае они нужны только при установке программы, если производится запись в системные папки (например, Program Files) и регистрация компонентов в системе. Конечно, при этом выводится запрос контроля учетных записей. Но в дальнейшем все пользовательские данные и параметры программы хранятся в профиле, в папке %userprofile%\appdata. Там вы найдете папки с данными установленных у вас программ, которые не требуют прав администратора для работы.

    image007

    Рисунок 6 – Современные приложения хранят пользовательские данные только в вашем профиле

    Наличие трех папок объясняется так:

    • Roaming – в корпоративной среде данные из этой папки следуют за пользователем при использовании перемещаемых профилей;
    • Local – данные, объем которых слишком велик, чтобы перемещать их вместе с профилем;
    • LocalLow – данные, записанные процессами с низким уровнем целостности, т.е. возможности которых по внесению изменений в систему максимально ограничены.

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

    image008

    Рисунок 7 – Поскольку для установки приложения не требуются права администратора, сразу предлагается поместить его в профиль

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

    Старые приложения

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

    Виртуализация файлов и реестра

    Разработчики UAC сразу понимали, что старые приложения уже не научатся хранить данные в профиле, а будут пытаться записывать их в папки Program Files или Windows (хотя последнее было дурным тоном еще в ХР). Как я говорил выше, при включенном UAC даже у администратора приложения запускаются с обычными правами, что означает отсутствие разрешений на запись в системные расположения. Решение было придумано оригинальное – система делает вид, что программе разрешена запись, а на самом деле перенаправляет файлы в профиль, либо записывает параметры реестра в специальный раздел. В дальнейшем программа продолжает обращаться к этим данным, даже не подозревая об их реальном расположении. Так в Windows Vista появилась виртуализация папок и системного реестра, которую унаследовала и Windows 7.

    Несмотря на недетский возраст этой технологии, о ней слышали немногие. Это мы выяснили в конкурсе на знание Windows 7, который проходил в конце 2009 года на OSZone.net. Там был задан вопрос о кнопке «Файлы совместимости» в проводнике, и подавляющее большинство участников ответило, что такой кнопки в Windows 7 не существует. Между тем, именно с помощью этой кнопки вы можете увидеть папки, в которые программы пытались записать данные, не имея на то разрешения. Это может вам пригодиться, если вы захотите вручную сделать резервную копию настроек программы или данных, которые она сохранила.

    image009
    Увеличить рисунок

    Рисунок 8 – Кнопка “Файлы совместимости” ведет в виртуальное хранилище

    У меня эту кнопку проводник отображает уже в корне системного диска, а нажав ее, я вижу папки с названиями Windows и Program Files, а также какой-то архив. Обратите внимание на адресную строку проводника – я перешел в уже знакомую папку AppData, а точнее – в виртуальное хранилище (Virtual Store). Названия программ в папке Program Files мне знакомы – это и есть старые приложения, работа которых не нарушилась благодаря виртуализации файлов.

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

    image010
    Увеличить рисунок

    Рисунок 9 – Чтобы сохранять или изменять файлы в системных папках, «Блокнот» нужно запускать от имени администратора

    Собственные программы Microsoft, конечно, спроектированы для работы обычным пользователем, поэтому они знают, что делать при отсутствии прав. Теперь возьмите, скажем, текстовый редактор Akelpad, в котором не предусмотрено такое сообщение, и попробуйте сделать то же самое. Вместо корня диска файл будет сохранен в виртуальном хранилище, и в дальнейшем «обманутый» Akelpad будет видеть его именно в корне диска (а блокнот – нет, ведь он туда ничего не записывал).

    image011
    Увеличить рисунок

    Рисунок 10 – Akelpad открывает “свой” файл из корня системного диска (слева), хотя он расположен в виртуальном хранилище (справа)

    Теперь понятно,  откуда взялся Archive.zip в корне виртуального хранилища. Я создал его в корне системного диска архиватором 7-zip, причем неважно, из контекстного меню, либо просто запустив программу с обычными правами. Система позволила выполнить операцию, но сохранила файлы в профиль.

    Виртуализация реестра происходит аналогично. Например, при попытке записи в HKEY_LOCAL_MACHINE\Software\ProgramName происходит перенаправление в раздел HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software\ ProgramName, где User_SID обозначает идентификатор пользователя, от чьего имени выполняется действие. Кроме того, перенаправляются все попытки записи в разделы, куда администратор имеет доступ, а обычный пользователь – нет.

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

    При чем тут UAC?

    С помощью виртуализации файлов и реестра обеспечивается совместимость со старыми приложениями, и в первую очередь она нацелена на работу с правами обычного пользователя. Если UAC отключен, администратор не заметит разницы, поскольку права на запись в Program Files у него есть. А вот обычных пользователей старая программа может огорчить очень быстро, ведь прав на запись в системные расположения нет (хоть с UAC, хоть без него), а перенаправить данные уже некому. Программа «ломается», т.е. скорее всего, выводит сообщение из разряда «отказано в доступе».

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

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

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

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

    Установка в профиль или получение полных прав на папку программы

    Виртуализация файлов и реестра помогает в тех случаях, когда приложение запускается с обычными правами (т.е. без запроса UAC), но в процессе работы нуждается в правах администратора и при этом не умеет их запрашивать. Существуют программы, которые уже при запуске проверяют наличие прав на запись в собственную папку. Когда они установлены в Program Files, права на запись отсутствуют, поэтому при запуске появляется запрос UAC. В этом случае можно попробовать заставить программу идти в ногу со временем, установив ее в профиль. Альтернативный вариант – это получение полных прав на папку программы, что может оказаться быстрее переустановки в профиль.

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

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

    Системные утилиты

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

    На примере утилит Sysinternals Марка Руссиновича это легко продемонстрировать. Process Explorer отображает массу информации о системных процессах, но для ее сбора, очевидно, нужны полные права, поэтому запрос выводится сразу. Утилита Autoruns, которая знает все об автозагрузке системы, запускается с обычными правами, а запрос выводит только в случае, когда вы изменяете параметры, требующие административных полномочий.

    image012

    Рисунок 11 – Утилите Autoruns нужны полные права для внесения изменений в системный раздел реестра

    Когда с помощью Autoruns вы изменяете пользовательские параметры (раздел HKCU), запрос не выводится, а при настройке системных параметров на самом деле получается два запроса. Один выводит программа (рис. 11), после чего требуется ее перезапуск, что ведет уже к появлению запроса UAC (аналогично ведут себя сторонние файловые менеджеры при попытке копирования файлов в системные папки). Это неудобно (лучше уж однажды при запуске), но вполне решаемо, как мы увидим это чуть позже.

    Командная строка и скрипты

    Со встроенными программами Windows 7 тоже получается по-разному. При открытии редактора реестра запрос появится сразу, даже если вы хотите просто проверить наличие какого-нибудь параметра. Командная строка же запускается с обычными правами, а при попытке выполнить в ней команду, требующую полных прав администратора, выводится соответствующее сообщение (рис. 12 слева).

    image013
    Увеличить рисунок

    Рисунок 12 – Из заголовка командой строки понятно, с какими правами она запущена (слева с обычными правами, справа – от имени администратора)

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

    image014
    Увеличить рисунок

    Рисунок 13 – С помощью утилиты elevate для команды запрашивается повышение прав

    Запрос контроля учетных записей при этом все равно появится, но время все-таки экономится, т.к. не надо запускать новую командную строку от имени администратора и повторно вводить команду. Достаточно нажать стрелку вверх (повтор команды), затем клавишу Home (переход к началу строки) и ввести elevate /k. Конечно, это полумера, но если вы часто работаете с командной строкой, эту утилиту стоит иметь в арсенале.

    И раз уж речь зашла о командной строке, нельзя обойти вниманием скрипты, которые также часто приходится запускать с повышенными правами. В контекстном меню Windows 7 возможность запуска от имени администратора предусмотрена только для скриптов командного интерпретатора, т.е. для bat и cmd. Однако с помощью набора утилит Elevation PowerToys можно расширить список, добавив туда WSH и PowerShell, а также возможность запуска скриптов от имени другого пользователя, включая систему.

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

    Запуск программ без запроса UAC

    Достаточно поработать с контролем учетных записей пару недель, чтобы определить список приложений, при запуске которых появляется диалоговое окно UAC. Для каждого из них можно создать ярлык, который будет запускать программу без всякого запроса. Можно также создать ярлык для командной строки и/или диалогового окна «Выполнить», откуда любые задачи уже будут выполняться с полными правами администратора.

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

    Заключение

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

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

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

    Действие Средство для повышения удобства работы
    Настройка в панели управления Не требуется
    Настройка системными утилитами Ярлык для запуска с полными правами
    Запуск и работа старых приложений
    • Включение UAC (виртуализация файлов и реестра)
    • Установка в профиль или получение полных прав на папку программы
    • Ярлык для запуска с полными правами
    Работа в командной строке
    • Утилита elevate
    • Ярлык для запуска с полными правами
    Запуск скриптов
    • Elevation PowerToys
    • Ярлык для запуска с полными правами
    Подбор и тестирование приложений Виртуальная машина

    Ссылки

    Все ссылки этой статьи:

    Вадим Стеркин

Комментарии

  1. “На мой взгляд, лучшее соотношение «безопасность / комфорт» в Windows 7 достигается при работе администратором с включенным контролем учетных записей.”

    На взгляд эксперта – да, но если посмотреть глазами пользователя, то ему все равно из-за чего появится UAC. Даже если это будет вирус, который попытался запуститься, а UAC его перехватил и показывает окошко с выбором “ДА” “НЕТ”, то пользователь в 99% случаев выберет “ДА”, так что смысл UAC пропадает в корне. Вывод прост: Нет мозга – UAC не нужен, так как все равно не спасет и будет “задалбывать”.

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

  2. “Представьте, что вредоносная программа скрытно пытается осуществить запись в системную папку или раздел реестра.”

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

  3. Такие вирусы крайне не эффективны и были они уже давным давно и под XP, да и в общем-то надо ориентироваться на задачу. 90% трояноввирусов рассчитаны на хищение данных, создание прокси сервера, DDoS и т.д., а для этого лучше всего “быть” руткитом, но тут все упирается в права. Хотя какая разница? Куча пользователей без зазрения совести запускают кряки для софта даже не проверяя его на вирустотале и UAC тут не спасет, пользователь все равно нажмет “ДА” ибо ОН этого хочет.

    МС конечно большое спасибо за UAC, мне как администратору, который сидит постоянно под пользователем, очень нравится это “изобретение”.

  4. никогда такая защита не была для меня в тягость
    помню лет 6/7 тому назад я был системным администратором в конторе
    и был едиственным кто работал как простой “юзер” а остальные пользователи поголовно были “администраторами”

  5. блинн где мой пост?!!!!
    больше не буду постить!!!!

  6. >блинн где мой пост?!!!!
    В спам попадал 🙂

  7. @as
    Мозг нужен, да. Ну так он нужен вне зависимости от использования UAC и не только в сфере ИТ. О кнопке “Да” я говорил в самой первой статье http://itband.ru/2010/06/security-in-windows-7#_Toc263808423 и в последующих статьях не раз ссылался.

    И даже без кнопки виртуализация работает, т.е. пишет данные в профиль, а не в системные папки – зайдите в LocalLow и посмотрите.

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

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

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

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

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

  9. @shs
    Я не имею отношения к разработке упомянутой инф. системы, но я хорошо представляю, как она развертывается. Одним из способов является отправка пользователям письма со ссылкой на программу (на сервере разработчика или своем), после чего они устанавливают одним щелчком мыши. Если права ограничены, установка идет в профиль, а у администратора – в Program Files. Если вы хотите развернуть ее всем пользователям централизованными средствами, по умолчанию ставится в Program Files. Очевидно, что для установки не требуется быть администратором, так зачем это навязывать?

    Что же касается запуска программ из профиля, то у пользователя и так есть возможность установить туда программу. Довольно странно будет выглядеть требование к разработчикам ограничивать эту возможность, блокируя любые расположения установки кроме Program Files. Для контроля в этом случае есть политики и AppLocker.

  10. >Очевидно, что для установки не требуется быть администратором, так зачем это навязывать?
    Очевидно для того, что разумный администратор ограничит возможность запуска любых программ (при помощи AppLockera или SRP) из тех папок, в которые пользователь имеет право на запись. Сделает он это с очевидной же целью – предотвращение заражения системы и недопущения пользователем запуска любых программ, кроме предустановленных администратором. Пример того, для чего это нужно делать, можно посмотреть здесь: http://social.technet.microsoft.com/Forums/ru-RU/windowsserverru/thread/5b020246-320a-449a-a318-07168ff39f4b

    > Довольно странно будет выглядеть требование к разработчикам ограничивать эту возможность, блокируя любые расположения установки кроме Program Files

    Требования к разработчикам должны быть несколько иными (где я писал о том, что ставить нужно только в “Program files”?): для установки программы необходимы права администратора (причины я изложил выше).

  11. @Вадим Стеркин
    “Что же касается запуска программ из профиля, то у пользователя и так есть возможность установить туда программу.”

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

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

  13. >Это если есть хеш программы в политиках ограниченного запуска программ, а по моим наблюдениям пытаться отследить все действия сетапа — достаточно трудно ибо он (сетап) создает кучу временных *ехе, которые через раз еще умудряются иметь разный хеш. Так что если и делать установку софта, то через ГПО.

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

  14. @shs
    А вот и нет. Куча программ пишет свои темповые файлы в профиль пользователя и именно в темпе профиля и возникают чудо ехе`шники с разными именами и размером. Согласитесь что Вы не будете давать разрешение по пути в ту папку куда у пользователя есть права на запись 😉

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

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

  16. @Вадим Стеркин

    Согласен с Вами, но все таки пример очень редкий =( Как правило софт ТАК криво написан, что становится дико страшно. Мало того что нет ключей автоматической установки, так еще хочет права на запись в program files, в HKLM, а конфиги свои держит в windows =( Яркий пример тому – folio.

  17. @as
    >А вот и нет. Куча программ пишет свои темповые файлы в профиль пользователя и именно в темпе профиля и возникают чудо ехе`шники с разными именами и размером. Согласитесь что Вы не будете давать разрешение по пути в ту папку куда у пользователя есть права на запись.

    Не буду и не даю. В моей организации SRP внедрена и успешно работает около 2х лет. Никакой кучи программ (относящихся к бизнес-приложениям), которые бы генерили “чудо ехе`шники”, мне наблюдать не приходилось. Назовите (для примера) хотя бы пару программ.

  18. @ Вадим Стеркин
    >Но я не согласен с тем, что для установки программ обязательно нужно требовать права администратора. Если приложение устанавливается и функционирует без них, пусть работает — в этом случае локальная система будет стабильнее и устойчивее, т.к. вообще не затрагиваются системные файлы и параметры.

    Не согласен. Я никак не могу донести до вас простую мысль: права админа нужны во время установки только для того, чтобы программа была установлена в папки, не доступные на запись пользователям, а вовсе не для того, чтобы менять мифические системные настройки.
    Установка программы без прав админа (читай в папку, в которой у пользователя имеется права на запись) не повышает стабильность системы, а наоборот – создает уязвимость. Т.к. вредоносный код, запущенный в контексте пользователя, без труда сможет внедриться в исполняемые файлы такой программы.

  19. >Мало того что нет ключей автоматической установки, так еще хочет права на запись в program files, в HKLM, а конфиги свои держит в windows =( Яркий пример тому — folio.

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

  20. @shs
    “Т.к. вредоносный код, запущенный в контексте пользователя, без труда сможет внедриться в исполняемые файлы такой программы.”

    1. Тут еще надо как-то запустить в обод SRP вирус, чтобы он смог модифицировать другой *.ехе.
    2. Хотя даже если ехе по каким-то причинам изменится (пусть будет авто обновление), то его отловит SRP (если до этого ехе был разрешен по хешу и лежал где-то у пользователя в папке).

    Насчет чудо софта сейчас не подскажу точное название (да-да можно считать за слив), но в терминалках есть чудо pathcmd файлик или как-то так 😉 Хотя там есть свои фиксы с костылями, но все равно эпик фейл.

  21. @as
    > 1. Тут еще надо как-то запустить в обод SRP вирус, чтобы он смог модифицировать другой *.ехе.

    Если есть разрешение на запуск программ (реализованное на основании правила путей), то из такой папки может стартовать все, что угодно – хоть бизнес-приложение, хоть вирус. Настраивать же разрешения на основании хэша – не гуманно по отношению к администратору:
    1)растет объем работы,
    2)человеческий фактор (повышается риск ошибочных настроек)
    3)после обновления софта, требуется обновление политик

    И не гуманно по отношению к пользователю: правила хэша работают медленные, чем правила путей, а, значит, много правил хэша – большие тормоза.

  22. @shs
    Я понял вашу простую мысль уже давно, просто я не разделяю ваш подход. Работа с административными правами должна сводиться к мимимуму, и приложения, не требующие их для работы и установки, укладываются в эту концепцию.

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

  23. @Вадим Стеркин
    >Я понял вашу простую мысль уже давно/
    Ok.

    >Работа с административными правами должна сводиться к минимуму, и приложения, не требующие их для работы и установки, укладываются в эту концепцию.

    Вы опять пытаетесь смешать в одну кучу установку программ и работу пользователя с программой. Это 2 разных задачи. Первая задача (установка софта, равно, как и внесение изменений настроек в систему) – задача для администрирования, вторая (использование прикладного софта) – задача для пользования. Сводить к минимуму работу с повышенными привилегиями необходимо для пользователя, выполняющего работу с прикладным софтом, а, вовсе, не работу администратора по управлению системой.

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

    Опять с вами не соглашусь.
    1) Что такое zero-day уязвимость, думаю никому объяснять не нужно. Запуск кода эксплуатирующего подобную (или непропатченную) уязвимость в контесте непривилегированного пользователя может привести к тому, что зловред повысит свои привилегии до уровня администратора.
    2) Даже не обладая административными привилегиями, зловред может выполнять свое черное дело: превратить вашу машину в спамбота, показывать вам порнобанеры, etc.

  24. @shs
    “И не гуманно по отношению к пользователю: правила хэша работают медленные, чем правила путей, а, значит, много правил хэша — большие тормоза.”

    Речь идет про загрузку GPO во время включения компьютера? Или что-то еще?

  25. >Речь идет про загрузку GPO во время включения компьютера? Или что-то еще?

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

  26. @shs
    Мне кажется, проблема в том, что вы оцениваете статью, написанную для домашних пользователей, с позиции администратора в организации. Будучи администратором, вы можете полностью контролировать пользовательскую среду, и если вам не нравится, что приложение может устанавливаться в профиль, разверните его самостоятельно. Но существуют бизнес-сценарии, в которых такая установка может понадобиться, вот и все.

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

  27. @Вадим Стеркин
    >Мне кажется, проблема в том, что вы оцениваете статью, написанную для домашних пользователей, с позиции администратора в организации.

    Именно так и расцениваю. Возможно, что этого действительно не стоило делать.

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

    Связь есть. Я о ней писал выше (вы даже сказали, что поняли мою простую мысль). Повторю еще раз: установка программы в профиль (читай – в папку, доступную для записи в контексте непривилегированного пользователя) создает дыру в безопасности ОС и среду для распространения “зловредов”. Если пользователей, выполняет работу с ограниченными привилегиями, то “зловред”, запущенный в контексте такого пользователя сможет заразить вашу программу, установленную в профиль пользователя, но не сможет заразить программу, установленную, например в %programfiles%, т.к. права на запись в эту папку имеет только привилегированный пользователь. Посему, считаю ваш совет – устанавливать программы в профиль – ошибочным (если не сказать вредным).

    >Подавляющее большинство домашних пользователей все равно работают с правами администратора, о чем я и пишу в статье.

    Да, с одной стороны вы даете правильный совет – не работайте с правами админа, не отключайте UAC и т.п. С другой стороны, вы даете совет – ставить программы в профиль пользователя, что уменьшает профит от отказа работы с повышенными привилегиями.

  28. Господа, хорошая дискуссия!
    Мне по нраву позиция shs. Софт должны администрировать (т.е. установка, настройка и т.п.) админы! Пользователи должны его пользовать – очевидно из названий 🙂
    Однако пишу я сюда по другому поводу.
    В моей маленькой организации идёт переход на Win7, таким макаром, что все новые ПК несут на себе Win7 и она там остаётся жить.
    UAC функционирует с настройками по-умолчанию для доменного ПК. Однако вот впервые за полгода столкнулся с проблемой UAC. Есть приложения для сетевого сканирования с МФУ Xerox. Так вот если отключить UAC – оно работает под пользователем без проблем, а если включить – то требует повышения прав.
    Версии этого софта с поддержкой UAC для Win7 нет, и как скоро будет – не понятно, ибо драйвера для Win7 (а также в комплекте для всех предыдущих)есть, но эта софтина определяя что она устанавливается на Win7 автоматом (в комплекте с остальным ПО для МФУ) ставиться не хочет (её нет в выборе компонентов). А это может означать, что Xerox так это дело и оставит. Софт я ставил вручную.
    UAC отключать не охота. Вообщем как быть?

  29. “Есть приложения для сетевого сканирования с МФУ Xerox. Так вот если отключить UAC — оно работает под пользователем без проблем, а если включить — то требует повышения прав.”
    В ГПО отключите “Контроль учетных записей: обнаружение установки приложений и запрос на повышение прав”. Поможет скорее всего так как UAC перестанет пытаться автоматом повысить софт в правах и будет запускать под юзером.

  30. @shs
    Установка программы в профиль не создает никаких дыр в безопасности системы, не выдумывайте. Пользователь волен сам выбирать папку для установки – это стандартное поведение практически всех установщиков программ. Безопасность обеспечивается не установкой программ в Program Files, а наличием защитных средств – брандмауэр, антивирус, антишшион и т.д. Равно как и пример с заражением программы, установленной в профиль, я считаю притянутым за уши. Если зловред проник, заразил программу в профиле… ну и что с того? Он точно так же может повредить кучу других файлов, например, пользовательские данные программы, установленной в Program Files. Просто переустановите программу после лечения в конце концов.

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

    И, пожалуйста, не приписывайте мне совет не работать с правами админа. Я как раз говорил о том, что в Windows 7 нет особого выигрыша в безопасности при работе с ограниченными правами, если включен UAC. CTRL+F -> резюме

    @mikas
    Попробуйте в HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsLayers
    создать параметр: полный_путь_к_программе.exe = RUNASINVOKER

    Либо примените исправление RunAsInvoker в ACT http://bit.ly/9W3lU9

  31. @Вадим Стеркин
    Спасибо помогло. Я уже начал копать в сторону ACT… но проще спросить, чем ставить ACT и вычислять ветки реестра. Еще раз спасибо.
    @as
    Ваш совет не помог.

    @shs & Вадим Стеркин
    Если на клиентах работает SRP, то пользователь при любом желании не сможет установить софт в свой профиль потому, что инсталятор не сможет запуститься.

  32. Спор двух равноценных специалистов с разной точкой зрения на целесообразность КУЗП.

  33. >Если зловред проник, заразил программу в профиле… ну и что с того?
    Зловред получает возможность действовать и распространяться по сети. Вам этого мало?

    >Безопасность обеспечивается не установкой программ в Program Files, а наличием защитных средств — брандмауэр, антивирус, антишшион и т.д.

    Безопасность обеспечивается комплексом мер, в том числе разграничением полномочий в системе (одна из мер по разграничению полномочий – это ограничение доступа пользователя к исполняемым файлам, нет возможности записи – нет возможности заражения). Если система позволяет, путем грамотного распределения полномочий, защитить себя от поражения вирусами, то я не понимаю, почему этого не надо делать? Таковая защита ничего не стоит (не надо ничего докупать), очень эффективна, т.к. блокирует любые попытки несанкционированных действий со стороны зловредов (как известных, так и неизвестных). Вы же призываете игнорировать эту возможность, что, на мой взгляд, – ошибочно (мягко говоря). Антивирус/антишпион, файервол – это конечно хорошо, но это только часть всего комплекса необходимых мер (это все равно, что полагаться в обеспечении сохранности своего жилища на пограничную службу и патрульных милиционеров, вместо того, чтобы, уходя из дома, банально, закрывать дверь на замок).

    >Кроме того, мой совет устанавливать программы в профиль, вокруг которого крутится почти вся ваша аргументация, вы явно вырвали из контекста. Я его давал применительно к очень узкому кругу программ — тех, которые при запуске проверяют наличие прав на запись в собственную папку.
    Я бы согласился с таким мнением, но (цитирую): «Некоторые разработчики идут еще дальше, создавая приложения, которые можно устанавливать без прав администратора. Например, я сейчас имею отношение к выпуску огромной информационной системы, в которой предусмотрена работа с ограниченными правами, т.е. у обычного пользователя программный пакет целиком устанавливается в профиль, после чего является полностью работоспособным». IMHO, в этой фразе неявно прослеживается экспертный совет – устанавливайте программы в профиль, так поступают профессионалы.

    >И, пожалуйста, не приписывайте мне совет не работать с правами админа. Я как раз говорил о том, что в Windows 7 нет особого выигрыша в безопасности при работе с ограниченными правами, если включен UAC. CTRL+F -> резюме

    Извините, что приписал вам то, что вы не говорили. Но, IMHO, выигрыш в безопасности при работе с правами пользователя – есть. Безусловно, введение UAC – понижает риск подхватить заразу и его можно рекомендовать для бездумных пользователей, которые (не будь его) работали бы с правами администратора, но не более того. Если зловред запросит у такого пользователя повышения полномочий, то с вероятностью близкой к 100% он его получит, потому что бездумному пользователю, проще щелкнуть OK, не чита сообщения и не задумываясь о последствиях, нежели ввести пароль администратора (что его (пользователя), возможно, остановит и заставит задуматься о причинах появления такого запроса.). В корпоративной же среде пользователь не должен иметь административных прав никогда, за исключением тех редких случаев, когда это вызвано производственной необходимостью.
    Кроме того, в «Резюме» читаем: «Появление контроля учетных записей подтолкнуло разработчиков к созданию программ, рассчитанных на работу с ограниченными правами» Тезис очень странный. IMHO разработчикам программ и до появления UAC ничто не мешало писать программы не требующих для своей работы повышенных привилегий. А появление UAC никак не могло на это повлиять. IMHO, UAC появился после того, как MS осознала, что развращенные ее же прошлым подходом к безопасности (в системах win9x нет разграничений полномочий, а системах на платформе Windows NT пользователь после установки ОС получает ничем неограниченные права админа) не хотят следовать рекомендациям MS по разграничению полномочий и работать под учетной записью с правами ограниченного пользователя. Поэтому и появился UAC, который является компромиссным решением: «черт с вами, будьте админами, но мы хотя бы постараемся сделать так, чтоб вы не отстрелили себе ноги». Да, работа с правами админа под UAC – это лучше, чем ничего, но хуже, чем то, как это должно было бы быть.

  34. @shs
    Гм… я уже говорил, что статья написана для *домашних* пользователей, а вся ваша аргументация построена с позиции корпоративной среды. У вас пользователи работают с ограниченными правами, а дома – с административными, и я смотрю на вещи реально, посему не рассказываю им про укрепление безопасности за счет работы с ограниченными правами. Вы применяете SRP и сами решаете, можно ставить ПО в профиль или нет, руководствуясь производственной необходимостью, а дома они ставят ПО куда хотят, и вас не спрашивают.

    Установка в профиль у вас прямо болевая точка какая-то 🙂 Ну решила некая компания, что нужно включить в свое ПО возможность установки в профиль – это смертный грех? Кому надо, использует это возможность, а кому не надо – давно запретил. Поймите, пользователи не могут просто пойти и скачать инф. систему, о которой идет речь… И нет здесь никакого “экспертного совета” устанавливать ПО в профиль, я уже говорил выше об этом.

    Что же касается моего тезиса о назначении UAC, показавшегося вам странным, то ваши выводы я тоже могу обозначить таковыми. MSFT переделала ОС, чтобы можно было работать с ограниченными правами (набивший оскомину пример – смена часового пояса). Но этого недостаточно, нужно двигать разработчиков, которые с MSFT в одной упряжке – и те и другие хотят заработать. Но без ПО никому ОС не нужна, равно как и не нужно ПО, которое не работает в ОС с ограниченными правами. Так что UAC и есть сигнал разработчикам, потому что давать его домашним пользователям бесполезно – они UAC отключат и все дела.

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