Безопасность компьютерных систем

Денис Гамаюнов

dgamaunov@hse.ru

Лекция 10: Безопасность операционных систем

Много привилегий у программы – плохо

• Вспомним, что в наших приложениях могут быть ошибки
• Ошибки порчи памяти (C, C++, asm)
• Гонки
• Confused deputy problem

2

By Rogers and Cowan, Beverly Hills - eBayfrontback, Public Domain, �https://commons.wikimedia.org/w/index.php?curid=31434880

3

Принцип наименьших привилегий

• Можно ли минимизировать потенциальный ущерб?
• Идея: разделить приложение на множество процессов в соответствии с потребностями в привилегиях в каждый момент времени

4

Разделение доступа и минимизация привилегий. Compartmentalisation.

5

Дискреционная модель доступа в UNIX

• Principals: UID (32-bit), GID (32-bit)
• Объекты операционной системы
• Атрибуты объекта определяют права доступа к нему:
• чтение, запись, выполнение
• со стороны владельца, группы и остальных пользователей

​

XYZ, где X – права владельца, Y – группы, Z – остальных пользователей.

Каждое из чисел получается сложением битов, указывающих на наличие права: 4 – право на чтение, 2 – на запись, 1 – на выполнение.

​

Альтернативное представление:

–rw– r–– –r– user users data-type0.5.4.txt.html

drwx ––– ––– user users test/

drwx r–x r–x user users todo/

​

• Владелец объекта имеет возможность устанавливать права доступа к объекту по своему усмотрению

​

6

Типовая дискреционная модель доступа в UNIX (2)

• Суперпользователь
• Root (UID = 0)
• Имеет доступ ко всем объектам системы, а так же может менять права доступа к объектам и их владельцев
• Исполнение программ, права программы
• По умолчанию, программа исполняется от имени пользователя, запустившего ее и получает эффективный идентификатор этого пользователя,
• Тем самым программа получает права пользователя, запустившего ее,
• login как начало сеанса работы пользователя в системе
• Иногда требуется, чтобы программа запускалась с правами владельца, а не реального пользователя
• Выполнение специфичных операций
• Атрибут setUID

7

Формальные модели доступа

8

Формальные модели доступа

• Назначение

Формальное выражение политики безопасности

• Основные понятия и определения
• O – объекты системы
• S – субъекты системы
• R – права доступа
• Типы моделей
• Дискреционная (свободная) – Discretionary Access Control,
• Мандатная (нормативная) – Mandatory Access Control

​

9

Дискреционная модель доступа. �Модель Харрисона-Руззо-Ульмана

• Множества:
• объектов (O),
• субъектов (S),
• прав доступа (R)
• Матрица прав доступа M
• ячейка M[s,o] содержит набор {r} прав доступа субъекта s к объекту o
• Состояние системы Q=(S,O,M)
• Эволюция системы во времени через изменение матрицы M

​

10

Дискреционная модель (2)�Эволюция системы во времени

• Модель системы:
• наборы прав доступа, начальных субъектов и объектов,
• начальная матрица доступа
• набор команд С
• Формальный критерий безопасности: Начальное состояние Q является безопасным относительно права r если не существует последовательности команд, добавляющих в ячейку матрицы M право r, изначально отсутствующее в этой ячейке
• Проблема безопасности системы:
• Алгоритмически неразрешима,
• Разрешима при ограничениях на команды из множества C
• Ограничения на команды существенно снижают практическую применимость модели

11

Мандатная модель доступа.�Модель Белла-ЛаПадулы

• Сопоставление субъектам и объектам уровней безопасности
• Наличие двух операций доступа – read и write
• Два простых правила:
• Запрет чтения сверху
• Запрет на запись вниз
• Модель системы: ∑(v,R,T), где T:(V×R)->V – функция переходов
• Понятие безопасности состояния: безопасность по чтению и записи
• Критерий безопасности системы – достижимость только безопасных состояний
• Основная теорема безопасности Белла-ЛаПадула:

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

P.S. Уровень безопасности: число или нечто большее ?

• Уровень допуска + доступные категории

12

Мандатная модель (2)�Модель Биба

• К свойствам конфиденциальности добавляются свойства целостности
• Характеристика целостности
• Либо запрет на общение субъекта и объекта с разным уровнем целостности
• Либо снижение уровня целостности при взаимодействии

​

​

13

Ролевой контроль доступа �(Role Based Access Control)

