Security in Plan9 / Безопасность в Plan9: Chapter 1

Безопасность в Plan9

rapidfx 22.04.09 в 18:15

Russ Cox, MIT LCS

j1m 22.04.09 в 18:22

Eric Grosse, Bell Labs

j1m 22.04.09 в 18:22

Rob Pike, Bell Labs

j1m 22.04.09 в 18:22

Dave Presotto, Avaya Labs and Bell Labs

j1m 22.04.09 в 18:22

Sean Quinlan, Bell Labs

j1m 22.04.09 в 18:22

{rsc,ehg,rob,presotto,seanq}@plan9.bell-labs.com

j1m 22.04.09 в 18:22

ОБЗОР
Архитектура безопасности операционной системы Plan 9(tm) была недавно изменена из-за нескольких технических недостатков. Это изменения призваны сделать систему более удобной с точки зрения безопасности. Plan 9 в соответствии с этими улучшениями преследовал две обычно не совместимые цели: стать более безопасным и более легким в использовании.

rapidfx 24.04.09 в 06:25

Центральным компонентом новой архитектуры является агент работающий на пользовательском уровне названный factotum. Factotum безопасно хранит копию пользовательских ключей и взаимодействует с протоколом аутентификации от имени пользователя с сетевыми службами безопасности.
Сотредоточение кода отвечающего за безопасность в одной программе прдоставляет несколько преимуществ:
- легкость обновления или восстановления неисправной программы безопасности и протокола
- способности запускать службы безопасности на уровне ниже чем системный
- инифицировать управление ключами для всех сервисов
- и возможность предоставить единственную авторизацию, оставив без изменения оставшееся в наследство программное обеспечение.
Factotum имеет необычную архитектуру: он реализован как файл-сервер Plan9.

1. Введение

rapidfx 24.04.09 в 07:44

Компьютерные системы безопасности сталкиваются лицом к лицу с двумя трудностями: первая, они должны применять сложные технологии которые трудно правильно проектировать и испытывать; и второе, они должны быть простыми чтобы люди ими пользовались. Вопрос простоты использования зачастую забывался, но это первоочердное требование: поскольку даже ненадежное, но легкое в использовании средство безопаасности может быть намного эффективнее, чем мощное но трудное в применении средство если они больше нравяться людям. Люди запирают свои парадные двери когда покидают дом, зная наверняка что взломщик сможет открыть замок (или же сломать дверь); а еще они понимают сколько стоит и насколько неуклюжа дверь банковского хранилища в их доме, несмотря на то, что она значительно снизит вероятность ограбления.
В связи с этм пользователь нуждаются в ясной модели того как приводится в действие система безопасности (а не то, как она в действительности предоставляет безопасность) для того чтобы ей воспользоваться; например, ясная для понимания иконка замка на панели веб-браузера весьма далека от сбивающих с толку и обычно небезопасных шагов по установке сертификатов X.509.

rapidfx 24.04.09 в 09:29

Архитектура безопасности ОС Plan9 (Pike95) была недавно перепроектирована и для повышения безопасности и для простоты использования. Под безопасностью мы имеем в виду три вещи: во-первых, дело аутентификации пользователей и сервисов; во-вторых, безопасное обслуживание и развертывание, и использование ключей и другой секретной информации; и в-третьих, использование шифрования и проверки целостности охраняемых коммуникаций от любопытных глаз.

rapidfx 24.04.09 в 10:25

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

rapidfx 24.04.09 в 10:31

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

rapidfx 24.04.09 в 10:36

В-третьих, файловы протокол 9P (Pike93), который образует ядро Plan 9 систем, по замыслу уже имеет встроенный аутентификационный протокол. Это значит что исправляя или изменяя аутентификацию используемую в 9P требует внесения глубинных изменений в систему. Если кто-то найдет способ взломать протокол, система будет широко доступна и ее будет черзвычайно трудно исправить.

rapidfx 24.04.09 в 10:42

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

rapidfx 24.04.09 в 10:45

