Некоторое время я описал баг в AppLocker'е, который заключается в некорректной обработке правил пути, если путь содержит неанглийские буквы (подробнее см. Очередной баг в AppLocker). Как я уже говорил, я открыл кейс в саппорте и обещал отписаться, если будут какие-то новости. И я выполняю своё обещание публикацией официального ответа Microsoft:

We've investigated the issue and it appears to be a problem in the implementation of case-insensitive path comparison for characters outside the ASCII range. Fortunately it seems there is a workaround for the time being. If, in Local Security Policy, one specifies paths in all-uppercase characters, including uppercasing any non-ASCII characters as appropriate, then the rule will match properly. Concretely, for your example 'Mapīte', putting that string with lowercase ī in a rule's path in Local Security Policy will not work; however putting the string 'MAPĪTE' with uppercase Ī does seem to work.

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

Уже прошёл почти год моего опыта использования AppLocker'а в домашних, тестовых и производстенных условиях и я хотел бы поделиться своими впечатлениями об этом со стороны перспективы использования этой технологии. К сожалению (а может и к счастью?) эту технологию постиг эпик фейл. И это даже при весьма удачной технической реализацией, которая более удобная в управлении, чем SRP и более надёжная. Хотя и с известными багами.

Microsoft создала потребительскую технологию, актуальную для всех секторов рынка, но давать её решила только VIP'ам, а остальным только пускать слюнки. Я говорю о том, что AppLocker доступен только в редакциях Ultimate и Enterprise десктопной Windows 7. Этим самым из целевой аудитории отваливается домашний сектор. В реальной жизни кроме пиратов мало кто приобретает компьютер с Windows 7 Ultimate. Чаще это ноутбуки с редакциями Home Basic/Premium, то же касается и обычных десктопов. Так же отваливается как минимум весь сектор Small Business и Medium тоже. SMB и средний бизнес тоже не будет приобретать Windows 7 Enterprise, а скорее будет покупать Professional, поскольку у Enterprise против Professional реальных преимуществ для этих секторов почти нет. А SMB — это основной рынок любой страны и по большому счёту он делает погоду на рынке. Да и крупные компании тоже особо тратиться на Enterprise не будут (хотя, Software Assurance им покрывает эти расходы). Иными словами, целевая аудитория этой технологии — средний (в меньшей степени) и крупный бизнес. Это маркетоЕдная составляющая проблемы.

Другая проблема кроется в технической составляющей. При всех достоинствах, AppLocker имеет определённые недостатки, которые заключаются в ограниченном применении правил издателей (подробнее см.тут: Встречаем – AppLocker!). Уж очень неоднозначно описываются правила издателей (а кто-нибудь пробовал строгие правила издатедей? Нет, а попробуйте и узнаете что это такое :-)), из-за чего они могут обхватывать нежелательные сертификаты доверенного поставщика. И с этим бороться сложно. Хотя, кому как. Из-за этого более целесообразным является использование правила хеша, что в свою очередь доставляет головняка при обновлении исполняемых файлов, для которых создано правило хеша. Их каждый раз придётся пересчитывать и обновлять сами правила. Это не смертельно, но уже не так весело, как в вайтпеперах и уютненьких бложеках MVP-маркетоидов.

Но наиболее глобальная проблема даже не в недостатках правил издателей или бага в правилах пути. Наиболее глобальная проблема кроется в интеграции AppLocker'а в существующую среду и крупный бизнес здесь страдает от этого сильнее, чем смалл бизнес. Это связано с тем, что в крупном бизнесе практически никогда не бывает сетей с установленной единственной версией ОС. Там обязательно присустствует парк ОС из разных поколений (начиная от Windows 2000/XP до Windows 7). AppLocker покрывает только малую часть из всего парка (только Windows 7 Enterprise). Для остальных приходится же использовать что-то другое. Обычно это Software Restriction Policies. И администраторам придётся создавать 2 набора политик: отдельно SRP для XP/Vista и отдельно AppLocker для Windows 7. То же самое относится и к редактированию политик. Если обновился какой-то файл, придётся обновлять политику SRP и AppLocker соответственно. Администраторам будет проще поддерживать одну политику, вместо двух. Плюс, правила сертификатов в SRP могут вносить негативный эффект в правила AppLocker'а. Хоть и заявляется, что если AppLocker включен, SRP будет игнорироваться системой, но запреты по правилам сертификатам будут перекрывать соответствующие разрешения в AppLocker'е. Это вызовет в свою очередь проблему планирования правил, чтобы грамотно создать правило в SRP и AppLocker'е и чтобы не наткнуться на подводный камень.