• Замещение понятия “субъект” понятиями “пользователь” и “роль”
• Идея состоит в том, что полномочиями наделяются не конкретные пользователи, а абстрактные роли
• Ролевая модель:
• U – множество пользователей
• R – множество ролей
• P – множество полномочий на доступ к объектам
• S – множество сеансов пользователей
• Отношение PA – отображает множество полномочий на множество ролей,
• Отношение UA – отображает множество пользователей на множество ролей
• Правила управления доступом определяются функциями:
• user: S->U
• roles: S->R
• permissions : S->P

14

UA

user

roles

PA

Ролевой контроль доступа (2)

• Критерий безопасности:

Система считается безопасной, если любой пользователь системы, работающий в сеансе s, может осуществлять действия, требующие полномочия p, только в том случае, когда p є permissions(s)

• Управление доступом через назначение набора доступных ролей
• Иерархия ролей.
• Различные типы ролевых моделей в зависимости от вида PA, UA, user и roles отражают различные виды распределения полномочий и ответственности:
• Взаимоисключающие роли (статическое разделение обязанностей),
• Ограничения на одновременное использование ролей в рамках одного сеанса (динамическое разделение обязанностей),
• Количественные ограничения на назначение ролей,
• Группирование ролей и полномочий

15

16

Security Enhanced Linux

17

Гранулярный контроль привилегий

Принудительная типизация

• Более строгое разделение доступа между ОС и приложениями
• … и между самими приложениями

18

Архитектура SELinux

• Надстройка над традиционной моделью безопасности UNIX
• Реализует сервер безопасности, который интерпретирует политику безопасности
• Не затрагивает традиционные механизмы безопасности UNIX. Но ключевые программы в ОС заменены, и работают с сервером безопасности напрямую
• Идентификатор SELinux не соответствует стандартному UID в Linux.
• Метки SELinux работают одновременно с традиционной UNIX DAC (и ACL файловых систем)

19

SELinux в схеме контроля доступа

20

Основные понятия SELinux

• Пользователи (users) – идентификаторы для пользователей или классов пользователей
• Классы (class) – типы объектов, т.е. файлов или процессов
• Роли (roles) – списки привилегий, доступных для пользователей, выступающих под конкретными ролями
• Домены (domains) – классификация субъектов
• Типы (types) – классификация объектов (то же самое, что домен, только используется для объектов)

21

Основные понятия SELinux

• Система принимает два основных типа решений
• Контроль доступа: может ли субъект получить доступ к объекту?
• Присвоение меток: какие метки должен иметь новый объект (субъект)?
• Язык спецификаций политики безопасности позволяет описывать разные формальные модели.
• В поставку Linux обычно входит некоторая модель по-умолчанию.

22

Принудительная типизация в SELinux

• Управление доступом реализуется с помощью неструктурированной метки, называемой «типом»
• Для процессов метка называется «доменом»
• Политика определяет правила доступа для доменов и типов
• allow <subject type> �<target type>:<class set> <permission set>
• allow httpd_t http_config_t:file � { read, write };

23

Пользователи, роли и домены

• Пользователи авторизуются в одной или нескольких ролях
• Роли можно менять (команда newrole)
• Роли авторизованы на доступ к доменам

24

Пример

• Пользователь example авторизован в роли sysadm_r
• Роль sysadm_r может исполнять файлы типа httpd_exec_t
• После запуска httpd_exec_t получает домен httpd_t
• Теперь веб-сервер Apache запущен в выделенном домене

25

Пример принудительной типизации

26

Правила принудительной типизации

​

• allow Project1 ProjData:file � { read, write, execute };
• allow ROProject1 ProjData:file { read, execute };
• allow SecretProject1 SecretProj1Data:file � { read, write, execute };
• …

27

Как это работает

• Как разметить данные, чтобы Алиса, Боб и Чарли могли работать над Project1?
• Как должна быть помечена ценная информация проекта Project1?
• Может ли Боб записывать в файлы проекта Project1?

28

Контексты безопасности

• Сущности помечены контекстами безопасности
• Пользователь, Роль, Тип или Домен
• Т.е. Bob:user_r:corporate_t
• Команда “id” выводит информацию о контексте пользователя:
• Зарегистрирован как пользователь Bob в роли user_r в домене corporate_t
• Команда “ls –Z foo” выводит инфомацию о контексте файла:
• Создан пользователем Bob в роли user_r. Член типа corporate_t.

​

29

Контексты безопасности

​

​

root:sysadm_r:example_t

​

• SELinux User ID
• Текущая роль SELinux
• Текущий домен/тип

30

Реализация

