Модель разграничения доступа.

В ОС Windows реализована модель ролевого доступа, она не позволяет формально обосновать безопасность приложений в ряде случаев, представляющих практический интерес. С каждым процессом или потоком, то есть, активным компонентом (субъектом), связан маркер доступа, а у каждого защищаемого объекта (например, файла) имеется дескриптор защиты. Проверка прав доступа обычно осуществляется в момент открытия объекта и заключается в сопоставлении прав субъекта списку прав доступа, который хранится в составе дескриптора защиты объекта.

Другая возможность, предоставляемая ОС Windows - управление ролевым, в частности привилегированным доступом. Ролевая политика предназначена в первую очередь для упрощения администрирования информационных систем с большим числом пользователей и различных ресурсов. В ролевой политике управление доступом осуществляется с помощью правил. Вначале для каждой роли указывается набор привилегий по отношению к системе и полномочий, представляющих набор прав доступа к объектам, и уже затем каждому пользователю назначается список доступных ему ролей. Классическое понятие субъект замещается понятиями пользователь и роль. Примером роли является присутствующая почти в каждой системе роль суперпользователя (группа Administrator для ОС Windows). Количество ролей обычно не соответствует количеству реальных пользователей - один пользователь может выполнять несколько ролей, и наоборот, несколько пользователей могут в рамках одной и той же роли выполнять типовую работу. Таким образом, в рамках ролевой модели формируются близкие к реальной жизни правила контроля доступа и ограничения, соблюдение которых и служит критерием безопасности системы. Однако, как и в случае дискреционной модели, ролевая политика безопасности не гарантирует безопасность с помощью формальных доказательств.

Проблемами безопасности модели разграничения доступа в Windows являются пользователи с возможностью «овладевания» объектов, а также пользователи являющиеся агентами архивации и восстановления.

Права, привилегии, суперпривилегии и вход пользователей в ОС семейства Windows NT.

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

При входе через терминал или при обращении к сети не происходит обращение к какому-либо объекту, так как пользователю в системе ещё ничего не принадлежит. Соответственно, для этого пользователя должны быть указаны какие-то права доступа именно к компьютеру. Они регламентируют способы, которыми пользователи попадают в систему, и возможность доступа в систему (для Windows XP):

– интерактивный вход – разрешен ли вход через терминал;

– сетевой вход – разрешен ли вход через сеть. То есть, может ли быть сформирован маркер безопасности на основании данных из сети;

– вход через клиент службы терминалов;

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

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

Права парные (разрешение и запрет). Например, право на вход через терминал и запрет на вход в терминал. Эти права проверяет lsas при аутентификации пользователя. Они регламентируют вход в систему. Но, они не содержатся в маркере доступа.

Привилегии

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

Привилегия (privilege) – это право (right) учетной записи на выполнение определенной операции. Право учетной записи разрешает или запрещает конкретный тип входа в систему, скажем, локальный или интерактивный.

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

Несколько привилегий дают настолько широкие права (суперпривилегии), что пользователя, которому они назначаются, называют «суперпользователем» – он получает полный контроль над компьютером. Эти привилегии позволяют получать неавторизованный доступ к закрытым ресурсам и выполнять любые операции.

Будет время перепиши ↑

· Debug programs (Отладка программ). Пользователь с этой привилегией может открыть любой процесс в системе независимо от его дескриптора защиты.

· Take ownership (Смена владельца). Эта привилегия позволяет ее обладателю сменить владельца любого защищаемого объекта, просто вписав свой SID в поле владельца в дескрипторе защиты объекта.

· Restore files and directories (Восстановление файлов и каталогов). Пользователь с такой привилегией может заменить любой файл в системе на свой.

· Load and unload device drivers (Загрузка и выгрузка драйверов устройств). Злоумышленник мог бы воспользоваться этой привилегией для загрузки драйвера устройства в систему. Такие драйверы считаются доверяемыми частями операционной системы, которые выполняются под системной учетной записью (в русской версии Windows XP эта привилегия называется «Овладение файлами или иными объектами»).