Вывод: так какое же место в этой жизни уготовано для AppLocker? Я считаю, что это только терминальные сервера или фермы терминальных серверов, где AppLocker показывает явное преимущество. А так же тот небольшой кусочек домашнего сектора, где возможно использование AppLocker'а. В остальных случаях практического использования, AppLocker является нецелесообразным и неэффективным. Возможно в следующем поколении Windows (или через поколение) что-то изменится, но сейчас дела обстоят примерно таким образом.

Но учитывая, что процент использования SRP по отношению к общему количеству инсталляций Windows XP/Vista/7/Server 2003/Server 2008/Server2008 R2 (видали, какой список ОС поддерживает SRP? :-)) очень ничтожный, то процент использования AppLocker'а — вообще круглый ноль и можно сказать, что МС просто выкинул деньги на ветер, вложив их в разработку AppLocker'а.

Update 23.08.2010: добавлен воркэраунд для обхода проблемы.

Оговорюсь сразу, баг был обнаружен не мною, а кем-то с технетов. Но тем не менее я заинтересовался им. Баг состоит в том, что если в правиле пути сам путь содержит буквы неанглийского алфавита, правило просто напросто не применяется! И некоторые вводные данные:

Подверженные ОС:

• Windows 7 Ultimate/Enterprise (x86/x64)
• Windows Server 2008 R2 (все редакции)

И вот как его можно проверить:

1. Войдите в систему с правами локального администратора.

2. На рабочем столе создайте папку с именем Папка.

3. Скопируйте в эту папку любой .EXE файл.

4. Нажмите Start и в поле Search for programs or files введите Local Security Policy. Вы должны увидеть значок редактора локальных политик и нажмите на него. Если появится запрос подтверждения User Account Control, подтвердите операцию или введите пароль своей учётной записи.

5. В раскрывшемся окне разверните секцию Application Control Policies.

6. Выделите и разверните секцию AppLocker.

7. Выберите секцию Executable rules.

8. Нажмите правой кнопкой мыши на эту секцию и выберите Create Default Rules. Этой операцией вы создадите правила по умолчанию, которые позволят запускать любые исполняемые файлы в %systemroot%, %programfiles% и разрешит запускать абсолютно всё встроенной учётной записи администратора.

9. Найдите это правило для встроенных администраторов и удалите его. Вот как выглядит правило, которое следует удалить:
   

10. Теперь вы сможете запускать исполняемые файлы только из папок %systemroot% и %programfiles%, а остальные папки будут запрещены для запуска исполняемых файлов. Нажмите правой кнопкой мыши на Executable rules и нажмите Create New Rule.

11. На странице Before You Begin вы можете узнать основные сведения о мастере. Нажмите Next.

12. На странице Permissions убедитесь, что Action выставлен в Allow и User or group выставлено в Everyone (значения по умолчанию). Нажмите Next.

13. На странице Conditions выставьте переключатель в Path и нажмите Next.

14. На странице Path нажмите Browse Folders. Укажите созданную на рабочем столе папку (по умолчанию это C:\Users\<YourAccountName>\Desktop\Папка) и нажмите Ok. На этой же странице мастера нажмите Create.

15. Сверните окно консоли MMC.

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

Примечание: перед выполнением всех операций убедитесь, что у вас запущена служба Application Identity. Для этого вы можете запустить командную строку в elevated mode и выполнить следующую команду:

net start AppIDSvc

Воркэраунд для обхода проблемы опубликован здесь: Очередной баг в AppLocker (обновление)

Примечание: для успешного освоения данного материала, необходимо прочитать мою предыдущую запись по теме: Встречаем – AppLocker!

Я в своё время написал пост о порядке сортировки правил в Software Restriction Policies (Секреты Software Restriction Policies (часть 4)). Некоторые вопросы в интернетах говорят мне о том, что с AppLocker'ом люди не особо разобрались и сильно путаются. Виной тому — полное отсутствие вменяемой документации по вопросам практической реализации и отсутствие серого вещества у некоторых администраторов. Сегодня я покажу как AppLocker выявляет результирующий статус для запускаемого приложения/скрипта.

