На страже безопасностиСредства управления списками ACL
Йеспер Йохансон (Jesper M. Johansson)
В Windows списки управления доступом (списки ACL) позволяют довольно точно управлять способностью пользователей и процессов использовать ресурсы, такие как файлы и папки. Управление списками ACL — одна из самых сложных задач обеспечения безопасности операционных систем пользователей. К счастью, существует несколько полезных служебных программ,
помогающих автоматизировать и упростить выполнение задач, связанных с разрешениями и списками ACL.
Большинство читателей знакомо с замечательным средством cacls.exe — оно было в каждой версии Windows NT® с самого момента ее появления. Если запустить cacls.exe в Windows Vista™, вы увидите следующее сообщение:
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Windows\system32>cacls
NOTE: Cacls is now deprecated, please use Icacls.
Специалисты корпорации Майкрософт обновили не только списки ACL в Windows Vista (об этом рассказывалось в выпуске журнала TechNet Magazine за июнь 2007 г. — см. technetmagazine.com/issues/ 2007/06), но и некоторые средства управления ими. Что интересно, самые значительные изменения коснулись средств с интерфейсом командной строки.
Средство Icacls.exe появилось в Windows Vista (как средство нижнего уровня оно присутствует в Windows Server® 2003 с пакетом обновления 2 (SP2)). В конечном итоге оно заменит средство cacls.exe, в котором — как вы, наверное, знаете — так и не была реализована поддержка более детализированных разрешений, введенных в Windows® 2000. Подобное обновление следовало бы выпустить еще лет семь назад.
Странно, но хотя средство cacls.exe представляется как устаревшее, в нем появились новые функции. Во-первых, оно воспринимает и точки соединения, и символические ссылки, и знает, как их просматривать. Во-вторых, оно умеет и печатать, и настраивать списки ACL с использованием строки SDDL.
Но несмотря на все обновления cacls.exe, нельзя не оценить функции, предоставляемые средством icacls.exe.
Сохранение и восстановление списков ACL
Все последние 10 лет возникало желание — по крайней мере, у меня — иметь возможность сохранять списки ACL, чтобы потом их можно было восстанавливать. Как оказалось, это одна из самых сложных операций при работе со списками ACL. Лишь в редких случаях удается вернуться к тому же точно состоянию, не уничтожив первым делом списки ACL. Тем не менее, эти функции могут быть довольно полезны.
Прежде чем рассказывать, как сохранять и восстанавливать списки ACL, я попытаюсь объяснить, почему это так сложно сделать. Допустим, у вас есть иерархия с данными пользователей — студентов местного колледжа. 1 февраля вы сохраняете список ACL. 17 апреля вы обнаруживаете, что он каким-то образом поврежден, и хотите восстановить его из сохраненной копии. Какие трудности могут возникнуть при этом?
Во-первых, 2 апреля начинается новый триместр. Около 15 процентов студентов ушло из колледжа, поэтому их каталоги больше не существуют. Значит, в резервной копии есть недействительные списки ACL. Некоторое количество студентов — еще 15 процентов — поступило в этом триместре. У них уже есть домашние каталоги, а списков ACL в резервной копии нет. Как должны выглядеть списки ACL для них? И, разумеется, есть еще те 70 процентов пользователей, которые никуда не уходили — но они создавали одни файлы и папки и удаляли другие. На удаленные папки можно не обращать внимания, а вот как настроить созданные? А если один из студентов 4 марта сделал свою папку общей, чтобы использовать ее совместно с друзьями? Уничтожите ли вы эту функцию, восстановив списки ACL?
Сохранить и восстановить списки ACL не так просто, как многие пытаются вас убедить. Тут нужно действовать очень осторожно. В результате вы можете столкнуться с неожиданным поведением — даже, скорее всего, так и будет. Восстанавливать списки ACL, конечно, нужно только в крайнем случае. И чем больше времени прошло с момента создания копии, тем выше вероятность что-то испортить при восстановлении.
Если же, несмотря на все вышесказанное, хотите попробовать эти функции в действии, запустите icacls.exe с параметром /save.
icacls <target> /save acls.bin /t
Списки ACL будут сохранены в файл acls.bin. В файле будет по одной строке на каждый объект. За ACL будет следовать строка, определяющая ACL в SDDL. Если использовать в команде параметр /t, она применяется к указанному объекту и ко всем объектам и контейнерам, расположенным ниже по иерархии.
Функция сохранения — удачное дополнение к средству, но у нее есть несколько изъянов. Например, сохранять можно только списки управления доступом на уровне пользователя (списки DACL) — системные списки (SACL) сохранять нельзя. В действительности в случае с SACL сохраняется некое подставное значение, показывающее, что это системный список доступа, но сам список SACL по сути дела не сохраняется.
Еще одна любопытная проблема связана с тем, каким образом сохраняются списки ACL. Прежде чем открыть сохраненный ACL в любимом текстовом редакторе, запомните:
Никогда не вносите изменения в сохраненные списки ACL!
Если вдруг вам доведется открыть файл с сохраненным ACL в текстовом редакторе, вы увидите, что он, на первый взгляд, представляет собой форматированный текстовый файл в кодировке Юникод (UTF-16). Это почти правда. И исходя из этого вы можете подумать, что файл можно изменить и сохранить в текстовом редакторе. Этого делать не стоит.
Если вы откроете файл с сохраненным ACL в текстовом редакторе, а затем сохраните его, восстановить список ACL из этого файла не удастся. Все дело в том, что это не просто текст в кодировке Юникод. Каждый такой файл должен начинаться с двух байтов 0xfffe. Когда вы сохраняете файл в текстовом редакторе, он как раз помещает в первые 2 байта этот флаг. Но вот средство icacls.exe ожидает, что данные ACL начинаются с нулевого байта в файле. Следовательно, ему не удастся разбить файл на отдельные ACL, поскольку первые два байта будут восприниматься как часть строки, соответствующей обрабатываемому объекту. Резервный файл станет непригодным для использования.
Специалисты корпорации Майкрософт знают об этой проблеме, но она была выявлена уже на стадии завершения бета-тестирования Windows Vista, поэтому до выпуска системы она исправлена не была. Пока неизвестно, когда она будет устранена и будет ли устранена вообще. Так что сейчас можно только посоветовать не вносить изменения в сохраненные списки ACL. Если все-таки это необходимо, сохраните файл с расширением BIN и используйте шестнадцатеричный редактор — например свою любимую среду разработки.
Список ACL, сохраненный при помощи параметра /save, можно восстановить, используя команду icacls.exe с параметром /restore. Команда восстановления в простейшей ее форме выглядит следующим образом:
icacls <directory> /restore acls.bin
Процедура восстановления применяется не к файлам. Чтобы это понять, посмотрите на последовательность команд, приведенных на рис. 1. Я создал сохраненный файл, применив команду icacls.exe к файлу. Затем я попытался восстановить его, попросту заменив /save на /restore. Это не сработало, поскольку команда восстановления применяется только к каталогам. Файлы, которые должны быть изменены в ходе ее работы, уже указаны в файле acls.bin. Чтобы восстановить список ACL, нужно указать каталог, а не файл. Именно это я и делаю, когда указываю "." в качестве обрабатываемого объекта.
Figure 1 Сохранение и восстановление списков ACL
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files
C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
Обратите внимание, что команда восстановления должна выполняться под учетной записью с повышенными правами. Команду сохранения можно выполнить в командной строке под учетной записью администратора с ограниченными правами, даже под учетной записью простого пользователя, если в ней есть право считывать ACL. А вот для восстановления списка ACL необходима учетная запись администратора с полным набором прав, без ограничений.
Замена идентификаторов SID
Еще одна очень полезная функция icacls.exe — это возможность заменять разрешения одного пользователя разрешениями другого. Это делается при восстановлении при помощи параметра /substitute. В документации по параметру говорится, что для его использования необходим идентификатор SID, но чуть ниже разъясняется, что можно взять просто имя пользователя. То есть последовательность команд, приведенная на рис. 2, работает.
Figure 2 Замена идентификаторов безопасности при восстановлении
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
Как вы видите, я пришел к тому же списку ACL, с которого и начал, но элемент ACE, который определял разрешения для пользователя foo, теперь определяет разрешения для пользователя bar.
Смена владельца
Средство chown долгие годы существовало исключительно в системах UNIX. В Windows изначально не было встроенного средства для изменения владельца объектов. Затем в комплекте Resource Kit появилось средство setowner. За ним последовало средство takeown.exe в Windows NT 4.0, но эта служебная программа позволяло только присвоить объекты себе. Чтобы передать объекты другому пользователю, нужно было знать его пароль. В средстве icacls.exe есть встроенные возможности установить владельца для тех объектов, для которых у вас есть разрешение на установку владельца.
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
К сожалению, средство icacls.exe не показывает владельца объекта. В командной строке невозможно увидеть, кому же на самом деле объект принадлежит. Кроме того, когда вы сохраняете список ACL для объекта, владелец его не сохраняется.
В средстве icacls.exe есть еще одна ошибка: оно не вызывает SeTakeOwnershipPrivilege при изменении владельца. Если вы имеете право изменять владельца объекта на основании ACL, средство icacls.exe работает правильно. Если же вы являетесь администратором, но не имеете разрешения на изменение владельца на основании ACL данного объекта, изменить его при помощи средства icacls.exe не удастся — как раз из-за этой ошибки. В таком случае необходимо использовать средство takeown.exe — оно вызывает SeTakeOwnershipPrivilege, но может установить в качестве владельца не любую учетную запись, а только вашу учетную запись или группу администраторов.
C:\>takeown /f c:\test
SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
Конечно, нужно отметить, что средство subinacl, которое можно загрузить из центра загрузки корпорации Майкрософт, также использует ключ setowner. Во многих случаях средство subinacl понятнее, чем icacls, но также верно, что его гораздо сложнее использовать.
Поиск файлов определенного пользователя
В средстве icacls есть еще одна полезная функция: оно позволяет найти файлы, у которых есть разрешения для определенных пользователей. Пример:
C:\windows\system32>icacls “c:\program files” /findsid jesper /t
SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
Это может пригодиться, если нужно будет выяснить, к каким элементам имеет доступ некий пользователь.
Сброс и изменение списков ACL
Средство icacls.exe позволяет сбросить поврежденный или разрушенный список ACL путем наследования от родительского. Эта функция очень бы пригодилась осенью 2006 года, когда обнаружилась проблема с безопасностью «нулевого дня». Одним из методов, использованных для ослабления ее негативных последствий в Windows, был запрет доступа группы Everyone к объекту. Это было несложно. А вот удалить элементы управления доступом (ACE) встроенными средствами Windows XP и Windows Server 2003 оказалось практически невозможно. В Windows Vista нужно было бы просто выполнить вот такую команду:
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset
processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
В средстве icacls.exe, разумеется, есть и все стандартные операции grant/deny/remove. Единственный действительно новый элемент в этом списке — remove. При помощи этого параметра можно удалить все разрешающие элементы ACE для данного пользователя от данного объекта или иерархии, все запрещающие элементы ACE или и то, и другое. На рис. 3 приведены примеры различных операций grant, remove и deny.
Figure 3 Операции grant, deny и remove
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
Возможностью удалять только запрещающие элементы ACE удобно пользоваться, чтобы открывать доступ к объекту для определенной группы или пользователя.
Настройка уровней целостности
Кроме того, средство icacls.exe позволяет посмотреть и установить уровни целостности. В системе Windows Vista поддерживается нанесение меток целостности на объекты. Делается это в командной строке при помощи средства icacls.exe следующим образом:
C:\>icacls c:\test /setintegritylevel high
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Mandatory Label\High Mandatory Level:(NW)
Successfully processed 1 files; Failed processing 0 files
Обратите внимание, что icacls.exe показывает метку целостности объекта, только если она была установлена явным образом. Для большинства файлов это не так, поэтому метки видны редко.
Наконец, средство icacls.exe позволяет проверить, является ли список ACL для того или иного объекта каноническим. Как говорилось ранее, средства сторонних разработчиков могут располагать элементы ACE в списках ACL в неверном порядке. Средство icacls.exe может проверить наличие подобных проблем и исправить их следующим образом:
C:\>icacls c:\test /verify
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
Пользовательский интерфейс ACL
ACL UI, или пользовательский интерфейс ACL, несколько отличается от используемого в Windows XP. На рис. 4 и рис. 5 показано диалоговое окно пользовательского интерфейса ACL в Windows XP и Windows Vista соответственно.
Рис. 4** Диалоговое окно ACL UI в Windows XP **
Рис. 5** Диалоговое окно ACL UI в Windows Vista **
Как можно заметить, кое-что изменилось. Во-первых, в диалоговом окне наконец-то довольно четко отображен обрабатываемый объект — это может быть удобным при работе с несколькими объектами одновременно. Во-вторых, в нижней части есть ссылка на справку. Однако самое заметное изменение — это то, что кнопки «Добавить» и «Удалить» исчезли, а вместо них появилась кнопка «Изменить» — она часто встречается в модулях управления доступом на уровне пользователей (UAC) в Windows Vista. На кнопке стоит значок щита: у пользователя, запустившего диалоговое окно, нет разрешения на изменение списка ACL, ему нужно будет получить повышенные права, прежде чем он сможет редактировать разрешения. Обратите внимание, что эта настройка не будет использоваться по умолчанию, если вы создаете папку в корне диска C: и сразу же проверяете ее свойства. Поскольку вы являетесь владельцем папки, у вас есть неявные разрешения на изменение ACL, поэтому щит не появится. Щит означает специальное имя COM — механизм, при помощи которого выдается запрос на необходимость иметь повышенные права для выполнения части текущего процесса. Если вы нажмете кнопку «Изменить», вы увидите знакомое диалоговое окно повышения. Если в нем нажать кнопку «Далее», появится диалоговое окно, практически совпадающее с тем, что появляется в Windows XP при нажатии кнопки «Добавить». В пользовательском интерфейсе ACL такая двухоконная процедура используется в нескольких местах. Пока не повышены права, появляется одно окно, а когда права повышены, появляется другое — уже знакомое по предыдущим версиям Windows.
Если нажать кнопку «Дополнительно» и перейти на вкладку «Аудит», вы в любом случае увидите кнопку повышения (см. рис. 6). Для изменения аудита обязательно требуются повышенные права, даже если вы имеете полный контроль над объектом и являетесь его владельцем. Это связано с тем, что способность изменять объекты SACL управляется привилегией SE_SECURITY_NAME — в средствах с графическим интерфейсом она называется «Управление аудитом и журналом безопасности». По умолчанию это право есть только у администраторов. Однако в режиме одобрения администратором (когда включено UAC) это право у администраторов отбирается, поэтому даже им необходимо повышение.
Рис. 6** Изменение параметров аудита в Windows Vista всегда требует повышения прав **
Наконец, вот что нужно упомянуть про изменение списков ACL: все вышесказанное верно, только если UAC не отключен. Если UAC отключить, поведение будет соответствовать тому, что было в Windows XP — разве что диалоговые окна будут выглядеть по-другому. Если вы войдете под учетной записью администратора, повышения нигде не потребуется, поскольку у вашего маркера все время будет идентификатор безопасности администратора.
Другие средства
Средство icacls.exe весьма полезно — и является большим шагом вперед по сравнению с cacls.exe — но и у него есть недостатки. Пожалуй, самый серьезный из них — это способность управлять доступом только к файлам и каталогам. Списки ACL других объектов в Windows Vista мало отличаются от списков в Windows XP, однако в некоторых случаях возникает необходимость управлять списками ACL для служб, разделов реестра, даже объектов Active Directory®.
Ярые приверженцы командной строки используют для этого средство subinacl.exe. Subinacl.exe есть в средствах поддержки. Его также можно загрузить здесь.
Должен вас предупредить, что средство subinacl.exe использовать непросто. Временами оно демонстрирует просто непробиваемое упрямство. И все же оно дает широчайшие возможности управления доступом. Любому уважающему себя администратору это средство необходимо.
Списки ACL для реестра
Списки ACL для реестра, равно как и системные ACL, претерпели некоторые изменения. Впрочем, они не так значимы, как изменения для файловой системы. Самое очевидное отличие от предыдущих версий Windows состоит в том, что из-за устранения группы «опытные пользователи» пропали практически все элементы ACE для опытных пользователей. Теперь считается, что опытные пользователи в действительности не опытнее всех остальных. Это свидетельствует лишь о том, насколько сложны списки ACL. Пропали, конечно, не все элементы ACE для опытных пользователей, но некоторых, к сожалению, действительно не хватает.
Среди списков ACL в реестре вам встретится элемента ACE для идентификатора безопасности с именем RESTRICTED. Он появился не в Windows Vista, но идентификатор этот стоит упомянуть. Не все хорошо понимают, для чего он нужен. Идентификатором безопасности RESTRICTED обозначается любой процесс, представляющий маркер ограничения. Маркер ограничения создается специальной функцией интерфейса API CreateRestrictedToken. Маркер может иметь один или несколько ограничивающих идентификаторов безопасности, используемых в разделенной проверке доступа. Допустим, у нас есть процесс, выполняемый с маркером ограничения. Если такой процесс попытается получить доступ к объекту с элементом ACE для идентификатора безопасности RESTRICTED, Windows на самом деле выполнит две проверки. Первая — это обычная проверка доступа. Вторая же проверка полностью идентична первой, но проверяются только ограничивающие идентификаторы безопасности в маркере. Обе проверки доступа должны пройти успешно.
Сейчас существует несколько списков ACL, использующих идентификатор безопасности RESTRICTED — в частности, в реестре. Снимок экрана, иллюстрирующий такой список ACL, приведен на рис. 7.
Рис. 7** Списки ACL для реестра содержат несколько элементов ACE для идентификатора RESTRICTED **
На данный момент немногие процессы используют маркеры ограничения, тем более с ограничивающими идентификаторами безопасности. В качестве примера можно привести процесс службы, который размещает брандмауэр Windows, базовый механизм фильтрации и службу политики диагностики. Он также использует маркер ограничения записи. Насколько я знаю, только девять служб в Windows Vista используют идентификатор RESTRICTED и маркеры ограничения записи.
Как и в предыдущих версиях Windows, с разрешениями реестра нужно быть очень аккуратным. Изменять их следует только в самых исключительных случаях и для решения строго определенных проблем. Учитывая сложность модели наследования и деликатность операций, выполняемых с реестром, вероятность серьезного сбоя при неосторожном изменении списков ACL в реестре недопустимо высока.
Заключение
Как и в большинстве версий Windows, в Windows Vista были внесены незначительные изменения в управление доступом. Но — в отличие от предыдущих версий — большое количество незначительных изменений довольно серьезно изменило поведение. UAC, в частности, потребовал нескольких корректив: меток целостности и модификации пользовательского интерфейса ACL. Кроме того, произошла первая в истории крупная очистка списков ACL.
Со многих точек зрения стандартные списки ACL в Windows Vista стали проще — такого не было еще никогда. Однако, как и в предыдущих версиях, работая со списками доступа, следует соблюдать осторожность и хорошо понимать происходящее. Это особенно важно в новых версиях ОС. К счастью, средства, описанные в данной статье, помогут вам с меньшими потерями исследовать списки ACL.
Йеспер Йохансон (Jesper M. Johansson) является главным инженером группы безопасности программного обеспечения и пишущим редактором журнала TechNet Magazine. Он защитил диссертацию по информационным системам управления и более 20 лет работает в области обеспечения компьютерной безопасности. Эта статья составлена на основе материалов новой книги Роджера Граймса (Roger Grimes) и Йеспера Йохансона Безопасность в Windows Vista. Защита системы от вредоносных атак (Издательство Wiley, 2007 г.)
© 2008 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.