Краеугольным камнем новой архитектуры стал агент, названный factotum, который обслуживает пользовательские ключи и участвует во всех секретных переговорах с системными сервисами и приложениями. Как доверенный помощник с копией ключей собственника, factotum ведет все переговоры о безопасности и аутентификации. Теперь нет нужды в компиляции программ с криптографическим кодом; вместо этого они общаются с агентом factotum который представляет различные сущности в криптографическом обмене, таких как пользователь и сервер службы безопасности. Если есть потребность в добавлении протокола безопасности, удалении или модификации, только factotum будет обновлен для всех обеспечения безопасности системных сервисов.

rapidfx 24.04.09 в 12:53

Разрабатывая factotum, мы модифицировали службы безопасности в системе для вынесения кода аутентификации пользователя в factotum.; сделали аутентификацию отдельным компонентом файл-серверного протокола; внедрили новые протоколы безопасности; разработали безопасное хранилище файлов, названное secstore, для защиты наших ключей, но сделали так чтобы их было легко извлечь, когда они понадобятся; разработали новый модуль ядра для прозрачного использования Transport Layer Security (TLS) [RFC2246]; и начали использовать шифрование ля всех коммуникаций в системе. Общий взгляд на архитектуру показан на Рисунке 1а.
[Figure 1a]

rapidfx 24.04.09 в 18:14

Компоненты архитектуры безопасности.
Каждый квадрат (обычно) является отдельным компьютером; а каждый эллипс процессом. Эллисы помеченные FX это процессы factotum; другие помеченные PX части и прокси распределенной программы. Сервер аутентификации один из нескольких хранилищ для пользовательской приватной информации к которой процесс factotum'а обращается при необходимости. Secstore общий ресурс для хранения частной информации такой как ключи; factotum обращается к ней для пользователя во время загрузки.

rapidfx 25.04.09 в 05:12

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

rapidfx 25.04.09 в 05:23

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

2. Агент безопасности

rapidfx 25.04.09 в 05:34

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

rapidfx 25.04.09 в 07:09

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

rapidfx 25.04.09 в 08:12

Следуя примеру агента SSH (Ylon96), мы дали каждому пользователю процесс-агент ответственный за хранение и использование пользовательских ключей. Программа-агент названа factotum, потому что она просто созвучна известному слуге с силой к действию в сочетании со своим хозяином, потому что он хранит ключи от всех хозяйских владений. // вот намудрили, надо тут почитать http://en.wikipedia.org/wiki/Factotum
И это естественно, потому что factotum хранит ключи в секрете и пользуется ими в интересах своего владельца. Позднее мы обсудим некоторые изменения в ядре которые уменьшают возможность непреднамеренно утечки данных из factotum.

rapidfx 25.04.09 в 08:21

Factotum реализован наподобие многих сервисов Plan 9, как файл-сервер. он традиционно монтируется в директорию /mnt/factotum, и файлы им обслуживаемые аналогичны виртуальным устройствам которые предоставляют доступ, управляют сервисами factotum. Следующие несколько разделов описывают дизайн factotum и как он взаимодействует с другими частями Plan 9 для предоставления безопасных сервисов.

2.1. Авторизация / Logging in

rapidfx 25.04.09 в 08:26

Чтобы сделать изложени более конкретным, мы рассмотрим несколько примеров, показывающих как архитектура безопасности Plan 9 представляется пользователю. Оба этих примера заставляют пользователя <pre>gre</pre> авторизоваться после загрузки компьютера. Пользователь может иметь или не иметь защищенное хранилище в котором хранятся все его ключи. Если он делает это, factotum спрашивает его пароль к защищенному хранилищу и получает ключи из него, обращаясь к пользователю только тогда, когда ключи не найдены в хранилище. В противном случае, factotum должен обращаться за каждым ключом.

rapidfx 25.04.09 в 08:40

В листинге, \n представляет собой символ перевода строки, набранный для окончания ввода. Вод пользователя показан курсивом, и длинные строки были перенесены для удобства чтения.

rapidfx 25.04.09 в 08:42

