1. Стандарты защи­щё­нности ос

Наиболее известным стандартом безопасности КС за рубежом является документ, принятый министерством обороны США в 1983 году "Критерии безопасности компьютерных систем", больше известным под название "Оранжевая книга". Защита в нём классифицируется по семи классам D1, C1, C2, B1, B2, B3, A1. Класс D1 – ОС не предусматривающие защиту, класс А1 – ОС имеющая максимальные средства защиты.

В России Гостехкомиссия при Президенте выпустила пять документов, посвящённых вопросам защиты КС. Наиболее важные из них два: "Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищённости от несанкционированного доступа" и "Автоматизированные системы, Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации". Защищённость КС от НСД в первом документе классифицируется по семи классам. Требования этих классов, в основном соответствуют семи классам "Оранжевой книги". Класс 7 соответствует классу D1, класс 1 классу А1. Второй документ касается автоматизированных систем, рассматривая КС как единый программно-ап­па­ратный комплекс. Все автоматизированные системы разделяются в нём на три группы.

Группа 3. Однопользовательские системы.

Классы 3Б, 3А.

Группа 2. Многопользовательские системы, в которых пользователи имеют одинаковые полномочия доступа ко всей информации.

Классы 2Б, 2А.

Группа 1. Многопользовательские системы, в которых пользователи имеют различные полномочия доступа к информации.

Классы 1Д, 1Г, 1В, 1Б, 1А.

21 2121212121212121212121212121212121212121

Архитектура подсистемы аудита Windows NT неявно предполагает совпадение групп администраторов и аудиторов, что заметно снижает защищённость ОС от несанкционированных действий администраторов. Для того, чтобы сделать группу аудиторов отличной от группы администраторов, необходимо выполнить следующие действия:

• создать группу по имени Auditors и добавить в неё всех пользователей-аудиторов;

• сделать владельцем файла журнала аудита одного из аудиторов;

• присвоить файлу журнала аудита дескриптор защиты, содержащий DACL вида

разрешить	Auditors	все права доступа
разрешить	SYSTEM	все права доступа

• предоставить группе Auditors привилегию аудитора и отнять эту привилегию у группы Administrators.

Процессы-серверы

Превышение полномочий пользователя

В любой ОС возникают ситуации, когда пользователь для выполнения некоторых действий должен получить полномочия, недоступные ему в другое время. Например, пользователь должен иметь возможность изменять свой пароль. Для этого он должен получить право доступа к учётной записи в базе паролей, что недопустимо, так как он может изменить и чужие пароли. В UNIX для этой цели используется механизм SUID/SGID, позволяющую пользователю запустить программу от имени другого пользователя.

В Windows NT, если пользователь должен осуществить операцию, для которой у него недостаточно полномочий, он должен запросить услуги одного из процессов-серверов, которые выполняются, обычно, от имени псевдопользователя SYSTEM, обладающего необходимыми полномочиями. В стандартной конфигурации имеются следующие процессы-серверы

• csrss.exe – сервер Win32;

• services.exe – диспетчер сервисов;

• lsass.exe – сервер LSA;

• spoolss.exe – сервер печати;

• smss.exe – диспетчер сеансов.

Все процессы-серверы запускаются при старте ОС. Аварийное завершение сервера приводит к аварийному завершению работы ОС. Большинство системных вызовов, инициируемых приложениями, выполняются процессами-серверами. Этот механизм значительно повышает надёжность ОС, так как прикладные процессы не имеют, в этом случае, доступа к глобальным переменным ОС и не могут вызвать её крах. С другой стороны, архитектура кли­ент-сервер, имеющая место при такой организации ОС заметно ухудшает её производительность.

Так как временное повышение полномочий пользователя осуществляется не путём запуска новой программы, а передачей сообщения процессу, запущенному при старте ОС, исключается возможность превышения полномочий пользователя подменой программных модулей.

Олицетворение пользователей

При обращении приложения к процессу-серверу запрос выполняется с правами псевдопользователя, от имени которого запущен сервер. Однако во многих случаях запрос должен быть выполнен не с полномочиями сервера, а с полномочиями клиента. Для реализации этого механизма NT использует концепцию олицетворения или воплощения (impersonation) пользователя. Она заключается в том, что в контексте процесса, выполняющегося от имени одного пользователя, создаётся поток, выполняющийся от имени другого пользователя.

Подсистема разграничения доступа при определении прав доступа к объекту и привилегий субъекта берёт необходимую информацию из маркера доступа субъекта. Обычно маркер доступа назначается процессу, и все его потоки выполняются с полномочиями, определяемыми этим маркером.

Но маркеры могут назначаться не только процессам, но и отдельным потокам процесса. При олицетворении пользователя одному из потоков процесса-сервера назначается личный маркер доступа, и поток выполняется не с правами пользователя процесса, а с правами пользователя, чей маркер доступа назначен потоку. Назначение маркера доступа конкретному потоку процесса и есть олицетворение пользователя.

Процесс-сервер имеет потоки двух типов – потоки, имеющие свои маркеры доступа, и потоки, не имеющие своих маркеров. Полномочия потоков второго типа определяются маркером доступа, назначенным процессам.

Олицетворение пользователя не требует от пользователя, от имени которого запущен процесс-сервер, никаких специальных привилегий. Единственно, что нужно пользователю – это право назначения маркера доступа и право назначения потоку.

Олицетворение пользователя осуществляет системная функция SetThreadToken, позволяющая назначить любому потоку любой маркер доступа, если, конечно, имеются права доступа к потоку и маркеру доступа. В процессах-серверах используются функции ImpersonateLoggedOnUser, ImpersonateNamePipeClient, DdeImpersonateClient, назначающие маркер доступа текущему потоку. Для завершения олицетворения пользователя текущим потоком используется функция RevertToSelf. Для начала и завершения олицетворения клиента сервером RPC используются соответственно функции RpcImpersonateClient и RpcRevertToSelf.

Механизм олицетворения может так же использоваться приложениями, если необходимо включить некоторую привилегию в одном потоке и оставить её выключенной для остальных потоков процесса. Для этого следует назначить потоку копию маркера, назначенного процессу, и в дальнейшем включить нужную привилегию в этой копии. Эта операция реализуется функцией ImpersonateSelf.

Если поток процесса-сервера, выполняющийся в режиме олицетворения, порождает новый процесс, этому процессу назначается маркер доступа процесса-родителя. Олицетворение пользователя не распространяется на порождаемые процессы.

Когда поток, выполняющийся в режиме олицетворения, выполняет привилегированную операцию, наличие привилегии проверяется с помощью маркера доступа потока. Некоторые привилегии, например, добавление записи в журнал аудита, проверяется относительно маркера доступа процесса, что позволяет процессам-серверам генерировать сообщения аудита, не прерывая олицетворение пользователя.