В Software Restriction Policies правила достаточно простые, хотя и со своими тараканами. Например, у нас есть возможность использовать один из двух уровней по умолчанию — Disallowed и Unrestricted. Правила в SRP так же могут быть определены одним из двух уровней (на самом деле в SRP ещё есть Basic User, но я его опускаю, как незначительный момент). Т.е. правило либо однозначно запрещает, либо однозначно разрешает вне зависимости от уровня по умолчанию. А результирующий уровень определялся нехитрым методом сортировок правил.

С AppLocker'ом ситуация немного иная. Теперь уровень по умолчанию только Disallowed. Т.е. запрещено всё, что не разрешено. Вроде бы и просто, но сами правила стали немного сложнее — появились исключения. В результате этих исключений значительно усложнилась и изменилась методика определения результирующего уровня для запускаемого файла.

Примечание: под «файлом» я здесь подразумеваю файл с расширением, контролируемым в AppLocker'е.

Итак, AppLocker позволяет создавать правила с уровнем Deny или Allow. Каждое правило пути или издателя (Publisher), кроме правила хешей, могут содержать исключения. Поскольку правило издателя не может уникально идентифицировать конкретный файл, т.к. поле Subject сертификата достаточно абстрактное понятие и под одно такое правило может подпадать сотни различных файлов. Причём, ситуация усугубляется тем, что в Software Restriction Policies в правило сертификата указывался конкретный сертификат подписи, AppLocker их просто перестаёт различать! Т.е. область действия правила издателя становится ещё шире, чем с классическими правилами сертификатов в SRP. То же самое и с правилами пути, поскольку по указанному пути сегодня может быть один файл, а завтра уже другой. Но для AppLocker'а это будет всё один файл. А ещё могут быть ситуации, когда по некоторому пути нужно разрешить всё, кроме какого-то набора файлов. Недостатки (и достоинства одновременно) компенсируются наличием в правилах исключений. Исключения позволяют значительно сократить количество правил в AppLocker'е.

Примечание: Единственный способ уникальной идентификации файла в AppLocker'е (равно как и в SRP) может быть только правило хеша, поскольку хеш условно говоря уникально идентифицирует файл (в пределах коллизий хеша). Именно по этой причине правило хеша не поддерживает возможность использования исключений.

Основной сценарий, который многих сбивает с толку: создаём запрещающее правило по правилу издателя или правилу пути. Однако определённые файлы, подпадающие под этот запрет должны быть разрешены для запуска. Для этих целей мы можем смело воспользоваться исключениями. Поэтому мы вносим такие файлы в исключения по пути, хешу или издателю. И, казалось бы, исключение из запрета означает явное разрешение. На первый взгляд это так и есть. Однако, следует помнить, что AppLocker использует неотключаемое действие по умолчанию — Disallowed. И когда файл выпадает из явного запрета, он не разрешается автоматически, поскольку подпадает под действие по умолчанию, если нет явного разрешения. Вот такие пирожки. Следовательно, можно вывести общий постулат AppLocker'а: разрешённый файл не должен быть явно запрещён и должен быть явно разрешён. Этот постулат будет доказан и продемонстрирован чуть ниже.

Если SRP использовал сортировку правил по их типу, устанавливая заданный приоритет для каждого вида, AppLocker более не использует такой метод. Запрет по правилу пути не может быть перекрыт даже разрешением по хешу или правилу издателя, как это работает в SRP. AppLocker сортирует правила по их действию — Deny и Allow. Запреты отрабатываются в первую очередь и затем разрешения. Опираясь на мои исследования я составил примерно такой алгоритм работы правил аплокера:

• Сначала проверяются все явные запреты (в произвольном порядке).
  • Если файл подпал под явный запрет, то для этого запрета отрабатываются все исключения. Если файл всё ещё подпадает под явный запрет, то файл помещается в список «Denied» и блокируется для запуска. Остальные шаги проверки не производятся.
  • Если после обработки исключений больше не подпадает под явный запрет, то берётся следующее запрещающее правило и так продолжается, пока не будут проверены все явные запреты.
  • Если после отработки всех запретов, файл больше не подпадает под явный запрет, он помещается в список «Processing».
