Локальная безопасность:от DAC до MAC

МФТИ Алексей Васюков 29/09/2011 v1.0

Что будет сегодня

● Рассказ:● Очень коротко о банальном — пользователи, группы,

процессы, файлы, ACL● Когда банального недостаточно — как работает MAC

● Обсуждение:● Реалии жизни — взлом kernel.org

● Практика (самостоятельно):● Вопросы на подумать и лабы на поделать

DAC: факты коротко (1/2)

● Все в Linux делится на процессы и файлы● Что не файл — то процесс. И наоборот.

● Есть пользователи и группы● И то, и другое — на самом деле число (uid/gid)● Есть зарезервированные диапазоны id'ов

● Любой процесс имеет владельца● Любой файл имеет владельца и группу

владельца

DAC: факты коротко (2/2)

● Права доступа в DAC:● RWX RWX RWX + специальные биты

● ACL в DAC:● Возможность задать права для отдельных

пользователей и групп (те же rwx, но гибче)– user::rw-

– user:ventura:r--

– user:bob:rw-

– group::rw-

– group:physics:rw-

– mask::rw-

– other::--

DAC: утилиты и файлы (1/2)

● Работа с пользователями и группами:● useradd / userdel / usermod● groupadd / groupdel / groupmod

● Работа с паролями● passwd / chage

● Основные файлы● /etc/passwd /etc/shadow /etc/group /etc/shells

DAC: утилиты и файлы (2/2)

● Основные утилиты для задания прав:● chmod / chown / chgrp● umask

● Работа с ACL:● getfacl / setfacl● Не забываем опцию acl при монтировании● Не забываем про поведение утилит (яркий пример — tar

не поддерживает acl)

Проблема DAC

● Представьте — система взломана:● Существуют незакрытые 0-day уязвимости● Бывают успешные брутфорсы паролей● Бывают ошибки людей● ... Мир вообще несовершенен

● Проблема DAC — негибкое задание прав:● Если вы получили user shell — вам можно очень многое● Если вы получили root shell — вам можно всё

Идеология MAC

● Принцип минимума привилегий — каждый процесс имеет права только на то, что ему реально необходимо.

● Если программа только слушает и отвечает на порту — зачем ей вообще возможность доступа к файлам?

● Даже если вы root и вам можно всё, какого чёрта ваш видеоплеер пытается читать /etc/shadow?

DAC и MAC

SELinux: реализация MAC (1/3)

● Существует контекст субъекта (процесса) и объекта (файла)

● Есть политика, задающая разрешения:● Обеспечивается ядром. Даёт атрибуты безопасности на

уровне процессов и файлов и на уровне структур ядра.● Обеспечивает контроль на уровне системных вызовов● Включает в себя описание разрешённых переходов

между контекстами● Все что не разрешено, то запрещено — принцип

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

SELinux: реализация MAC (2/3)Схема работы Место в системе

SELinux: реализация MAC (3/3)

● Политика «разрезает» систему на домены безопасности

● Если взломано отдельное приложение — атакующий ограничен его правами и не может их повысить

● Можно ограничить недоверенные приложения● Политика задано жёстко и поддерживается ядром —

пользователь не может случайно или злонамеренно раскрыть данные, к которым имеет доступ

● DAC и MAC работают независимо● MAC не может разрешить то, что запрещено DAC.● Можно ограничить права root (!)

Работа с SELinux: основы

● Режимы:● Enforcing / Permissive / Disabled

● Утилиты:● Стандартные с ключом -Z — учитывают контекст

SELinux● system-config-selinux — настройка основных параметров● chcon — изменение контекста

● Политики:● Targeted — сетевые сервисы вынесены в изолированные домены,

остальная система не тронута — используется в реальной жизни, более-менее универсальна

● MCS / MLS — паранойя в полный рост, обычно уникальна для каждой системы и пишется отдельно

Работа с SELinux: пример логов

● SELinux блокирует приложение:Oct 25 11:53:28 localahost kernel:

audit(1098719608.033:0): avc: denied