· Create a token object (Создание маркерного объекта). Эта привилегия позволяет создавать объекты «маркеры», представляющие произвольные учетные записи с членством в любых группах и любыми разрешениями.

· Act as part of operating system (Работа в режиме операционной системы). Эта привилегия применяется для установления доверяемого соединения с LSASS. B итоге можно было бы использовать свои имя и пароль для создания нового сеанса входа, в маркер которого включены SID более привилегированных групп или пользователей (расширенные привилегии не распространяются за границы локальной системы в сети, потому что любое взаимодействие с другим компьютером требует аутентификации контроллером домена и применения доменных паролей).

 

Этапы входа пользователя

Регистрация начинается, когда пользователь нажимает комбинацию клавиш SAS (по умолчанию – Ctrl+Alt+Del). После этого Winlogon вызывает GINA, чтобы получить имя и пароль пользователя. Winlogon также создает уникальный локальный SID для этого пользователя и назначает его данному экземпляру объекта «рабочий стол» (который представляет клавиатуру, экран и мышь). Winlogon передает этот SID в LSASS. Если вход пользователя прошел успешно, этот SID будет включен в маркер процесса входа (logon process token) – такой шаг предпринимается для защиты доступа к объекту «рабочий стол». Например, второй вход по той же учетной записи, но в другой системе, не предоставит доступа для записи к объекту «рабочий стол» первого компьютера, так как в его маркере не будет SID, полученного при втором входе.

После ввода имени и пароля пользователя Winlogon получает описатель пакета аутентификации. Эти пакеты перечисляются в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Winlogon передает пакету данные входа. После того как пакет аутентифицирует пользователя, Winlogon продолжает процесс входа этого пользователя. Если ни один из пакетов не сообщает об успешной аутентификации, процесс входа прекращается.

Windows использует два стандартных пакета аутентификации при интерактивном входе: Kerberos и MSV1_0. Пакет аутентификации по умолчанию в автономной системе Windows – MSVlO (\Windows\System32\Msvl_0.dll); он реализует протокол LAN Manager 2. LSASS также использует MSVlO на компьютерах, входящих в домен, чтобы аутентифицировать домены и компьютеры под управлением версий Windows до Windows 2000, не способные найти контроллер домена для аутентификации (Отключенные от сети портативные компьютеры относятся к той же категории.). Пакет аутентификации Kerberos (\Windows\System32\Kerberos.dll) используется на компьютерах, входящих в домены Windows. Этот пакет во взаимодействии со службами Kerberos, выполняемыми на контроллере домена, поддерживает протокол Kerberos версии 5 (ревизии 6). Данный протокол определен в RFC 1510.

Пакет аутентификации MSVIO принимает имя пользователя и хешированную версию пароля и посылает локальному SAM запрос на получение информации из учетной записи, включая пароль, группы, в которые входит пользователь, и список ограничений по данной учетной записи. Сначала MSVIO проверяет ограничения, например разрешенное время или типы доступа. Если ограничения из базы данных SAM запрещают регистрацию пользователя в это время суток, MSVIO возвращает LSA статус отказа.

Далее MSVIO сравнивает хэшированный пароль и имя пользователя с теми, которые хранятся в SAM. B случае кэшированного доменного входа MSVIO обращается к кэшированной информации через функции LSASS, отвечающие за сохранение и получение «секретов» из базы данных LSA (куст реестра SECURITY) Если эти данные совпадают, MSVIO генерирует LUID сеанса входа и создает собственно сеанс входа вызовом LSASS. При этом MSVIO сопоставляет данный уникальный идентификатор с сеансом и передает данные, необходимые для того, чтобы в конечном счете создать маркер доступа для пользователя.

Если MSV1_0 нужно аутентифицировать пользователя с удаленной системы, например при его регистрации в доверяемом домене под управлением версий Windows до Windows 2000, то MSV1_0 взаимодействует с экземпляром Netlogon в удаленной системе через службу Netlogon (сетевого входа в систему). Netlogon в удаленной системе взаимодействует с пакетом аутентификации MSV1_0 этой системы, передавая результаты аутентификации системе, в которой выполняется вход.

