В новых версиях Windows появились небольшие усовершенствования для работы со списком управления доступом Access Control List (ACL). Улучшения часто бывают связаны с фундаментальными изменениями в применении разрешений, поэтому важно понять, как они влияют на безопасность. ACL представляет собой список разрешений (таких, как Administrators — Full Control, Users — Read), назначенных разделу реестра, папке NTFS или другому объекту. Каждая запись в списке ACL, такая как Users — Read, именуется элементом управления доступом Access Control Entry (ACE).

В данной статье рассматриваются изменения в работе со списком ACL в Vista и Windows Server 2008 и последующих версиях и возможность более надежно защитить операционную систему и упростить управление безопасностью.

Права владельца

Одно из важнейших изменений в Vista и Windows Server 2008 — добавление нового идентификатора безопасности (SID), именуемого OWNER RIGHTS. В новых операционных системах любые действующие разрешения, применяемые к назначенному владельцу объекта, имеют приоритет перед владением. Если у владельца папки нет права записи, он не сможет скопировать файл в эту папку. Функция контроля учетных записей (UAC) не повышает разрешений. Необходимо изменить список ACL для папки, и сделать это может владелец объекта, если только права владельца по умолчанию не были изменены.

Идентификатор безопасности OWNER RIGHTS позволяет изменить этот порядок. Предположим, владелец папки имеет только разрешение READ для списка ACL. Если добавить элемент ACE, в котором идентификатор безопасности OWNER RIGHTS имеет разрешение WRITE (экран 1), то можно будет скопировать в папку новый файл.

Идентификатор безопасности OWNER RIGHTS

Если после этого попытаться изменить ACL папки, выяснится, что потеряно право доступа для ее изменения, поскольку назначение разрешения WRITE идентификатору безопасности OWNER RIGHTS не позволяет изменить список ACL. Если вместо WRITE задать FULL CONTROL, то можно будет скопировать файл и изменить разрешения папки. Однако, если изменить владельца объекта, OWNER RIGHTS не передается новому владельцу автоматически. Поэтому, если пользователь лишил себя права изменять разрешения, можно изменить владельца и устранить любые проблемы, связанные с разрешениями. OWNER RIGHTS ACE остается, но наследованию присваивается режим Nothing, что фактически отменяет все указанные в элементе разрешения.

Идентификатор безопасности OWNER RIGHTS в Vista и Windows Server 2008 позволяет администратору назначать права владения пользователю или группе, но предоставляет и механизм, с помощью которого пользователю или группе можно запретить изменять разрешения для объекта. Идентификатор безопасности OWNER RIGHTS позволяет упростить назначение прав, если нужно предоставить пользователю или группе возможность создавать новые папки и файлы, но не изменять разрешения для них, добавляя надлежащим образом элемент ACE для OWNER RIGHTS.

Если пользователь создает объект и впоследствии удаляется из группы, которая применяется для назначения разрешений этому объекту, пользователь остается владельцем объекта. Это позволяет ему отредактировать список ACL объекта и добавить элемент ACE для учетной записи пользователя, чтобы вновь получить доступ к объекту. Однако, если назначить разрешение DENY для WRITE_DAC (Change permissions) для вложенных папок и папок (экран 2), когда пользователь удален из группы, применяемой для назначения разрешений объектам, пользователь не сможет вернуть доступ к объектам, созданным путем изменения списков ACL.

Разрешение DENY для WRITE_DAC (Change permissions)

Рассмотрим список ACL для папки с именем Accounts:

OWNER RIGHTS: (OI) (CI) (IO) (DENY)

(special access:)

WRITE_DAC

NT AUTHORITYSYSTEM: (OI) (CI)F

FILESERVERAccounts: (OI) (CI)C

BUILTINAdministrators: (OI) (CI)F

Моя учетная запись пользователя — член только группы FILESERVERAccounts, и я создаю новую папку с именем Confidential Spreadsheets в папке Accounts. По умолчанию я владелец новой папки. Затем я был удален из группы Accounts, но остался владельцем папки Confidential Spreadsheets. В Vista у меня, как владельца Confidential Spreadsheets, нет стандартных прав доступа к этой папке, таких как READ и WRITE. Из-за флага WRITE_DAC DENY для OWNER RIGHTS я не могу изменить список ACL и предоставить себе доступ.

Стандартные разрешения CREA­TOR OWNER в XP, Windows Server 2003 и Windows Server 2008 дают владельцу новых объектов право FULL CONTROL только для этих объектов, добавляя элемент ACE, содержащий идентификатор безо­пасности владельца объекта. В Windows XP и Windows Server 2003, независимо от удаления CREATOR OWNER ACE, итоговый результат будет таким же, как в описанном случае; мне будет отказано в доступе к папке Confidential Spreadsheets.

Если бы список ACL был сложнее и содержал NT AUTHORITYAuthenticated Users: (CI)R ACE (List Folder Contents), я мог бы просмотреть папку. В этом случае, если бы моя учетная запись была удалена из группы Accounts, а флаг WRITE_DAC DENY не установлен в элементе ACE для OWNER RIGHTS на ранее созданном объекте, то можно было бы получить прямой доступ к папке Confidential Spreadsheets, так как CREATOR OWNER ACE предоставил право FULL CONTROL моей учетной записи пользователя, или можно было бы изменить список ACL, поскольку я по-прежнему остаюсь пользователем объекта. Наглядно последовательность действий данного сценария представлена на рисунках 1 и 2.

Сценарий действия разрешения при отсутствии флага OWNER RIGHTS WRITE_DACL Deny

Жирным шрифтом показаны различия в структуре и результатах между двумя сценариями. Вряд ли Authenticated Users будут на практике иметь какие-либо разрешения в папке, содержащей конфиденциальные данные. Однако, настраивая OWNER RIGHTS ACE, можно сформировать дополнительный уровень защиты и уменьшить уязвимость в случаях, когда списки ACL составлены неправильно.

Если добавить элемент ACE для OWNER RIGHTS в папке Accounts во время создания папки, а затем попытаться изменить владельца из учетной записи пользователя, например назначив владельцем группу Administrators, то необходимо сбросить OWNER RIGHTS ACE.

Присвоение ACE наследования значения Nothing

На экране 3 показано, как Windows назначает наследованию ACE значение Nothing после изменения владельца. Раскройте меню и установите режим наследования Subfolders and files only, как показано на рисунке 2.

Сценарий действия разрешения при наличии флага OWNER RIGHTS WRITE_DACL Deny

Стандартные списки ACL

В таблицах показаны списки ACL для корневого каталога системного диска (обычно C:) и каталога Windows (C:Windows) в Windows XP, Vista, Server 2003 и 2008. Эти таблицы были подготовлены с использованием утилиты cacls.exe, на смену которой в Vista пришла утилита icacls.

Сравнение списков ACL в корневом каталоге системного диска в Windows Vista и Windows XP Professional

Результаты работы icacls немного отличаются, поэтому во избежание путаницы данные для всех операционных систем подготовлены с использованием cacls.

Списки ACL для корневого каталога Vista

В результатах этих команд поначалу трудно разобраться (таблица 1), поэтому полезно сравнить таблицу 1 с экранами 4 и 5.

Списки ACL для корневого каталога Windows XP

Корневой каталог системного диска (C:)

Разрешения BUILTINAdministra­tors и SYSTEM были разделены на два элемента ACE. Удалены такие элементы ACE, как Everyone и CREATOR OWNER. Элементы BUILTINUsers были заменены на Authenticated Users, за исключением BUILTINUsers: (OI) (CI)R ACE, который компенсирует отсутствие Everyone.

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

Списки ACL для корневого каталога Windows Server 2008

Группа Authenticated Users получает разрешение MODIFY. CREATOR OWNER остается в Windows Server 2008, как показано в таблице 2 (см. также экраны 6 и 7).

Сравнение списков ACL в корневом каталоге системного диска в Windows Server 2008 и Windows Server 2003 R2

Списки ACL для корневого каталога Windows Server 2003 R2

Каталог Windows (C:Windows)

Разрешения в каталоге Windows немного изменились (таблица 3).

Сравнение списков ACL в корневом каталоге Windows в Windows Vista и Windows XP Professional

Не стало группы Power Users, зато появился TrustedInstaller. Элементы ACE для SYSTEM и BUILTINAdministrators немного изменены; указаны другие разрешения: MODIFY для каталога Windows верхнего уровня и FULL CONTROL для вложенных папок и файлов.

Разрешения для каталога Windows в Vista

Поэтому, если просматривать эти разрешения в интерфейсе пользователя Vista, можно увидеть два элемента для BUILTINAdministrators и SYSTEM соответственно (экраны 8 и 9).

Разрешения для каталога Windows в XP Professional

В Windows XP файлам операционной системы в каталоге Windows по умолчанию назначено разрешение Full Control для группы Administrators. Теперь это не так, и новому идентификатору безопасности с именем TrustedInstaller предоставляются полное управление и владение файлами операционной системы (таблица 4).

Сравнение списков ACL в корневом каталоге Windows в Windows Server 2008 и Windows Server 2003 R2

Разрешения для каталога Windows в Windows Server 2008

Цель этого изменения — помешать установщику программ автоматически заменять файлы операционной системы при работе с учетными данными администратора (см. также экраны 10 и 11).

Разрешения для каталога Windows в Windows Server 2003 R2

В Vista добавлены точки подсоединения (junction point) для обратной совместимости. В точке подсоединения Documents and Settings к группе Everyone применен ACE-элемент Deny. Это должно помешать пользователям обращаться напрямую и удалять точки подсоединения. Однако у группы Everyone есть право Bypass Traverse Checking, назначаемое для таких точек подсоединения. Это позволяет унаследованным программам обращаться к файлам, указывая полный путь к файлу, но мешает просмотру случайными пользователями.

Контроль учетных записей и списки ACL

При переходе к папке, для чтения которой у пользователя нет разрешения, функция контроля учетных записей (UAC) выдает диалоговое окно, содержащее предупреждение об отсутствии разрешения для доступа к папке и приглашение щелкнуть на кнопке Continue, чтобы получить доступ к папке. Из диалогового окна не ясно, каким образом будет предоставлен доступ. Когда UAC предоставляет доступ к файлу или папке, то в отличие от других операций UAC, проводник Windows не перезапускается с расширенным маркером, который предоставляет временный доступ к папке для чтения. Вместо этого создается READ ACE для объекта, в свою очередь наследуемый всеми дочерними объектами. Можно заметить небольшую задержку после нажатия кнопки Continue. Это происходит потому, что к объектам в иерархии папки добавляется новый элемент ACE. Поэтому не удивляйтесь, если после такой операции пользователь получает доступ для чтения части файловой системы, ранее ему недоступной.

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

Рассел Смит (rms@russell-smith.net) — независимый ИТ-консультант, специализируется на управлении системами

Флаги наследования доступа

Краткое описание контейнера Access Inheritance Flags поможет лучше понять информацию, приведенную в статье. Эти флаги используются для представления параметров наследования в командной строке таких программ, как cacls:

(IO) Inherit Only — элемент ACE не влияет на объект, к которому он применяется;

(OI) Object Inherit — элемент ACE будет влиять на подчиненные файлы;

(CI) Container Inherit — элемент ACE будет влиять на подчиненные папки.

Например, (OI) (CI) вместе означают, что элемент ACE применяется к вложенным папкам, но не к файлам, и не влияет на объект, к которому применен. В графическом интерфейсе это будет представлено как Subfolders only. (IO) (CI) (OI) отображаются в графическом интерфейсе как Subfolders and files only. Разрешения не применяются к объекту, которому назначается элемент ACE, но распространяются на вложенные папки и файлы.

F — Full Control

R — Read

C — Modify (Change)

Стандартные  учетные записи и группы — участники безопастности

Прежде чем создать элемент управления доступом Access Control Entry (ACE) для объекта, необходимо, чтобы идентификатор безопасности (SID) учетной записи или группы указал, к какому участнику безопасности будет применяться элемент ACE. Во встроенных учетных записях и группах произошли важные изменения. Начиная с Windows Vista учетная запись Administrator по умолчанию отключена. Часто пароль учетной записи Administrator был на всех рабочих станциях одинаковым, что представляло угрозу безопасности. При необходимости встроенная учетная запись Administrator все же может использоваться в режиме Safe Mode и в консоли восстановления. В Windows Server 2008 и Vista функция контроля учетных записей (UAC) не применяется к встроенной учетной записи Administrator. Но если не задано иное, контроль учетных записей применяется ко всем новым учетным записям, членам группы Administrators.

Группа Power Users по-прежнему существует в целях обратной совместимости, но ее возможности ограничены. Права, предоставленные этой группе в предшествующих версиях Windows, удалены. Механизм Remote Assistance переработан, и учетная запись HelpAssistant больше не нужна. Исчезла и учетная запись Support_<1234>, которая использовалась для запуска сценариев Support Center.

Появились новые группы: IIS_IUSRS с такими же функциями, как у учетной записи IUSR_ в XP. Благодаря удалению части имени учетной записи проще управлять учетной записью с помощью таких автоматизированных механизмов, как групповая политика, поскольку имя одинаково на всех компьютерах; Event Log Readers, которая устраняет необходимость изменять строки Security Description Definition Language (SDDL) в журналах событий; группа Performance Log Users может назначать расписание внесения в журнал показателей счетчика производительности, включать провайдеров трассировки, локально и удаленно перечислять следы событий, но право контроля системных процессов по-прежнему предоставляется через привилегию Profile system performance (SeSystemProfilePrivilege); группа Performance Monitor Users имеет доступ к данным счетчиков производительности; группа Distributed COM Users первоначально появилась в Windows Server 2003 SP1, чтобы обеспечить простой способ применить к учетным записям пользователей настройки ограничения компьютера DCOM; в Vista SP1 и Server 2008 группа Cryptographic Operators активизирует Cryptography API: Next Generation (CNG), предоставляя доступ к таким элементами, как настройки шифрования в политике IPSec брандмауэра Windows.