• Если файл находится в списке «Processing», файл проходит через второй этап проверки. Если список «Processing» пуст, файл не проходит через второй этап и хмуро блокируется для запуска.
• Если файл подпал под явное разрешение, то для этого разрешения отрабатываются все исключения. Если файл всё ещё подпадает под разрешение, файл помещается в список «Allowed» и разрешается для запуска. Остальные шаги проверки не производятся.
• Если после обработки исключений файл больше не подпадает под явное разрешение, то берётся следующее разрешающее правило, и процесс повторяется для каждого разрешающего правила.
• Если после отработки всех разрешений, файл всё ещё находится в списке «Processing», к файлу применяется действие по умолчанию. Т.е. файл блокируется для запуска.

Примечание: на самом деле никаких таких списков не существует, это я всё соврал. Я их придумал только для улучшения понимания.

Для наглядной демонстрации алгоритма я нарисовал следующую картинку:

Ну и в качестве бонуса — практическая задача, которая продемонстрирует этот алгоритм в действии.

Задача:

На компьютере в каталог по умолчанию установлен пакет Microsoft Office, которым можно пользоваться всем. Но группе «Accountants» необходимо разрешить запускать только программы Word и Excel. Запуск остальных файлов из «Program Files» разрешён без ограничений.

Решение:

Для решения этой задачи мы должны разрешить весь каталог «Program Files» по правилу пути для группы «Everyone». Поскольку доступ к программам Microsoft Office будет ограничен только для группы «Accountants», мы создаём новое запрещающее правило (с действием «Deny»), которое применяется только к группе «Accountants». Теперь программы из пакета Microsoft Office будут разрешены для запуска всем, кроме группы «Accountants». Чтобы обеспечить запуск только необходимых приложений из этой папки, мы редактируем запрещающее правило и добавляем два исключения (по правилу пути, хеша или издателя) для файлов «Excel.exe» и «Winword.exe».

Проверка:

Исходя из диаграммы, посмотрим, что будет происходить, когда член группы Accountants запустит PowerPNT.exe (PowerPoint).

При запуске мы попадаем на первый условный переход: подпадает ли файл под какой-нибудь запрет? Да, у нас есть запрет на папку %programfiles%\Microsoft Office. Следовательно выходим на следующий условный переход: указан ли PowerPNT.exe в исключениях? Правило запрета не предусматривает исключения для этого файла, следовательно мы выходим на действие «File is blocked to run». При этом алгоритм заканчивается.

А теперь член группы Accountants запускает Excel.exe (Excel). При запуске мы снова попадаем на первый условный переход: подпадает ли файл под запрет? Да, у нас есть запрет на папку %programfiles%\Microsoft Office. Следовательно переходим на следующий условный переход: указан ли Excel.exe в исключениях данного правила? Да, указан в исключениях, поэтому переходим на третий условный переход: есть ли ещё запрещающие правила? Если нет, мы сразу попадаем на четвёртый условный переход, который уже отрабатывает разрешения. Если есть ещё запрещающие правила, в них Excel.exe никак не запрещается (по условию задачи это не подразумевается), мы прямиком с первого условного перехода попадаем на четвёртый условный переход: подпадает ли файл хоть под одно разрешающее правило? Да, файл подпадает под разрешающее правило всего каталога Program Files для группы Everyone, в которую входит и группа Accountants. В результате попадаем на пятый условный переход: есть ли исключение для Excel.exe в этом разрешающем правиле? Нет, исключений для правила не предусмотрено и мы выходим на действие «File is allowed to run».

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

Напоследок ещё хочется отметить ситуацию применения множественных политик. Так же как и в случае с Software Restriction Policies, правила никак не замещаются, а суммируются. Т.е. собираются в один список, после чего AppLocker оперирует правилами, собранных со всех политик, применённых к конкретному компьютеру.

Что бы почитать?

• Встречаем – AppLocker!
• Секреты Software Restriction Policies (часть 4)

В последнее время мне всё чаще стали задавать вопрос, что выбрать, AppLocker или старый добрый SRP?

Казалось бы, что тут думать — AppLocker и точка. Многие, наверное, помнят пиар-акцию под названием «Windows 7 + 1», которую проводили многие MVP для рекламы новых технологий Windows 7. И весьма досадно то, что некоторые MVP вместо раскрытия реальной объективности новых технологий распространяли просто маркетинговый булшит и даже подтасовывали факты. Например статья Владимира Безмалого про AppLocker:

