Методические указания к лабораторным работам по курсу «Методы и средства защиты компьютерной информации» Волгоград 2011 (стр. 2 из 5)
whoami /user /sid
Соответствие имени пользователя и его SID можно отследить также в ключе реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ ProfileList.
После аутентификации пользователя процессом Winlogon, все процессы, запущенные от имени этого пользователя будут идентифицироваться специальным объектом, называемым маркером доступа (access token). Если процесс пользователя запускает дочерний процесс, то его маркер наследуются, поэтому маркер доступа олицетворяет пользователя для системы в каждом запущенном от его имени процессе. Основные элементы маркера представлены на рис. 1.
| SID пользователя | SID1 … SIDn Идентификаторы групп пользователя | DACL по умолчанию | Привилегии | Прочие параметры |
Рисунок 1. Обобщенная структура маркера доступа.
Маркер доступа содержит идентификатор доступа самого пользователя и всех групп, в которые он включен. В маркер включен также DACL по умолчанию - первоначальный список прав доступа, который присоединяется к создаваемым пользователем объектам. Еще одна важная для определения прав пользователя в системе часть маркера – список его привилегий. Привилегии - это права доверенного объекта на совершение каких-либо действий по отношению ко всей системе. В таблице 2 перечислены некоторые привилегии, которые могут быть предоставлены пользователю.
Таблица 2. Привилегии, которыми могут быть наделены пользователи
| Имя и идентификатор привилегии | Описание привилегии |
| Увеличение приоритета диспетчирования SeIncreaseBasePriorityPrivilege | Пользователь, обладающий данной привилегией может изменять приоритет диспетчирования процесса с помощью интерфейса Диспетчера задач |
| Закрепление страниц в памяти SeLockMemoryPrivilege | Процесс получает возможность хранить данные в физической памяти, не прибегая к кэшированию данных в виртуальной памяти на диске. |
| Управление аудитом и журналом безопасности SeAuditPrivilege | Пользователь получает возможность указывать параметры аудита доступа к объекту для отдельных ресурсов, таких как файлы, объекты Active Directory и разделы реестра. |
| Овладение файлами или иными объектами SeTakeOwnershipPrivilege | Пользователь получает возможность становиться владельцем любых объектов безопасности системы, включая объекты Active Directory, файлы и папки NTFS, принтеры, разделы реестра, службы, процессы и потоки |
| Завершение работы системы SeShutdownPrivilege | Пользователь получает возможность завершать работу операционной системы на локальном компьютере |
| Обход перекрестной проверки SeChangeNotifyPrivilege | Используется для обхода проверки разрешений для промежуточных каталогов при проходе многоуровневых каталогов |
Управление привилегиями пользователей осуществляется в оснастке «Групповая политика», раздел Конфигурация Windows/Локальные политики/Назначение прав пользователя.
Чтобы посмотреть привилегии пользователя, можно также использовать команду
whoami /all
Остальные параметры маркера носят информационный характер и определяют, например, какая подсистема создала маркер, уникальный идентификатор маркера, время его действия. Необходимо также отметить возможность создания ограниченных маркеров (restricted token), которые отличаются от обычных тем, что из них удаляются некоторые привилегии и его SID-идетификаторы проверяются только на запрещающие правила. Создать ограниченный маркер можно программно, используя API-функцию CreateRestrictedToken, а можно запустить процесс с ограниченным маркером, используя пункт контекстного меню Windows “Запуск от имени…” и отметив пункт “Защитить компьютер от несанкционированных действий этой программы” (рис.2).
Рисунок 2. Запуск процесса с ограниченным маркером
Ограниченные маркеры используются для процессов, подменяющих клиента и выполняющих небезопасный код.
Маркер доступа может быть создан не только при первоначальном входе пользователя в систему. Windows предоставляет возможность запуска процессов от имени других пользователей, создавая для этих процессов соответствующий маркер. Для этих целей можно использовать:
- API-функции CreateProcessAsUser, CreateProcessWithLogon;
- оконный интерфейс (рис.2), инициализирующийся при выборе пункта контекстного меню “Запуск от имени…”;
- консольную команду runas:
runas /user:имя_пользователя program ,
где имя_пользователя - имя учетной записи пользователя, которая будет использована для запуска программы в формате пользователь@домен или домен\пользова-тель;
program – команда или программа, которая будет запущена с помощью учетной записи, указанной в параметре /user.
В любом варианте запуска процесса от имени другой учетной записи необходимо задать ее пароль.
1.3. Защита объектов системы.
Маркер доступа идентифицирует субъектов-пользователей системы. С другой стороны, каждый объект системы, требующий защиты, содержит описание прав доступа к нему пользователей. Для этих целей используется дескриптор безопасности (Security Descriptor, SD). Каждому объекту системы, включая файлы, принтеры, сетевые службы, контейнеры Active Directory и другие, присваивается дескриптор безопасности, который определяет права доступа к объекту и содержит следующие основные атрибуты (рис.3):
- SID владельца, идентифицирующий учетную запись пользователя-владельца объекта;
- пользовательский список управления доступом (Discretionary Access Control List, DACL), который позволяет отслеживать права и ограничения, установленные владельцем данного объекта. DACL может быть изменен пользователем, который указан как текущий владелец объекта.
- системный список управления доступом (System Access Control List, SACL), определяющий перечень действий над объектом, подлежащих аудиту;
- флаги, задающие атрибуты объекта.
Авторизация Windows основана на сопоставлении маркера доступа субъекта с дескриптором безопасности объекта. Управляя свойствами объекта, администраторы могут устанавливать разрешения, назначать право владения и отслеживать доступ пользователей.
Список управления доступом содержит набор элементов (Access Control Entries, ACE). В DACL каждый ACE состоит из четырех частей: в первой указываются пользователи или группы, к которым относится данная запись, во второй – права доступа, а третья информирует о том, предоставляются эти права или отбираются. Четвертая часть представляет собой набор флагов, определяющих, как данная запись будет наследоваться вложенными объектами (актуально, например, для папок файловой системы, разделов реестра).
Если список ACE в DACL пуст, к нему нет доступа ни у одного пользователя (только у владельца на изменение DACL). Если отсутствует сам DACL в SD объекта – полный доступ к нему имеют все пользователи.
Если какой-либо поток запросил доступ к объекту, подсистема SRM осуществляет проверку прав пользователя, запустившего поток, на данный объект, просматривая его список DACL. Проверка осуществляется до появления разрешающих прав на все запрошенные операции. Если встретится запрещающее правило хотя бы на одну запрошенную операцию, доступ не будет предоставлен.
Рассмотрим пример на рис.4. Процесс пытается получить доступ к объекту с заданным DACL. В маркере процесса указаны SID запустившего его пользователя, а также SID групп, в которые он входит. В списке DACL объекта присутствуют разрешающие правила на чтение для пользователя с SID=100, и на запись для группы с SID=205. Однако, в доступе пользователю будет отказано, поскольку раньше встречается запрещающее запись правило для группы с SID=201.
Необходимо отметить, что запрещающее правило помещено в списке DACL на рисунке не случайно. Запрещающие правила всегда размещаются перед разрешающими, то есть являются доминирующими при проверке прав доступа.
Для определения и просмотра прав доступа пользователей к ресурсам можно использовать как графические средства контроля, так и консольные команды. Стандартное окно свойств объекта файловой системы (диска, папки, файла) на вкладке Безопасность (рис. 5) позволяет просмотреть текущие разрешения для пользователей и групп пользователей, редактировать их, создавать новые или удалять существующие.
При определении прав доступа к объектам можно задать правила их наследования в дочерних контейнерах. В окне дополнительных параметров безопасности на вкладке Разрешения при выборе опции «Наследовать от родительского объекта применимых к дочерним объектам разрешения, добавляя их к явно заданным в этом окне» (рис. 6) можно унаследовать разрешения и ограничения, заданные для родительского контейнера, текущему объекту.
При выборе опции «Заменить разрешения для всех дочерних объектов заданными здесь разрешениями, применимыми к дочерним объектам» разрешается передача определенных для объекта-контейнера правил доступа его дочерним объектам.
В этом же окне на вкладке Владелец допустимо узнать владельца объекта и заменить его. Владелец объекта имеет право на изменение списка его DACL, даже если к нему запрещен любой тип доступа. Администратор имеет право становиться владельцем любого объекта.
С учетом возможности вхождения пользователя в различные группы и независимости определения прав доступа к объектам для групп и пользователей, зачастую бывает сложно определить конечные права пользователя на доступ к объекту: требуется просмотреть запрещающие правила, определенные для самого объекта, для всех групп, в которые он включен, затем то же проделать для разрешающих правил. Автоматизировать процесс определения разрешенных пользователю видов доступа к объекту можно с использованием вкладки «Действующие разрешения» окна дополнительных параметров безопасности объекта (рис. 7).