Как стать автором
Обновить

«Распределенное управление информационными потоками»/«Distributed Information Flow Control»

Время на прочтение 5 мин
Количество просмотров 3.5K
Недавно по просьбе своего научного руководителя делал компиляцию и обзор для своей группы некоторых актуальных топиков в сфере безопасности ОС и систем в целом: automated trust negotiation (автоматическое «обсуждение» прав доступа — не знаю как правильно перевести) и information flow control (контроль потоков информации). Хотел запостить эту компиляцию, но к своему удивлению нашел, на мой взгляд, необоснованно мало сведений о DIFC (distributed information flow control/распределенном управлении инфромационными потоками) в .RU и поэтому решил написать эту небольшую статью по DIFC.

Мотивация
Практически единственным способом обеспечивать безопасность и приватность данных в системе принято считать аутенификацию (отвечает на вопрос: «Кто это сказал?») и авторизацию («Что он имеет право делать с этими данными»). Т.е. если программе необходим доступ к некоторым данным, мы фактически имеем 2 варианта: отказать или поверить. Если мы не доверяем этой программе, то теряем возможность работать с ней и возможно лишаемся важной функциональности. Если же мы решаем, что доверяем программе (и/или ее разработчикам), то программа фактически становится «полновластным хозяином» этой информации (или копии). Такой принцип в литературе называют All-Or-Nothing — «Все или ничего».

Естественно, что этот принцип недостаточно гибок и кроме того является основной причиной многих уязвимостей в системах, таких как переполнение буфера. В общем случае, этот принцип не позволяет создавать более интересные приложения, где права доступа не ограничиваются традиционными: «no access», «read only» и «read/write». Оказывается, что существуют системы, которые позволяют намного более гибкие разграничения прав доступа к данным — системы с поддержкой управления информационными потоками. Самой главной особенностью этих систем является то, что они следят за данными на всем протяжении их жизненного цикла в системе. Вспомним, что традиционно система ответственна только за начальный доступ к данным, например, проверку имеет ли программа доступ к файлу, а что после этого программа делает с этими данными систему уже не интересует.

Классический пример. Допустим, что в системе есть 2 пользователя Алиса и Боб. Они хотят назначить встречу, но так чтобы не раскрывать слишком много информации о своем расписании недели. Можно ли в многопользовательской системе Linux/Unix/Windows написать программу таким образом, чтобы она имела одновременный доступ к календарям и Алисы, и Боба и гарантировала конфиденциальность обоих пользователей системы?

Самый простой способ — попросить «суперпользователя» написать такую программу или хотя бы правильно назначить права на уже существующе решение. Но этот путь создает как минимум 2 проблемы:

1. Нет гарантии, что программа не содержит логических ошибок и, например, не скопирует данные Алисы куда-нибудь еще (или админ неправильно назначит права).
2. Нужно доверять на все 100% «суперпользователю» и кроме того, такой процесс неинтерактивен, т.е. ждать пока админ напишет такую программу или выставит права.

Решение первой проблемы осуществляется при помощи систем с поддержкой управления информационными потоками.

В общем системы с поддержкой управления информационными потоками условно делятся на 2 категории: централизованные и распределенные (децентрализованные). К централизованным относят всем известные SELinux и AppArmor. В этой же статье я постараюсь рассказать о децентрализованных системах, на примере исследовательской (следовательно совершенно непригодной для реального использования, к сожалению) ОС Flume, т.к. имел некоторый опыт «общения» с ней. Децентрализованные системы позволяют избавиться и от второй проблемы — зависимость от суперпользователя.

(Distributed) Information Flow Control
Если кратко, то идея контроля потока информации тривиальна и заключется в том, чтобы отслеживать как данные «перетекают» в системе от отправителя к получателю. Главная задача системы предотвратить несанкционированную утечку данных из нее. В общем случае, ни одна программа (кроме «привилегированной») не может иметь одновременный (в контексте жизни программы) доступ к приватным данным и любому «стоку информации» (sink), таким как монитор, принтер, сокет (AF_INET). Т.е. если программа один раз прочитала мои личные файлы, то после этого система не позволит этой программе иметь доступ к сети.

