Усовершенствованные ACL в Windows Vista и Windows Server 2008

В новых версиях 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), то можно будет скопировать в папку новый файл.

Если после этого попытаться изменить 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.

Рассмотрим список 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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) — независимый ИТ-консультант, специализируется на управлении системами