В первом примере показано как пользователь авторизуется без помощи от защищенного хранилища. Во-первых, factotum спрашивает имя пользователя, которое будет использовано локальным ядром:

rapidfx 25.04.09 в 08:45

<pre> user[none]: <em>gre</em>
</pre>

rapidfx 25.04.09 в 08:45

(Ответ пользователя по умолчанию показан в квадратных скобках.) Ядро затем начинает доступ к локальным ресурсам и запрашивает через factotum пару логин/пароль для этого:

rapidfx 25.04.09 в 08:48

<pre> !Adding key: dom=cs.bell-labs.com proto=p9sk1
user[gre]: <em>\n</em>
password: ****
</pre>

rapidfx 25.04.09 в 08:49

Теперь пользователь зашел в локальную систему и запускается почтовый клиент:

rapidfx 25.04.09 в 08:50

<pre> !Adding key: proto=apop server=plan9.bell-labs.com
user[gre]: <em>\n</em>
password: <em>****</em>
</pre>

rapidfx 25.04.09 в 08:50

Factotum все время запрашивал логин/пароль и запущенные приложения не прикосались к ключам. Обратите внимание что всегда ясно какой ключ был запрошен.

rapidfx 25.04.09 в 08:54

Теперь предположим, ту же последовательность авторизации, но теперь у пользователя <pre>gre</pre> есть аккаунт в защищенном хранилище.

rapidfx 25.04.09 в 08:56

<pre> user[none]: gre
secstore password: <em>*********</em>
STA PIN+SecurID: <em>*********</em>
</pre>

rapidfx 25.04.09 в 08:56

Это было последнее что услышал <pre>gre</pre> от factotum до тех пор пока он не обратится к системе от которой нет ключей в secstore.

rapidfx 25.04.09 в 08:58

2.2. Factotum

rapidfx 25.04.09 в 08:58

Каждый компьютер с запущенным Plan 9 имеет один пользовательский идентификатор который владеет всеми ресурсами этой системы - планировщиком, локальными дисками, сетевыми интерфейсами и т.д. Этот пользователь, владелец компьютера, аналогичен пользователю root из мира Unix (хотя и намного слабее его; сокрее обладающий специальными полномочиями, вытекающими из того что владелец компьютера это простой пользователь и так случилось что он владее ресурсами локальной машины). На однопользовательской системе, которую мы называем терминалом, у владелеца хоста тот же самый id что и у терминального пользователя.
Сервера с общим доступом, такие как CPU сервера обычно имеют псевдо-пользователя который изначально владеет всеми ресурсами. Во время загрузки ядро Plan 9 запускает factotum с привилегиями владельца компьютера.

rapidfx 25.04.09 в 09:08

Новые процессы запускаются от имени пользовательского процесса который их создал. Когда поцесс должен взять идентификатор нового пользователя, как например для получения login shell на CPU-сервере, он делает это предоставляя factotum владельца компьютера который и выполняет авторизацию. Это происходит при помощи запуска протокола аутентификации с factotum для получения доступа к секретной информации которой должен владеть только новый пользователь. Например, рассмотрим схему из Рисунка 1а. Если пользователь терминала желает получить доступ к CPU-серверу используя cpu-сервис Plan 9 (Pike93), тогда PT модет быть клиентской cpu-программой а PC cpu-сервером. Никто, ни PC, ни PT не знают деталей аутентификации. Все что они должны сделать как это отослать сообщение и принять сообщения между двумя factotum, но это обычная функция легко осуществляемая без узнавания, или возможности извлечь секреты (здесь и далее под словом "секрет" имеется ввиду пароль) из сообщений. PT поизведет сетевое соединение с PC. PT и PC затем перенаправят свои сообщения между factotum которым владеет пользователь, FT, и другим factotum владелец которого CPU-сервер, FC, пора кне будет установлена взаимная аутентификация. Последующие разделы опишут RPC между factotum и приложениями и библиотечными функциями для поддержки прокси операций.

rapidfx 25.04.09 в 09:25