Для того чтобы сделать данные приватными необходимо явно это указать, например, с помощью специальных флагов/тэгов. Вот тут и главное различие между централизованными и распределенными системами. В первом случае существует особый пользователь — «менеджер безопасности», который ответственен за правильное «тэгирование» данных и определение прав доступа различных программ к таким данным. Например, можно назначить тэг «особо секретно» на файлы с вашими паролями или информацией о личных доходах и разрешить доступ к нему только для Vim/Emacs без прав (1) эти данные экспортировать куда бы то ни было и (2) снять эти тэги. Таким образом, даже если скомпроментировать ваши текстовые редакторы, то система (предполагая, что сама система безопасна и работает без ошибок) не позволит сохранить эти файлы где-либо в системе (/tmp) с другими более разрешающими тэгами и отослать их каким-либо образом в Интернет. Я не работал с SELinux, поэтому отсылаю вас к официальным руководствам за дальнейшей информацией.

В распределенных же системах любая программа/сущность может создавать свои тэги, назначать права и давать доступ к своим данным для других программ.



В ОС Flume вы можете создать тэг для доступа к некоторым личным данным. Причем у вас есть выбор. Можно отдать в открытый доступ права на назначение этого тэга и/или на его удаление. Допустим, что мы создали тэг tag1 и отдали в открытый доступ право {tag1+}, тогда любая программа может поместить этот тэг в свой собственный набор тэгов. Если мы создадим файл F и ассоциируем его с тэгом tag1, то любой процесс p1 может включить в свой набор тэгов этот тэг tag1 и после этого сможет читать все данные, помеченные tag1. Однако, так как {tag1-} не в открытом доступе, то этот процесс не сможет удалить tag1 со своего набора тэгов и отныне может общаться только с процессами, с набором тэгов, которые являются надмножеством аналогичного набора процесса p1.

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

Flume — это одна из разработанных систем, которая обеспечивает «правильность» потока информации. На системном уровне Flume — это Linux с модифицированной системой LSM, которая перехватывает основные системные вызовы, хранит информацию о тэгах, метках и проверяет на корректность потока данных от одного процесса к другому.

Теперь вернемся к примеру с календарем Алисы и Боба. В ОС Flume Алиса назначит тэг A для своего календаря, а Bob для своего — тэг B. Алиса отдает в открытый доступ {A+}, а Боб {B-}. Боб запускает программу с меткой {A, B}, т.е. с возможностью доступа к обоим календарям. Эта программа находит несколько удобных временных промежутков, где ни Алиса, ни Боб не заняты, снимает с себя тэг B ({B-} в открытом доступе) и записывает результат в файл F, который получает автоматический тэг A ({A-} не в открытом доступе). Алиса открывает файл F, т.к. она является владельцем тэга A и выбирает конкретную дату из списка «предложенных Бобом». На всякий случай напомню, что {B+} не в открытом доступе, поэтому Алиса не может читать календарь Боба.

Заключение
К сожалению, я не смогу охватить всех сфер применимости идей DIFC (даже тех, которые использовал в качестве мотивации проблемы) Есть немало отличных статей на эту тему, начинаю с самых классических (Jiff) до достаточно свежих HiStar/DStar или Resin. При наличии интереса к данной теме могу более подробно/формально рассказать о, например, фреймворке Resin от MIT. В свое время посчастливилось побеседовать с Барбарой Лисков (которая является, наверное, одной из главных авторитетов в данной области) на тему контроля потока информации, применимости этих принципов для других задач и просто заболел этой темой. Есть несколько интересных «видений» развития этой идеи: W5 (world wide web without walls) или Fabric. Но это уже совершенно другая история…
Теги:
Хабы:
+15
Комментарии 16
Комментарии Комментарии 16

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн