3. Если вызывающий поток является владельцем объекта, ему предоставляются права управления чтением (read-control access) и доступа к DACL для записи (write-DACL access).
      4. Из маски предоставленных прав доступа удаляется маска доступа каждого ACE типа «доступ отклонен», SID которого совпадает с SID маркера доступа вызывающего потока.
      5. K маске предоставленных прав доступа добавляется маска доступа каждого ACE типа «доступ разрешен», SID которого совпадает с SID маркера доступа вызывающего потока (исключение составляют права доступа, в предоставлении которых уже отказано).
      После анализа всех элементов DACL рассчитанная маска предоставленных прав доступа возвращается вызывающему потоку как максимальные права доступа. Эта маска отражает полный набор типов доступа, которые этот поток сможет успешно запрашивать при открытии данного объекта.
      Все сказанное применимо лишь к той разновидности алгоритма, которая работает в режиме ядра. Его Windows-версия, реализованная функцией GetEffectiveRigbtsFromAcl,отличается отсутствием шага 2, а также тем, что вместо маркера доступа она рассматривает SID единственного пользователя или группы.
 
      Второй алгоритм проверяет, можно ли удовлетворить конкретный запрос на доступ, исходя из маркера доступа вызывающего потока. У каждой Windows-функции открытия защищенных объектов есть параметр, указывающий желательную маску доступа – последний элемент выражения, описывающего защиту объектов. Чтобы определить, имеет ли вызывающий поток право на доступ к защищенному объекту, выполняются следующие операции.
      1. B отсутствие DACL (DACL = null) объект является незащищенным, и система защиты предоставляет к нему запрошенный тип доступа.
      2. Если у вызывающего потока имеется привилегия на захват объекта во владение, система защиты предоставляет владельцу право на доступ для записи, а затем анализирует DACL. Однако, если такой поток запросил только доступ владельца для записи, система защиты предоставляет этот тип доступа и не просматривает DACL.
      3. Если вызывающий поток является владельцем объекта, ему предоставляются права управления чтением и доступа к DACL для записи. Если вызывающий поток запросил только эти права, система защиты предоставляет их без просмотра DACL.
      4. Просматриваются все ACE в DACL – от первого к последнему. Обработка ACE выполняется при одном из следующих условий:
      a. SID в ACE типа «доступ отклонен» совпадает с незаблокированным SID (SID могут быть незаблокированными и заблокированными) или SID с атрибутом проверки только на запрет в маркере доступа вызывающего потока;
      b. SID в ACE типа «доступ разрешен» совпадает с незаблокированным SID в маркере доступа вызывающего потока, и этот SID не имеет атрибута проверки только на запрет;
      c. Идет уже второй проход поиска в дескрипторе ограниченных SID, и SID в ACE совпадает с ограниченным SID в маркере доступа вызывающего потока.
      5. B случае ACE типа «доступ разрешен» предоставляются запрошенные права из маски доступа АСЕ; проверка считается успешной, если предоставляются все запрошенные права. Доступ к объекту не предоставляется в случае ACE типа «доступ отклонен» и отказа в предоставлении какого-либо из запрошенных прав.
      6. Если достигнут конец DACL и некоторые из запрошенных прав доступа еще не предоставлены, доступ к объекту запрещается.
      7. Если все права доступа предоставлены, но в маркере доступа вызывающего потока имеется хотя бы один ограниченный SID, то система повторно сканирует DACL в поисках АСЕ, маски доступа которых соответствуют набору запрошенных прав доступа. При этом также идет поиск АСЕ, SID которых совпадает с любым из ограниченных SID вызывающего потока. Поток получает доступ к объекту, если запрошенные права доступа предоставлялись после каждого прохода по DACL.
      Поведение обоих алгоритмов проверки прав доступа зависит от относительного расположения разрешающих и запрещающих АСЕ. Возьмем для примера объект с двумя АСЕ, первый из которых указывает, что определенному пользователю разрешен полный доступ к объекту, а второй отказывает в доступе. Если разрешающий ACE предшествует запрещающему, пользователь получит полный доступ к объекту. При другом порядке этих ACE пользователь вообще не получит доступа к объекту.
      Более старые Windows-функции вроде AddAccessAllowedAceдобавляли ACE в конец DACL, что нежелательно. Таким образом, до появления Windows 2000 большинство Windows-приложений были вынуждены создавать DACL вручную, помещая запрещающие ACE в начало списка. Несколько функций Windows, например SetSecurityInfoи SetNamedSecurityInfo,используют предпочтительный порядок АСЕ: запрещающие ACE предшествуют разрешающим. Заметьте, что эти функции вызываются при редактировании, например, прав доступа к NTFS-файлам и разделам реестра. SetSecurityInfoи SetNamedSecurityInfoтакже применяют правила наследования ACE к дескриптору защиты, для операций над которым они вызываются.
 
      Ha рис. 8-5 показан пример проверки прав доступа, демонстрирующий, насколько важен порядок АСЕ. B этом примере пользователю отказано в доступе к файлу, хотя ACE в DACL объекта предоставляет такое право (в силу принадлежности пользователя к группе Writers). Это вызвано тем, что запрещающий ACE предшествует разрешающему.
       Маркер доступа
      Пользователь: DaveC
      Как уже говорилось, обработка DACL системой защиты при каждом использовании описателя процессом была бы неэффективной, поэтому SRM проверяет права доступа только при открытии описателя, а не при каждом его использовании. Так что, если процесс один раз успешно открыл описатель, система защиты не может аннулировать предоставленные при этом права доступа – даже когда DACL объекта изменяется. Учтите и вот еще что: поскольку код режима ядра обращается к объектам по указателям, а не по описателям, при использовании объектов операционной системой права доступа не проверяются. Иначе говоря, исполнительная система полностью доверяет себе в смысле защиты.
      Тот факт, что владелец объекта всегда получает право на запись DACL при доступе к объекту, означает, что пользователям нельзя запретить доступ к принадлежащим им объектам. Если в силу каких-то причин DACL объекта пуст (доступ запрещен), владелец все равно может открыть объект с правом записи DACL и применить новый DACL, определяющий нужные права доступа.
 

Будьте осторожны при использовании GUI-средств изменения параметров защиты

      Модифицируя с помощью GUI-средств параметры защиты объектов «файл», «реестр», Active Directory или других защищаемых объектов, имейте в виду, что основное диалоговое окно безопасности создает потенциально неверное представление о защите, применяемой для объекта. B верхней части этого окна в алфавитном порядке показываются группы и пользователи, чьи ACE имеются в ACL данного объекта. Если вы выдадите Full Control группе Administrators и запретите его группе Everyone, то, судя по алфавитному списку, можете подумать, будто ACE типа «доступ разрешен» для группы Administrators предшествует ACE типа «доступ отклонен» для группы Everyone. Однако, как мы уже говорили, средства редактирования, применяя ACL к объекту, помещают запрещающие ACE перед разрешающими.
      Ha вкладке Permissions (Разрешения) диалогового окна Advanced Security Settings (Дополнительные параметры безопасности) показывается порядок ACE в DACL. Однако даже это диалоговое окно может ввести в заблуждение, так как в сложном DACL за запрещающими ACE для различных видов доступа могут быть расположены разрешающие ACE для других типов доступа.
      Единственный способ точно узнать, какие виды доступа к объекту будут разрешены конкретному пользователю или группе (помимо метода проб и ошибок), – открыть вкладку Effective Permissions. Введите здесь имя пользователя или группы, и диалоговое окно покажет, какие разрешения на доступ к объекту будут действовать на самом деле.
 

AuthZ API

      Auth2 API, впервые введенный в Windows XP, реализует ту же модель защиты, что и Security Reference Monitor (монитор состояния защиты), но исключительно для пользовательского режима; все функции AuthZ API находятся в библиотеке \Windows\System32\Authz.Dll. Это позволяет приложениям, нуждающимся в защите своих закрытых объектов (вроде таблиц базы данных), задействовать Windows-модель защиты без издержек, связанных с переходами из пользовательского режима в режим ядра, которые были бы неизбежны при использовании Security Reference Monitor.
      AuthZ API оперирует стандартными структурами дескриптора защиты, SID и привилегиями. Вместо применения маркеров для представления клиентов, AuthZ использует AUTHZ_CLIENT_CONTEXT. AuthZ включает эквиваленты всех функций проверки прав доступа и защиты Windows; например AutbzAccessCbeck- это AuthZ-версия Windows-функции AccessCbeck,которая вызывает функцию SeAccessCbeck,принадлежащую Security Reference Monitor.
      Еще одно преимущество AuthZ заключается в том, что приложения могут указывать AuthZ кэшировать результаты проверок прав доступа для ускорения последующих проверок, где используются те же контекст клиента и дескриптор защиты.
      AuthZ полностью документирован в Platform SDK.
 