Базовая последовательность действий при аутентификации Kerberos в основном та же, что и в случае MSV1_0. Однако в большинстве случаев доменный вход проходит на рабочих станциях или серверах, включенных в домен (а не на контроллере домена), поэтому пакет в процессе аутентификации должен взаимодействовать с ними через сеть. Взаимодействие этого пакета со службой Kerberos на контроллере домена осуществляется через TCP/IP-порт Kerberos (88). Служба Kerberos Key Distribution Center (\Windows\ System32\Kdcsvc.dll), реализующая протокол аутентификации Kerberos, выполняется в процессе Lsass на контроллерах домена.

После проверки хэшированной информации об имени и пароле пользователя с помощью объектов учетных записей пользователей (user account objects) Active Directory (через сервер Active Directory, \Windows\System32\ Ntdsa.dll) Kdcsvc возвращает доменные удостоверения LSASS, который при успешном входе передает через сеть результат аутентификации и удостоверения пользователя той системе, где выполняется вход.

Как только учетные данные аутентифицированы, LSASS ищет в базе данных локальной политики разрешенный пользователю тип доступа – интерактивный, сетевой, пакетный или сервисный. Если тип запрошенного входа в систему не соответствует разрешенному, вход прекращается. LSASS удаляет только что созданный сеанс входа, освобождая его структуры данных, и сообщает Winlogon о неудаче. Winlogon в свою очередь сообщает об этом пользователю. Если же запрошенный тип входа в систему разрешается, LSASS добавляет любые дополнительные идентификаторы защиты (например, Everyone, Interactive и т. п.). Затем он проверяет в своей базе данных привилегии, назначенные всем идентификаторам данного пользователя, и включает эти привилегии в маркер доступа пользователя.

Собрав всю необходимую информацию, LSASS вызывает исполнительную систему для создания маркера доступа. Исполнительная система создает основной маркер доступа для интерактивного или сервисного сеанса и маркер олицетворения для сетевого сеанса. После успешного создания маркера доступа LSASS дублирует его, создавая описатель, который может быть передан Winlogon, а свой описатель закрывает. Если нужно, проводится аудит операции входа. На этом этапе LSASS сообщает Winlogon об успешном входе и возвращает описатель маркера доступа, LUID сеанса входа и информацию из профиля, полученную от пакета аутентификации (если она есть).

33. Компоненты системы защиты, модель разграничения доступа и способности в операционных системах семейства Linux.

Защита ОС семейства UNIX в общем случае базируется на 3-х основных механизмах:

– идентификация и аутентификация пользователя при входе в систему;

– разграничение прав доступа к файловой системе, в основе которого лежит реализация дискреционной модели доступа;

– аудит, то есть регистрация событий.

У каждого пользователя системы имеется:

– ID пользователя – Имя пользователя;

– Хеш-свертка в файле паролей;

– UID.

При входе в систему на основании ID и AU процессу пользователя присваивается UID. У встроенного пользователя «root» UID = 0. Проверка прав доступа для процессов с UID=0 не осуществляется.

При этом отметим, что для различных клонов ОС семейства UNIX возможности механизмов защиты могут незначительно различаться, однако будем рассматривать ОС UNIX в общем случае, без учета некоторых незначительных особенностей отдельных ОС этого семейства.

В ОС Linux низкоуровневые методы аутентификации интегрируются в виде единого высокоуровневого API, представляющего собой набор разделяемых библиотек (PAM, подключаемые модули аутентификации). Данная технология позволяет предоставить единые механизмы для управления, встраивания прикладных программ в процессе аутентификации.

Для обеспечения поддержки различных моделей информационной безопасности, в ОС Linux реализуется технология LSM(Linux Security Modules). Данная технология является стандартной частью ядра Linux выше версии 2.6.LSM разрабатывалась для возможности реализации мандатной модели доступа в операционных системах Linux.