Как это сделано

• В оригинале – патч к ядру, сейчас – часть стандартного ядра
• Несколько изменённых приложений (login, ssh, ls, ps, и т.д.)
• Разметка файловой системы контекстами безопасности

(хранятся в расширенных атрибутах ext2/3/4)

• Разметка процессов контекстами безопасности

31

Язык описания политик

• Декларация типа
• type type-name [ alias alias-id ] [, attr-id] ;
• Например, type sshd_t, domain, privuser, privrole;
• Связывает имя типа с набором атрибутов
• Атрибуты – произвольные теги, ассоциированные с именем типа
• Во многих местах атрибуты можно использовать вместо типов
• allow domain unlabeled_t:file { read, write, execute };

32

Переходы между типами

Политика

• определяет разрешённые переходы
• определяет правила автоматических переходов

Ограничения

• Возможны только при exec()
• Никаких переходов в процессе выполнения программы
• Никаких переходов, если внешний код исполняется как модуль

33

Переходы между типами

• Задаём тип вновь создаваемых объектов
• type_transition source_types target_types : classes new_type ;
• Тип source_type это тип (домен) субъекта.
• Тип target_type это тип родительского объекта, например каталога в случае файловой системы
• Например, type_transition sshd_t tmp_t : devfile_class_set cardmsg_dev_t ;
• Когда демон sshd создаёт файл устройства в каталоге tmp, новый файл помечается меткой cardmsg_dev_t
• devfile_class_set – это макрос M4 (info m4)

34

Переходы между типами: пример

• Удалённая регистрация (ssh)
• Автоматический переход в роль и тип по-умолчанию, как только sshd запускает оболочку
• Выполнение программы, для которой определён домен (screen)
• На время выполнения этой программы переход в её домен

35

Правила доступа

• Доступ доменов к типом задаётся правилами:
• (allow | auditallow | dontaudit) src_type target_type : classes permissions;
• Когда субъект из домена src_type обращается к объекту типа target_type, он получает заданный набор привилегий, если объект в одном из заданных классов
• Например:

allow sshd_t shell_exec_t : file execute;

36

Синтаксис описания ролей

• Определение роли
• role name type type_set ;
• Определяет домены (типы) для роли
• Например, role staff_r type staff_t;
• Список разрешённых изменений ролей
• allow current_role new_role ;
• Например, allow staff_t sysadm_t ;
• Если не задано, то роль нельзя изменить

37

Переходы доменов

• По-умолчанию процесс наследует домен процесса-родителя
• Для задания доменных переходов можно описывать правила:
• type_transition d1 d2:process f1
• Плюс правила для доступа между всеми тремя типами

38

Проблемы политики принудительной типизации

• Явно описанная политика обладает большой выразительностью, но…
• Политики становятся очень большими
• 150,000 правил в целевой политике SELinux после выполнения макроподстановок
• Язык описания богатый, но слишком низкоуровневый
• Для описания модульных программ нужны макросы
• Средства анализа работают уже после макроподстановки

39

Достоинства

Роли и домены:

• Домены можно сделать полностью раздельными
• Роли соответствуют принципу наименьших привилегий
• Успешная эксплуатация уязвимостей не ломает всю систему
• ...даже если скомпрометирован пользователь root
• Недоверенный код можно заключить в «контейнер»

40

Достоинства

Пример реализации RBAC

• Четыре роли
• Разделение обязанностей
• Перекрываются где необходимо
• Могут переключать роли –DBA и WebAdmin могут быть одним и тем же человеком

​

41

Достоинства

Политика SELinux и её выполнение:

• Высокая гранулярность контроля доступа - на уровне системных вызовов
• Даже небольшие нарушения можно заметить
• Управление политикой, а не действиями пользователей
• Минимизация ущерба
• Заставляет пользователей следовать общей политике (нельзя обойти)

42

Мандатный доступ (MLS) в SELinux

• Дополнительный механизм, который может работать параллельно принудительной типизации
• Помечает каждый контекст безопасности меткой уровня чувствительности
• Метка чувствительности принимает один из 16 уровней допуска и подмножество из 256 «ячеек»
• Bob:user_r:corporate_t:s0_c0,c5,c10

​

43

Мандатный доступ (MLS) в SELinux

• Усиливает язык описания принудительной типизации возможностью описывать правила модели Белла-Лападулы (BLP)
• Добавлено выражение mlsconstrain – логический предикат над пользователями, ролями, типами, уровнями и т.д.
• mlsconstrain { dir file lnk_file } { read getattr execute }� (( l1 dom l2 ) or� (( t1 == mlsfilereadtoclr ) � and ( h1 dom l2 )) or� ( t1 == mlsfileread ) or� ( t2 == mlstrustedobject ));