Права и привилегии учетных записей

      Многие операции, выполняемые процессами, нельзя авторизовать через подсистему защиты доступа к объектам, так как при этом не происходит взаимодействия с конкретным объектом. Например, возможность обходить проверки прав доступа при открытии файлов для резервного копирования является атрибутом учетной записи, а не конкретного объекта. Windows использует как привилегии, так и права учетных записей, чтобы системный администратор мог управлять тем, каким учетным записям разрешено выполнять операции, затрагивающие безопасность.
      Привилегия (privilege) – это право (right) учетной записи на выполнение определенной операции, затрагивающей безопасность, например на выключение компьютера или изменение системного времени. Право учетной записи разрешает или запрещает конкретный тип входа в систему, скажем, локальный или интерактивный.
      Системный администратор назначает привилегии группам и учетным записям с помощью таких инструментов, как ММС-оснастка Active Directory Users and Groups (Active Directory – пользователи и группы) или редактора локальной политики безопасности (Local Security Policy Editor)*. Запустить этот редактор можно из папки Administrative Tools (Администрирование). Ha рис. 8-6 показана конфигурация User Rights Assignment (Назначение прав пользователя) редактора локальной политики безопасности, при которой в правой части окна выводится полный список привилегий и прав (учетных записей), доступных в Windows Server 2003. Заметьте, что этот редактор не различает привилегии и права учетных записей. Ho вы можете сделать это сами, поскольку любое право, в названии которого встречается слово «logon» («вход»), на самом деле является привилегией.
      * B русской версии Windows XP окно этого редактора называется «Локальные параметры безопасности». – Прим. перев.
 

Права учетной записи

      Права учетной записи не вводятся в действие монитором состояния защиты (Security Reference Monitor, SRM) и не хранятся в маркерах. За вход отвечает функция LsaLogonUser.B частности, WinLogon вызывает API-функцию LogonUser,когда пользователь интерактивно входит в систему, aLogonUserобращается KLsaLogonUser.Эта функция принимает параметр, указывающий тип выполняемого входа, который может быть интерактивным, сетевым, пакетным, сервисным, через службу терминала или для разблокировки (unlock).
      B ответ на запросы входа служба локальной безопасности (Local Security Authority, LSA) извлекает назначенные пользователю права учетной записи из своей базы данных; эта операция выполняется при попытке пользователя войти в систему LSA сверяет тип входа с правами учетной записи и по результатам этой проверки отклоняет попытку входа, если у учетной записи нет права, разрешающего данный тип входа, или, напротив, есть право, которое запрещает данный тип входа. Права пользователей, определенные в Windows, перечислены в таблице 8-4.
      Windows-приложения могут добавлять или удалять права из учетной записи пользователя через функции LsaAddAccountRightsи LsaRemoveAccount-Rigbtsсоответственно, а также определять, какие права назначены учетной записи, вызывая функцию LsaEnumerateAccountRigbts.
 

Привилегии

      Число привилегий, определяемых в операционной системе, со временем выросло. B отличие от прав пользователей, которые вводятся в действие в одном месте службой LSA, разные привилегии определяются разными компонентами и ими же применяются. Скажем, привилегия отладки, позволяющая процессу обходить проверки прав доступа при открытии описателя другого процесса через API-функцию OpenProcess,проверяется диспетчером процессов. Полный список привилегий приведен в таблице 8-5.
      Компонент, которому нужно проверить маркер на наличие некоей привилегии, обращается к API-функции PrivilegeCheckили LsaEnumerateAccountRights,если он выполняется в пользовательском режиме, либо к SeSingle-PrivilegeCbeckили SePrivilegeCbeck,если он работает в режиме ядра. API-функции, работающие с привилегиями, ничего не знают о правах учетных записей, но API-функциям, оперирующим с правами, привилегии известны.
      B отличие от прав учетной записи привилегии можно включать и отключать. Чтобы проверка привилегии прошла успешно, эта привилегия должна находиться в указанном маркере и должна быть включена. Смысл такой схемы в том, что привилегии должны включаться только при реальном их использовании, и в том, чтобы процесс не мог случайно выполнить привилегированную операцию.
 
       ЭКСПЕРИМЕНТ: наблюдение за включением привилегии
      Следующая процедура позволит увидеть, как апплет Date and Time (Дата и время) из Control Panel включает привилегию SeSystemTime-Privilege, исходя из того, что его интерфейс будет использован для изменения даты или времени на компьютере.
      1. Войдите в систему под учетной записью, имеющей право «Change the system time» (Изменение системного времени); такая учетная запись обычно входит в группу администраторов или пользователей с правами администраторов.
      2. Запустите Process Explorer и выберите для частоты обновления значение Paused.
      3. Откройте вкладку Security в окне свойств какого-либо процесса, например Explorer. Вы должны увидеть, что привилегия SeChange-SystemTimePrivilege отключена.
      4. Запустите апплет Date and Time из Control Panel и обновите окно Process Explorer. B списке появится новый процесс Rundll, выделенный зеленым цветом.
      5. Откройте окно свойств для процесса Rundll (дважды щелкнув имя этого процесса) и убедитесь, что командная строка содержит текст «Timedate.Cpl». Наличие этого аргумента сообщает Rundll (хост-процессу Control Panel DLL) загрузить DLL, реализующую UI, который позволяет изменять дату и время.
      6. Перейдите на вкладку Security в окне свойств процесса Rundll и вы увидите, что привилегия SeSystemTimePrivilege включена.
 
       ЭКСПЕРИМЕНТ: привилегия Bypass Traverse Checking
      Если вы являетесь системным администратором, то должны знать о привилегии Bypass Traverse Checking (Обход перекрестной проверки)* (ее внутреннее название – SeNotifyPrivilege) и о том, какие последствия влечет за собой ее включение. Этот эксперимент демонстрирует, что непонимание ее поведения может привести к серьезному нарушению безопасности.
      1. Создайте папку, а в ней – новый текстовый файл с каким-нибудь текстом.
      2. Перейдите в Explorer к новому файлу и откройте вкладку Security (Безопасность) в его окне свойств. Щелкните кнопку Advanced (Дополнительно) и сбросьте флажок, управляющий наследованием. Выберите Сору (Копировать), когда появится запрос с предложением удалить или скопировать унаследованные разрешения.
      3. Далее сделайте так, чтобы по вашей учетной записи нельзя было получить доступ к этой новой папке. Для этого выберите свою учетную запись и в списке разрешений выберите все флажки типа Deny (отклонить или запретить).
      4. Запустите Notepad и попробуйте через его UI перейти в новую папку. Вы не сможете этого сделать.
      5. B поле File Name (Имя файла) диалогового окна Open (Открыть) введите полный путь к новому файлу. Файл должен открыться. Если в вашей учетной записи нет привилегии Bypass Traverse Checking, NTFS будет проверять права доступа к каждому каталогу в пути к файлу, когда вы попытаетесь открыть этот файл. И только в таком случае вам будет отказано в доступе к данному файлу.
      * Так эта привилегия называется в русской версии Windows XP, но на самом деле никакой перекрестной проверки нет – проверяются промежуточные каталоги в пути к файлу. Поэтому такую привилегию следовало бы назвать «Обход промежуточных проверок». – Прим. перев.
 

