XP vs Vista. Списки управления доступом
Было время – я писал о списках управления доступом и о том, каким образом их можно использовать. Это было довольно давно, поэтому рассматривались списки, относящиеся к Windows XP. Время бежит, уже больше года активно используется операционная система Windows Vista — платформа, отличная от предшествующей, поэтому и списки управления доступом претерпели изменения. Кроме того, в новой ОС отредактированы дефолтные группы пользователей и принадлежащие им права на доступ и операции. Сегодня я хотел бы рассмотреть подробнее, какие именно новшества имеются в Vista относительно XP, чтобы вы могли более грамотно управляться с системой управления правами. Что ж, приступим.
Для начала остановлюсь на двух проблемах, которые были наиболее критичными в ХР. Первая проблема — это, конечно же, наделение всех создаваемых пользователей при установке системы правами администратора. Если же пользователь имеет права администратора, то, не мне вам рассказывать, из-под его учетной записи запускаются абсолютно все приложения, без проблем изменяются параметры и компоненты. Это все делает систему достаточно уязвимой. Совершенно очевидно, что любое вредоносное программное обеспечение или хакерская утилита установит свои модули и будет понемногу "подслащать" жизнь владельцу машины тормозами или пересылкой информации пользователя.
Вторая неприятность – наличие группы пользователей "Все", которая активно используется в ACL, это, естественно, немного напрягает. Да и оплошности, допущенные при проработке прав владельца файла, позволяют ему вносить любые изменения в файл, при этом вне зависимости от того, какими правами он наделен по отношению к этому же файлу.
В висте проработаны и исправлены как раз такие вот проблемы, которые, может, и не носят критичности в некоторых вариантах, но вызывают неприятное чувство понимания наличия бага. Для начала давайте пробежимся по группам пользователей и учетным записям, а потом перейдем к дефолтным правам этих пользователей и групп.
Опытные пользователи
В планах компании Microsoft вообще отказаться от использования этой группы, но это будет в будущем. Пока же группа присутствует, однако она лишена большинства прав. Вообще, члены группы "опытные пользователи" в XP были фактически администраторами, просто еще не знали об этом. Небольшой каламбур, но это не меняет ситуации. Действительно, при создании этой группы был баг, и имелась возможность наделения ее членов правами администратора. Всего-то была необходима небольшая программка, естественно, написанная на месте, так как должны учитываться при написании особенности конкретной системы.
Возникает вполне закономерный вопрос — почему же не убрать группу сразу. Зачем же тянуть резину и изменять права, чтобы потом все равно избавиться. Но для этого есть свои причины, поскольку во многих компаниях достаточно сложная иерархия, которой просто необходима подобная группа.
Учетная запись Администратор
Сразу хочу оговориться, что учетная запись Администратор — это совсем не простая учетная запись, которая является членом группы
"администраторы". Администратор имеет SID 500, который включает в себя ряд привилегий и разрешений, не доступных больше ни одному пользователю в системе.
Изначально учетная запись должна была применяться для восстановления данных, в тех случаях, когда другие варианты не действуют. Однако большинство пользователей используют ее в качестве стандартной учетной записи. Это не просто неправильно, а чревато последствиями. Как пример можно привести то, что изменения, сделанные в системе из-под учетной записи Администратора, нельзя отследить.
На данный момент в висте эта учетная запись отключена, однако ею можно пользоваться в безопасном режиме и при работе с консолью восстановления, если в системе не имеется других локальных администраторов.
Учетная запись Trusted Installer
Если вы обращали внимание, то в висте при настройке разрешений файловой системы можно увидеть учетную запись Trusted Installer. На самом деле — это не учетная запись, а служба. В безопасность служб были внесены изменения, и теперь каждая из служб является полноценным участником безопасности, имеет SID и т.д.
Идентификатор безопасности (SID) для служб теперь не назначается привычными администраторами безопасности, такими как NT AUTHORITY или администратор домена. Полное название виртуальной учетной записи для службы TrustedInstaller — NT SERVICE\TrustedInstaller, а идентификатор безопасности этой записи
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
Кстати, идентификатор безопасности можно узнать даже для той службы, которой просто не существует в системе, для этого необходимо выполнить команду sc showsid в командной строке со следующим синтаксисом sc showsid имя_службы. И вы получите уже проработанный SID для вымышленной службы (рис.1).
Этот идентификатор безопасности начинается со строчки S-1-5-80. Октет 80 соответствует относительному идентификатору
SECURIY_SERIVCE_ID_BASE_RID. Это означает, что идентификатор службы назначается администратором безопасности NT SERVICE. Это справедливо для любой службы. Остальная часть идентификатора и относительные идентификаторы RID зависят от имени службы. Это позволяет разработчику службы устанавливать для нее разрешения, даже если служба еще не была собрана и установлена. Идентификатор определяется именем службы и поэтому совпадает на различных компьютерах.
Центр справки и поддержки
В ХР для выполнения сценариев при связи с центром связи и поддержки на сервере использовались учетные записи HelpAssistant и Support_[значение]. В висте таких записей больше нет, хотя при обновлении со старой версии до висты они все-таки остаются. В висте переработаны многие компоненты удаленного помощника и службы справки и поддержки, поэтому и необходимость в этих учетных записях исчезла.
SID: OWNER RIGHTS
Новый идентификатор безопасности Owner Right (права владельца) является как раз решением проблемы, которая описана мной в начале статьи. Идентификатор существует с одной целью – ограничивать права владельца файла. При этом, если этот идентификатор применен к владельцу, то его ограничения и права будут иметь приоритет перед фактом владения файлом.
SID сетевого расположения
В операционных системах на основе ядра Windows NT всегда присутствовали идентификаторы безопасности сетевого расположения, такие как NETWORK и INTERACTIVE. С их помощью можно было различать пользователей, выполнивших выход через сеть и интерактивно. Также в системах был идентификатор безопасности REMOTE INTERACTIVE LOGON, который назначался пользователям, выполнившим вход через службу терминалов. На самом деле у пользователей службы терминалов в маркере безопасности есть оба идентификатора: REMOTE INTERACTIVE LOGON и INTERACTIVE LOGON. В ОС Windows Vista помимо этих двух идентификаторов были добавлены еще два: DIALUP и INTERNET. Смысл выделения пользователей, выполнивших вход через телефонное подключение, не совсем ясен, особенно учитывая тот факт, что все больше и больше пользователей предпочитают не использовать такие соединения в качестве единственного способа подключения к сети. Тем не менее, этот идентификатор присутствует. Идентификатор INTERNET, очевидно, предназначен для выделения пользователей, выполнивших вход из-за пределов локальной сети. Идентификатором NETWORK отмечаются любые пользователи, выполнившие вход через локальную сеть или через Интернет.
Теперь мы рассмотрим дефолтные ACL записи.
Запрещение
В висте присутствует запрещающая запись "Для всех". Назначение ее не совсем понятно. Давайте рассмотрим одну ситуацию: если открыть для всеобщего взора скрытые папки и файлы, то в корне мы обнаружим папку Documents and Settings, при попытке входа в которую система культурно пошлет нас, выдав сообщение "доступ запрещен". Чтобы понять ситуацию, необходимо просмотреть содержимое системного тома из командной строки (рис.2).
Теперь становится понятно, что Documents and Settings — это и не папка вовсе. Это точка соединения, которая ссылается на C:/Users. Дело в том, что в висте было изменено пространство имен и привычное всем содержимое Documents and Settings теперь располагается в C:/Users. Это было сделано для того, чтобы облегчить навигацию для пользователей и нагляднее представить иерархию. Данные приложений, общие для всех пользователей, теперь располагаются в скрытой папке %systemroot%\ProgramData, а не в папке Documents and Settings\All Users\Application Data.
Папка Documents and Settings была оставлена для того, чтобы обеспечить совместимость некоторого софта, в коде которого определен строго путь хранения параметров. Для этого и создана была точка входа, которая должна перенаправить приложение в необходимо русло, так сказать.
Если ввести в адресной строке запрос на открытие файла типа C:\Documents and Settings\имя_пользователя>\Мои документы\1.jpg, то проблем с открытием не возникнет, а вот сама папка Documents and Settings не открывается. Взгляните на список разрешений для этой папки и все станет ясно (рис.3). Обратите внимание на первую строку списка. Этот параметр запрещает пользователям просматривать содержимое папки, но при этом имеется возможность использования полного пути. Именно для этого и была создана запись на запрещение для всех, просто чтобы исключить использование точки доступа пользователями.
Дефолтные разрешения
В ОС Windows Vista разрешения по умолчанию для файловой системы несколько отличаются от разрешений в ОС Windows XP. Списки ACL для папок %systemdrive% (обычно значение этой переменной соответствует загрузочному разделу C:\) в ОС Windows XP или Windows Server 2003 выглядят так:
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
Ниже приведен список ACL для той же папки в ОС Windows Vista:
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
Между этими двумя списками есть ряд различий, которые стоит отметить. Во-первых, встроенной группе BA (BUILTIN\Администраторы) в списке соответствуют две записи, а не одна. При этом результирующие права, которые получает учетная запись, в обоих случаях одинаковы. В ОС Windows Vista одна запись ACE предоставляет полный доступ к корневой папке и не распространяется на вложенные объекты, а другая запись распространяется только на вложенные папки и файлы и предоставляет все встроенные права (GA или, иначе, "полный доступ"). То же самое относится и к записям ACE для участника безопасности SY (LocalSystem). В ОС Windows XP одна запись ACE предоставляла полный доступ как непосредственно к корневой папке, так и к вложенным папкам и файлам. Результирующие разрешения в первом и во втором случае совпадают. Разделение на две записи было сделано для упрощения управления, а также на случай необходимости восстановления списка ACL.
Интересное отличие заключается в отсутствии в варианте для системы Windows Vista записи ACE для участника безопасности CO (Создатель-владелец). Это означает, что теперь при создании пользователем объекта в корневой папке файловой системы этому объекту не будут назначаться специальные разрешения для его создателя.
Также видно, что отсутствует запись ACE для участника безопасности WD (Все). Многих пользователей, которые интересовались вопросами безопасности, волновал вопрос присутствия этой записи ACE, несмотря на то, что они не всегда осознавали последствия совершаемых ими действий. Сотрудники корпорации Майкрософт безуспешно пытались в течение нескольких лет объяснить, что участник безопасности "Все" и встроенная группа "Пользователи" функционально идентичны. В конце концов, они отчаялись и просто убрали эту запись из списка. Благодаря наличию идентичной записи ACE для встроенной группы BU (BUILTIN\Пользователи), которая также наследуется вложенными папками и файлами, в итоге удаление этой записи не вызвало никаких изменений.
Помимо этого, две из записей ACE для группы BU были заменены на записи ACE для участника безопасности AU (Прошедшие проверку). Причина заключается в том, что учетная запись "Гость" является членом встроенной группы "Пользователи" (благодаря членству встроенного участника безопасности "ИНТЕРАКТИВНЫЕ" в группе "Пользователи"), но не является членом участника безопасности "Прошедшие проверку". Чтобы у пользователя "Гость" были права на чтение и выполнение файлов, запись ACE с номером 0x1200a9 (Чтение и выполнение) по-прежнему назначается для группы BU. Записи ACE, которые разрешают создавать файлы и папки, относятся теперь только к пользователям, прошедшим проверку. Это постепенный переход от системы Windows XP к системе Windows Vista. В отличие от ОС Windows XP, в ОС Windows Vista пользователь "Гость" не может создавать файлы в корневой папке. Не следует забывать, что на практике такое ограничение редко требовалось. Чтобы создавать файлы в корневой папке, необходимо включить учетную запись "Гость" и получить доступ к корню загрузочного раздела. По умолчанию учетная запись "Гость" отключена.
На этом я, пожалуй, остановлюсь. Конечно, рассмотрены были не все изменения, а только основные, которые наиболее часто встречаются пользователям. Если же задаться целью описать все изменения, то понадобится целый цикл статей, и получатся они уже ориентированными больше на профессионалов, чем на рядовых юзеров. Поэтому остановимся на том, что было озвучено. Да, и перед экспериментами над списками доступа и правами пользователей сделайте копии критически важных данных и не говорите потом, что я не предостерег ;)
Евгений Кучук, q@sa-sec.org SASecurity gr.
Для начала остановлюсь на двух проблемах, которые были наиболее критичными в ХР. Первая проблема — это, конечно же, наделение всех создаваемых пользователей при установке системы правами администратора. Если же пользователь имеет права администратора, то, не мне вам рассказывать, из-под его учетной записи запускаются абсолютно все приложения, без проблем изменяются параметры и компоненты. Это все делает систему достаточно уязвимой. Совершенно очевидно, что любое вредоносное программное обеспечение или хакерская утилита установит свои модули и будет понемногу "подслащать" жизнь владельцу машины тормозами или пересылкой информации пользователя.
Вторая неприятность – наличие группы пользователей "Все", которая активно используется в ACL, это, естественно, немного напрягает. Да и оплошности, допущенные при проработке прав владельца файла, позволяют ему вносить любые изменения в файл, при этом вне зависимости от того, какими правами он наделен по отношению к этому же файлу.
В висте проработаны и исправлены как раз такие вот проблемы, которые, может, и не носят критичности в некоторых вариантах, но вызывают неприятное чувство понимания наличия бага. Для начала давайте пробежимся по группам пользователей и учетным записям, а потом перейдем к дефолтным правам этих пользователей и групп.
Опытные пользователи
В планах компании Microsoft вообще отказаться от использования этой группы, но это будет в будущем. Пока же группа присутствует, однако она лишена большинства прав. Вообще, члены группы "опытные пользователи" в XP были фактически администраторами, просто еще не знали об этом. Небольшой каламбур, но это не меняет ситуации. Действительно, при создании этой группы был баг, и имелась возможность наделения ее членов правами администратора. Всего-то была необходима небольшая программка, естественно, написанная на месте, так как должны учитываться при написании особенности конкретной системы.
Возникает вполне закономерный вопрос — почему же не убрать группу сразу. Зачем же тянуть резину и изменять права, чтобы потом все равно избавиться. Но для этого есть свои причины, поскольку во многих компаниях достаточно сложная иерархия, которой просто необходима подобная группа.
Учетная запись Администратор
Сразу хочу оговориться, что учетная запись Администратор — это совсем не простая учетная запись, которая является членом группы
"администраторы". Администратор имеет SID 500, который включает в себя ряд привилегий и разрешений, не доступных больше ни одному пользователю в системе.
Изначально учетная запись должна была применяться для восстановления данных, в тех случаях, когда другие варианты не действуют. Однако большинство пользователей используют ее в качестве стандартной учетной записи. Это не просто неправильно, а чревато последствиями. Как пример можно привести то, что изменения, сделанные в системе из-под учетной записи Администратора, нельзя отследить.
На данный момент в висте эта учетная запись отключена, однако ею можно пользоваться в безопасном режиме и при работе с консолью восстановления, если в системе не имеется других локальных администраторов.
Учетная запись Trusted Installer
Если вы обращали внимание, то в висте при настройке разрешений файловой системы можно увидеть учетную запись Trusted Installer. На самом деле — это не учетная запись, а служба. В безопасность служб были внесены изменения, и теперь каждая из служб является полноценным участником безопасности, имеет SID и т.д.
Идентификатор безопасности (SID) для служб теперь не назначается привычными администраторами безопасности, такими как NT AUTHORITY или администратор домена. Полное название виртуальной учетной записи для службы TrustedInstaller — NT SERVICE\TrustedInstaller, а идентификатор безопасности этой записи
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
Этот идентификатор безопасности начинается со строчки S-1-5-80. Октет 80 соответствует относительному идентификатору
SECURIY_SERIVCE_ID_BASE_RID. Это означает, что идентификатор службы назначается администратором безопасности NT SERVICE. Это справедливо для любой службы. Остальная часть идентификатора и относительные идентификаторы RID зависят от имени службы. Это позволяет разработчику службы устанавливать для нее разрешения, даже если служба еще не была собрана и установлена. Идентификатор определяется именем службы и поэтому совпадает на различных компьютерах.
Центр справки и поддержки
В ХР для выполнения сценариев при связи с центром связи и поддержки на сервере использовались учетные записи HelpAssistant и Support_[значение]. В висте таких записей больше нет, хотя при обновлении со старой версии до висты они все-таки остаются. В висте переработаны многие компоненты удаленного помощника и службы справки и поддержки, поэтому и необходимость в этих учетных записях исчезла.
SID: OWNER RIGHTS
Новый идентификатор безопасности Owner Right (права владельца) является как раз решением проблемы, которая описана мной в начале статьи. Идентификатор существует с одной целью – ограничивать права владельца файла. При этом, если этот идентификатор применен к владельцу, то его ограничения и права будут иметь приоритет перед фактом владения файлом.
SID сетевого расположения
В операционных системах на основе ядра Windows NT всегда присутствовали идентификаторы безопасности сетевого расположения, такие как NETWORK и INTERACTIVE. С их помощью можно было различать пользователей, выполнивших выход через сеть и интерактивно. Также в системах был идентификатор безопасности REMOTE INTERACTIVE LOGON, который назначался пользователям, выполнившим вход через службу терминалов. На самом деле у пользователей службы терминалов в маркере безопасности есть оба идентификатора: REMOTE INTERACTIVE LOGON и INTERACTIVE LOGON. В ОС Windows Vista помимо этих двух идентификаторов были добавлены еще два: DIALUP и INTERNET. Смысл выделения пользователей, выполнивших вход через телефонное подключение, не совсем ясен, особенно учитывая тот факт, что все больше и больше пользователей предпочитают не использовать такие соединения в качестве единственного способа подключения к сети. Тем не менее, этот идентификатор присутствует. Идентификатор INTERNET, очевидно, предназначен для выделения пользователей, выполнивших вход из-за пределов локальной сети. Идентификатором NETWORK отмечаются любые пользователи, выполнившие вход через локальную сеть или через Интернет.
Теперь мы рассмотрим дефолтные ACL записи.
Запрещение
Теперь становится понятно, что Documents and Settings — это и не папка вовсе. Это точка соединения, которая ссылается на C:/Users. Дело в том, что в висте было изменено пространство имен и привычное всем содержимое Documents and Settings теперь располагается в C:/Users. Это было сделано для того, чтобы облегчить навигацию для пользователей и нагляднее представить иерархию. Данные приложений, общие для всех пользователей, теперь располагаются в скрытой папке %systemroot%\ProgramData, а не в папке Documents and Settings\All Users\Application Data.
Папка Documents and Settings была оставлена для того, чтобы обеспечить совместимость некоторого софта, в коде которого определен строго путь хранения параметров. Для этого и создана была точка входа, которая должна перенаправить приложение в необходимо русло, так сказать.
Дефолтные разрешения
В ОС Windows Vista разрешения по умолчанию для файловой системы несколько отличаются от разрешений в ОС Windows XP. Списки ACL для папок %systemdrive% (обычно значение этой переменной соответствует загрузочному разделу C:\) в ОС Windows XP или Windows Server 2003 выглядят так:
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
Ниже приведен список ACL для той же папки в ОС Windows Vista:
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
Между этими двумя списками есть ряд различий, которые стоит отметить. Во-первых, встроенной группе BA (BUILTIN\Администраторы) в списке соответствуют две записи, а не одна. При этом результирующие права, которые получает учетная запись, в обоих случаях одинаковы. В ОС Windows Vista одна запись ACE предоставляет полный доступ к корневой папке и не распространяется на вложенные объекты, а другая запись распространяется только на вложенные папки и файлы и предоставляет все встроенные права (GA или, иначе, "полный доступ"). То же самое относится и к записям ACE для участника безопасности SY (LocalSystem). В ОС Windows XP одна запись ACE предоставляла полный доступ как непосредственно к корневой папке, так и к вложенным папкам и файлам. Результирующие разрешения в первом и во втором случае совпадают. Разделение на две записи было сделано для упрощения управления, а также на случай необходимости восстановления списка ACL.
Интересное отличие заключается в отсутствии в варианте для системы Windows Vista записи ACE для участника безопасности CO (Создатель-владелец). Это означает, что теперь при создании пользователем объекта в корневой папке файловой системы этому объекту не будут назначаться специальные разрешения для его создателя.
Также видно, что отсутствует запись ACE для участника безопасности WD (Все). Многих пользователей, которые интересовались вопросами безопасности, волновал вопрос присутствия этой записи ACE, несмотря на то, что они не всегда осознавали последствия совершаемых ими действий. Сотрудники корпорации Майкрософт безуспешно пытались в течение нескольких лет объяснить, что участник безопасности "Все" и встроенная группа "Пользователи" функционально идентичны. В конце концов, они отчаялись и просто убрали эту запись из списка. Благодаря наличию идентичной записи ACE для встроенной группы BU (BUILTIN\Пользователи), которая также наследуется вложенными папками и файлами, в итоге удаление этой записи не вызвало никаких изменений.
Помимо этого, две из записей ACE для группы BU были заменены на записи ACE для участника безопасности AU (Прошедшие проверку). Причина заключается в том, что учетная запись "Гость" является членом встроенной группы "Пользователи" (благодаря членству встроенного участника безопасности "ИНТЕРАКТИВНЫЕ" в группе "Пользователи"), но не является членом участника безопасности "Прошедшие проверку". Чтобы у пользователя "Гость" были права на чтение и выполнение файлов, запись ACE с номером 0x1200a9 (Чтение и выполнение) по-прежнему назначается для группы BU. Записи ACE, которые разрешают создавать файлы и папки, относятся теперь только к пользователям, прошедшим проверку. Это постепенный переход от системы Windows XP к системе Windows Vista. В отличие от ОС Windows XP, в ОС Windows Vista пользователь "Гость" не может создавать файлы в корневой папке. Не следует забывать, что на практике такое ограничение редко требовалось. Чтобы создавать файлы в корневой папке, необходимо включить учетную запись "Гость" и получить доступ к корню загрузочного раздела. По умолчанию учетная запись "Гость" отключена.
На этом я, пожалуй, остановлюсь. Конечно, рассмотрены были не все изменения, а только основные, которые наиболее часто встречаются пользователям. Если же задаться целью описать все изменения, то понадобится целый цикл статей, и получатся они уже ориентированными больше на профессионалов, чем на рядовых юзеров. Поэтому остановимся на том, что было озвучено. Да, и перед экспериментами над списками доступа и правами пользователей сделайте копии критически важных данных и не говорите потом, что я не предостерег ;)
Евгений Кучук, q@sa-sec.org SASecurity gr.
Компьютерная газета. Статья была опубликована в номере 03 за 2009 год в рубрике ос