44

SELinux resume

• SELinux позволяет реализовать несколько механизмов контроля доступа
• Принудительная типизация и мандатный контроль доступа
• Политика SELinux может быть достаточно сложной
• Как только создана и проверена сложная политика мандатного доступа, пользователь не может её обойти

Capsicum

45

Robert N. M. Watson, Jonathan Anderson

University of Cambridge

Ben Laurie, Kris Kennaway

Google UK Ltd.

In proceedings of the 19th USENIX Security Symposium

Capability

• Capabilities это устойчивые к подделке авторизационные токены на доступ к конкретному объекту
• Provably Secure Operating System (PSOS)
• Extremely Reliable Operating System (EROS)

46

Архитектура Capsicum

• Capsicum extends standard UNIX APIs by adding kernel-level primitives and userspace support code

47

Capability Mode

• Capability mode is a process credential flag set by a new system call, cap_enter; once set, the flag is inherited by all descendent processes, and cannot be cleared.

​

• Processes in capability mode are denied access to global namespaces.

​

48

Capability Mode

49

Capability Mode

• Access to system calls in capability mode is also restricted.
• sysctl - can be used to query process-local information
• marking ～30 of 3000 parametersas permitted in capability mode
• openat family of system calls
• Accept a file descriptor argument
• they are constrained so that they can only operate on objects “under” this descriptor

50

Capabilities

• we chose to extend the file descriptor abstraction, and introduce a new file descriptor type, the capability

​

• The cap_new system call creates a new capability given an existing file descriptor and a mask of rights
• roughly 60 possible mask
• striking a balance between message-passing (two rights: send and receive), and MAC systems (hundreds of access control checks)

51

Capabilities

52

Run-time Environment

• Even with Capsicum’s kernel primitives, creating sandboxes without leaking undesired resources is difficult.

​

• libcapsicum therefore provides an API for starting scrubbed sandbox processes, and explicit delegation APIs to assign rights to sandboxes.

53

Adapting Applications

• In Capsicum, programmers have a choice of working directly with capability mode or using libcapsicum to create and manage sandboxes.
• use cap_enter directly in order to convert an existing process with ambient privilege into a capability mode process
• Use cap_enter to reinforce the sandboxes of applications with existing privilege separation or compartmentalisation.
• Modify the application to use the full libcapsicum API.

54

tcpdump

• tcpdump has a simple model
• compile a pattern into a BPF filter, configure a BPF device as an input source, and loop writing captured packets rendered as text.

55

tcpdump

• Unconstrained access to a user’s terminal connotes significant rights, such as access to key presses
• So……a refinement

56

Chromium

• Each tab is associated with a renderer process that performs the risky and complex task of rendering page contents[link]
• the existing compartmentalisation meant that several critical tasks had already been performed
• Processes can be converted into sandboxes that limit new object access
• Certain services were already forwarded to renderers
• Shared memory is used to transfer output between renderers and the web browser
• Chromium contains RPC marshalling and passing code

57

Chromium

58

Chromium

• Approximately 100 additional lines of code were required to introduce calls to lc_limitfd to limit access to file descriptors.
• the 4.3 million lines of code in the Chromium source tree

59

Comparison of �Sandboxing Technologies

60

DAC

MAC

Capability

Linux chroot

• Access to the filesystem is limited to a directory via chroot

​

• Access to other namespaces, including System V shared memory and network access, is unconstrained, and great care must be taken to avoid leaking resources when entering the sandbox

61

MAC OS X Seatbelt

• The rights that are granted to render processes are still very broad, and security policy must be specified separately from the code that relies on it.

62

SELinux

• SELinux can be used for very fine-grained rights assignment, but in practice, broad rights are conferred because fine-grained Type Enforcement policies are difficult to write and maintain.

63

Linux seccomp

• Linux provides an optionally-compiled capability mode like facility called seccomp.

​

• Processes in seccomp mode are denied access to all system calls except read, write, and exit.

​

• But as OS infrastructure to support applications using seccomp is minimal, application writers must go to significant effort to use it

64

Linux seccomp

• Chromium constructs a process in which one thread executes in seccomp mode, and another “trusted” thread sharing the same address space has normal system call access.

​

• The Chromium seccomp sandbox contains over a thousand lines of hand-crafted assembly

​

​

65