Суперпривилегии

      Несколько привилегий дают настолько широкие права, что пользователя, которому они назначаются, называют «суперпользователем» – он получает полный контроль над компьютером. Эти привилегии позволяют получать неавторизованный доступ к закрытым ресурсам и выполнять любые операции. Ho мы уделим основное внимание применению привилегии на запуск кода, который выдает привилегии, изначально не назначавшиеся пользователю, и при этом не будем забывать, что это может быть использовано для выполнения любой операции на локальном компьютере. B этом разделе перечисляются такие привилегии и рассматриваются способы их применения. Прочие привилегии вроде Lock Pages In Physical Memory (Закрепление страниц в памяти) можно использовать для атак типа «отказ в обслуживании», но мы не станем их обсуждать.
 
       (o) Debug programs (Отладка программ)Пользователь с этой привилегией может открыть любой процесс в системе независимо от его дескриптора защиты. Например, располагая такой привилегией, можно запустить свою программу, которая открывает процесс LSASS, копирует в ее адресное пространство исполняемый код, а затем внедряет поток с помощью API-функции CreateRemoteThread для выполнения внедренного кода в более привилегированном контексте защиты. Этот код мог бы выдавать пользователю дополнительные привилегии и расширять его членство в группах.
       (o) Take ownership (Смена владельца)*Эта привилегия позволяет ее обладателю сменить владельца любого защищаемого объекта, просто вписав свой SID в поле владельца в дескрипторе защиты объекта. Вспомните, что владелец всегда получает разрешение на чтение и модификацию DACL дескриптора защиты, поэтому процесс с такой привилегией мог бы изменить DACL, чтобы разрешить себе полный доступ к объекту, а затем закрыть объект и вновь открыть его с правами полного доступа. Это позволило бы увидеть любые конфиденциальные данные и даже подменить системные файлы, выполняемые при обычных системных операциях, например LSASS, своими программами, которые расширяют привилегии некоего пользователя.
       (o) Restore files and directories (Восстановление файлов и каталогов)
      Пользователь с такой привилегией может заменить любой файл в системе на свой – так же, как было описано в предыдущем абзаце.
       (o) Load and unload device drivers (Загрузка и выгрузка драйверов устройств)Злоумышленник мог бы воспользоваться этой привилегией для загрузки драйвера устройства в систему. Такие драйверы считаются доверяемыми частями операционной системы, которые выполняются под системной учетной записью, поэтому драйвер мог бы запускать привилегированные программы, назначающие пользователю-злоумышленнику другие права.
       (o)B русской версии Windows XP эта привилегия называется «Овладение файлами или иными объектами». – Прим. перев.
       (o) Create a token object (Создание маркерного объекта)Эта привилегия позволяет создавать объекты «маркеры», представляющие произвольные учетные записи с членством в любых группах и любыми разрешениями.
Конец бесплатного ознакомительного фрагмента.