Ядро всегда пользуется единственным экземпляром factotum запущенного от имени владельца компьютера дляцелей аутентификации, но и обычный пользователь может запустить своего factotum-агента. В действительности, factotum представляющий пользователя не обязательно должен быть запущен на той же машине что и клиент. Например, это легко сделать пользователю CPU- сервера, через стандартную операцию Plan9, заместив /mnt/factotum в пользовательском приватном пространстве имен сервера соединив с factotum работающим на терминале. (Обычно, правай файловой системы препятствуют тем кто умышленно стремится нанести вред) Это дает разрешения на операции с безопасностью на CPU-сервере, которые будут прозрачно проходить проверку на собственном пользовательском factotum, и таким образом секретные ключи никогда не выйдут за пределы терминала. SSH агент (Ylon96) делает практически то же самое со специальными сообщениями протокола SSH , но преимущество создания нашего агента, в том что нам не нужен новый механизм для доступа к нашему удаленному агенту; удаленный файловый доступ так же успешен.

rapidfx 25.04.09 в 10:23

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

rapidfx 25.04.09 в 10:33

Протоколы аутентификации реализованы только в factotum, но добавление или удаление протоколов потребует перелинковки исполняемого файла, так что процесс factotum (и никакой другой больше) должен быть перезгружен для того чтобы изменения или добавления вступили в силу.

rapidfx 25.04.09 в 10:35

На момент написания, factotum содержит модули для протокола Plan 9 с разделяемым ключом (p9sk1), SSH's RSA аутентификацию, пароли в чистом виде, APOP, CRAM, PPP's CHAP, Microsoft PPP's MSCHAP, и VNC's вызов/отклик.

rapidfx 25.04.09 в 10:38

2.3. Локальные возможности

rapidfx 25.04.09 в 10:38

Возможности системы управляемой ядром, используются для того, чтобы уполномочить factotum дать разрешение другому процессу для смены пользовательского идентификатора. Драйвер устройства ядра реализует два файла, dev/caphash и /dev/capuse. Файл с возможностью только-для-записи /dev/caphash может быть открыт только владельцем компьютера, и только один раз. Factotum открывает этот файл немедленно после загрузки.

rapidfx 25.04.09 в 18:05

Для имспользования этого файла factotum создает строку в форме userid1@userid2@random-string, используя хэш SHA1 HMAC для кодирования строки userid1@userid2 с ключевой случайной строкой, и записывает этот хэш в /dev/caphash. Затем factotum передает оригинальную строку другому процессу на той же машине, запущенному от имени пользователя userid1, который в свою очередь записывает строку в /dev/capuse. Ядро хэширует строку и ищет соответствия хэша в этом списке. Если такое соответствие найдено, идентификатор записывающего процесса изменяется с userid1 на userid2. После однократного использования или после некоторого таймаута, эта возможность сбрасывается ядром.

rapidfx 25.04.09 в 18:12

Эта способность локальна для машины на которой она создана. Следовательно factotum запущенный на одной машине не может передать возможности процессу запущенному на другой машине и ожидать что это сработает.

rapidfx 25.04.09 в 18:14

2.4. Ключи

rapidfx 25.04.09 в 18:14

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

rapidfx 26.04.09 в 05:34

Беря пример с SDSI (Simple Distributed Security Infrastructure), которая представляет информацию о безопасности как текстовые S-выражения, ключи в Plan9 являются чистым текстом в кодировке UTF-8. Текст понимается и изменяется пользователями. В противоположность этому, двоичный или другой формат крипто-информации может действительно понизить общую безопасность. Двоичные форматы сложны для проверки пользователями могут быть взломаны только специальными инструментами, которые сами по себе малопонятны большинству пользователей. Например, только несколько людей знают или понимают что скрывается за сертификатами X.509. Большинство же не знает где их найти в системе. Поэтому у них нет понимания, чему же они собственно доверяют, и почему они бессильны изменить эти доверенные отношения. Текстовые, хранящиеся и управляемые централизованно ключи легко и безопасно использовать.

rapidfx 26.04.09 в 08:51