Построение файловой системы и разграничение доступа к файловым объектам имеет особенности, присущие данному семейству ОС. Рассмотрим кратко эти особенности. Все дисковые накопители (тома) объединяются в единую ВИРТУАЛЬНУЮ ФАЙЛОВУЮ СИСТЕМУ путем операции монтирования тома. При этом содержимое тома проецируется на выбранный каталог файловой системы. Элементами файловой системы являются также все устройства, подключаемые к защищаемому компьютеру (монтируемые к файловой системе). Поэтому разграничение доступа к ним осуществляется через файловою систему.

Каждый файловый объект имеет индексный дескриптор (описатель), в котором среди прочего хранится информация о разграничении доступа к данному файловому объекту. Права доступа делятся на три категории: доступ для владельца, доступ для группы и доступ для остальных пользователей. В каждой категории определяются права на чтение, запись и исполнение (в случае каталога — просмотр).

Пользователь имеет уникальные символьный идентификатор (имя) и числовой идентификатор (UID). Символьный идентификатор предъявляется пользователем при входе в систему, числовой используется операционной системой для определения прав пользователя в системе (доступ к файлам и т.д.).

В Linux для каждого файла (все ресурсы в ОС Linux представимы в виде файлов, в том числе устройства ввода-вывода) устанавливаются разрешения доступа для трех категорий субъектов: владелец файла, члены той же группы, что и владелец, и все остальные пользователи. Для каждой из этих категорий устанавливаются права на чтение (r), запись (w) и выполнение (x). Набор прав доступа объекта может быть представлен в виде символьной строки. Например, запись «rwxr-xr--» означает, что владелец файла может делать с ним все, что угодно; члены его группы могут читать и исполнять файл, но не могут записывать, а прочим пользователям доступно только чтение.

В рамках модели разграничения доступа Linux контролируется доступ субъектов (пользователей или приложений) к объектам (представляющим собой различные информационные ресурсы: файлы, приложения, устройства вывода и т.д.).

Для каждого объекта существует субъект-владелец, который сам определяет тех, кто имеет доступ к объекту, а также разрешенные операции доступа. Основными операциями доступа являются READ (чтение), WRITE (запись) и EXECUTE (выполнение, имеет смысл только для программ). Таким образом, в модели дискреционного доступа для каждой пары субъект-объект устанавливается набор разрешенных операций доступа. При запросе доступа к объекту, система ищет субъекта в списке прав доступа объекта и разрешает доступ если субъект присутствует в списке и разрешенный тип доступа включает требуемый тип. Иначе доступ не предоставляется. Классическая система дискреционного контроля доступа является «закрытой» в том смысле, что изначально объект не доступен никому, и в списке прав доступа описывается набор разрешений. Также существуют «открытые» системы, в которых по умолчанию все имеют полный доступ к объектам, а в списке доступа описывается набор ограничений.

Однако в Linux не в полном объеме реализуется дискреционная модель доступа, в частности не могут разграничиваться права доступа для пользователя «root» (UID = 0). Т.е. данный субъект доступа исключается из схемы управления доступом к ресурсам. Соответственно все запускаемые им процессы имеют неограниченный доступ к защищаемым ресурсам. Как мы увидим позднее, с этим недостатком системы защиты связано множество атак, в частности:

- несанкционированное получение прав root;

- запуск с правами root собственного исполняемого файла (локально либо удаленно внедренного). При этом несанкционированная программа получает полный доступ к защищаемым ресурсам и т.д.

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

В основном, Linux-приложения записывают журнальную информацию в файлы, находящиеся в каталоге /var/log, а отдельные дистрибутивы используют для этого каталог /var/adm. Большинство журнальных файлов – это обычные текстовые файлы, в которые записываются сообщения о тех или иных событиях, происходящих в системе. Важно различать журнальную регистрацию на уровне ядра, на этапе начальной загрузки (журналы стартовых скриптов) и журналы демонов. Сообщения, генерируемые ядром, обрабатываются демоном klogd. Демон может или просто создать образ журнального буфера ядра и завершить работу, или динамически извлекать сообщения из буфера по мере их появления и записывать их в файл.

Регистрацией сообщений стартовых скриптов в отдельных системах занимается программа initlog.

Утилита, которая присутствует практически во всех дистрибутивах Linux и занимается журнальной ротаций, называется logrotate.

Способности процесса.

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