{ getattr } for pid=6762 exe=/usr/sbin/httpd

path=/home/user/public_html dev=dm-0

ino=11897405

scontext=root:system_r:httpd_t

tcontext=user_u:object_r:user_home_t

tclass=dir

SELinux и веб-сервер

● Что нужно веб-серверу:● Слушать порт 80 на eth0● Читать /etc/httpd/httpd.conf● Читать и дополнять /var/log/httpd/*● Читать /var/www/html/*

● Атакующий получит не больше:

Без SELinux С SELinux

Из жизни: защита веб-сервера (1/4)

● Что есть и что хочется:● Несколько пользователей веб-сервера (виртуальные

хосты)● Пользователи запускают свои скрипты● Если использовать suexec — скрипты запускаются из-

под пользователей● Необходима изоляция пользователей● Необходимо защитить данные пользователей от

небезопасных скриптов● Необходимо защитить систему от пользователей

● Применяем SELinux:● Задаём домен для веб-сервера (httpd_t) и отдельный

домен для скриптов пользователей (httpd_user_script_t)● Задаём типы для веб-контента:

– httpd_sys_content_t, httpd_user_content_t

– httpd_user_script_exec_t, httpd_user_script_ro_t

● Пишем политику, задающую разрешённые действия.(К счастью, уже почти всё сделано за нас в Targeted политике по умолчанию.)

Из жизни: защита веб-сервера (2/4)

● Файловая система:● Сайты в /var/www/<site> $ ls -dZ /var/www

– drwxr-xr-x sam sam system_u:object_r:httpd_user_content_t /var/www/example.com

– drwxr-xr-x jane jane system_u:object_r:httpd_user_content_t /var/www/example.org

● Статические данные. $ ls -dZ /var/www/example.com– drwxr-xr-x sam sam system_u:object_r:httpd_user_content_t

/var/www/example.com/index.html

– drwxr-xr-x sam sam system_u:object_r:httpd_user_content_t /var/www/example.com/about.html

– drwxr-xr-x sam sam system_u:object_r:httpd_user_content_t /var/www/example.com/sam.png

Из жизни: защита веб-сервера (3/4)

● Файловая система:● CGI скрипты. $ ls -dZ /var/www/example.org

– drwxr-xr-x jane jane system_u:object_r:httpd_user_script_exec_t /var/www/example.org/wiki.cgi

– drwxr-xr-x jane jane system_u:object_r:httpd_user_script_rw_t /var/www/example.com/wiki.db

– drwxr-xr-x jane jane system_u:object_r:httpd_user_script_ro_t /var/www/example.com/intro.html

● Домашние папки. $ ls -dZ /home/jane– drwxr-xr-x jane jane

system_u:object_r:user_home_dir_t /home/jane

Из жизни: защита веб-сервера (4/4)

Защита веб-сервера: что вышло

● Скрипты (httpd_user_script_t) не могут работать с файлами из домашних папок (user_home_dir_t), хотя принадлежат тому же пользователю

● Взлом скриптов компрометирует только данные типа httpd_user_script_rw_t

● Можно пойти ещё дальше и назначить разные контексты для разных скриптов

Сухой остаток

● DAC даёт нормальный уровень безопасности, если вы доверяете софту:

● MAC позволяет сильно ограничить полномочия конкретных процессов:

● Защита от недоверенного софта● Защита от недоверенных пользователей● Сильно снижает последствия взломов● Позволяет защититься от ещё не известных уязвимостей

● За всё надо платить — писать политику MAC может быть весьма непросто

Вопросы?

На подумать: взлом kernel.org

● Исходим из гипотезы, что атака была такой:● Компрометация ssh-ключей одного из разработчиков● Вход на машину по ssh● Повышение привилегий до root● Профит

● Вопросы:● Что могло пострадать от атаки, а что нет?● От чего и как защищают меры, предпринятые kernel.org?● Какие вообще методы пригодны для защиты от таких

атаки? Где здесь место DAC, где место MAC, где чего-то ещё? Где границы их применимости?