• AppLocker как средство обеспечения информационной безопасности
• AppLocker Часть 2

Этот вариант статьи можно ещё прочитать и здесь: http://www.osp.ru/win2000/2009/09/10721226/. Моё внимание обратила на себя табличка сравнения SRP и AppLocker. Вот она с моими комментариями:

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

На счёт мастера создания правил я немного не понял. В принципе, окно создания правила в SRP тоже своего рода мастер. Только одношаговый, в отличии от AppLocker.

А сообщения об ошибках в SRP были тоже. Как в виде диалогоых окон, так и в журнале Application в эвентлоге. Т.е. тут у меня 2 мнения — либо человек не работал с SRP, либо намеренно исказил факты, чтобы подкрутить популярность AppLocker'а, поскольку революции AppLocker не совершил. Ведь с появлением AppLocker мы приобрели не только удобный интерфейс, но и потеряли несколько полезных вещей, которые есть в SRP. Как я уже отмечал ранее, мы потеряли возможность самостоятельно регулировать список контролируемых расширений файлов и потеряли возможность фильтрования файлов по конкретным сертификатам. Новое правило издателя позволяет контролировать версию разрешённого приложения, но не отличает каким сертификатом подписано приложение. Да и применимость издателей такая же как и у классических правил сертификатов — т.е. низкая. К сожалению я не могу вспомнить ни одно бизнес-приложение (не стандартные приложения типа Microsoft Office), которое бы было подписано. Плюс невозможность использования системных переменных окружения так же усложняет создание правил в доменной среде. Эту табличку можно переделать в такой вид:

Мы видим, что преимущество AppLocker перед SRP резко переходит на нет. Я не хочу сказать, что AppLocker — отстой, а лишь хочу показать, что реализация этой технологии не на столько крутая, что её стоит пиарить как революцию.

Из блога Владимира Безмалого:

В Windows 7 SRP также могут применяться, однако все чаще будет использоваться AppLocker. Почему?

К сожалению этого не случится, во всяком случае в цикле Windows 7. Как уже отмечалось, наиболее значительное изменение в AppLocker — это новый простой, удобный и понятный интерфейс, чего в SRP не было. В значительной степени из-за этого SRP на домашних компьютерах применялся лишь в единичных случаях. Сейчас же применить AppLocker гораздо проще на домашних системах при получении одинаково эффективного результата. Но Microsoft слишком жадный и включил эту технологию только в Windows 7 Ultimate и Enterprise. Я верю, что от появления SRP в домашних редакциях Windows 7 количество применений SRP на них не увеличится совсем. Учитывая, что с ноутбуками будет чаще всего проинсталлирована какая-то домашняя редакция Windows 7, то профита от AppLocker они не получат тоже. Но если дома есть возможность использовать AppLocker и вы хотите получить адекватный уровень защиты от запуска случайных файлов — используйте AppLocker. Хотя, скажите, кто из вас, кроме меня, использует Windows 7 Ultimate/Enterprise дома и использует AppLocker? :-)

Если вы будете иметь возможность перевести часть парка машин предприятия на Windows 7 Enterprise, то вопрос использования AppLocker может сложиться не в его пользу. Это обусловлено тем, что если у вас уже используется SRP, то вам AppLocker не будет нужен до тех пор, пока весь парк не будет переведён на Windows 7 Enterprise. Ведь с AppLocker вы ощутимых бенефитов не получите в плане безопасности, но сразу усложните себе жизнь тем, что вам придётся поддерживать гораздо больше политик — SRP и AppLocker. При необходимости поддерживать клиентов отличных от Windows 7 Enterprise лучше использовать то, что может охватить наиболее число машин — SRP.

Внимать моим рекомендациям — личное дело каждого, просто я отразил своё видение проблематики. Вобщем, я не верю в массовое светлое будущее AppLocker по крайней мере до выхода следующей версии Windows, даже не смотря на активный и нечестный пиар технологии со стороны Microsoft (что вполне нормально для самого создателя) и прочих пиарщиков. Но начинать его использование по мере возможности — очень даже можно и нужно, т.к. однажды SRP просто не окажется в релизе ОС.