Локальная безопасность:от 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, где чего-то ещё? Где границы их применимости?