Руководство по защищенным Linux-контейнерам

Как усилить “легкие контейнеры” с помощью SELinux и Smack

Легкие контейнеры, также известные как Virtual Private Servers (VPS) или “тюрьмы” (Jails), часто считаются инструментами защиты, разработанными для изоляции приложений или пользователей, которые не соответствуют требованиям безопасности и доверительного доступа. Однако в настоящее время легкие контейнеры в их обычной конструкции не обеспечивают адекватных гарантий защищенности. Усилив такие контейнеры при помощи SELinux или политики Smack, можно создать в Linux® гораздо более защищенный контейнер. В данной статье изложен способ создания безопасного контейнера, защищенного с использованием Linux Security Modules. Проекты SELinux и политики Smack постоянно развиваются и совершенствуются соответствующими сообществами.

Серж Е. Халлин, штатный программист, IBM

Серж Халлин (Serge Hallyn) — сотрудник Linux Technology Center корпорации IBM, специализирующийся на разработке ядра и системы безопасности Linux. Он получил степень Ph.D. в области компьютерных наук в College of William and Mary. Он является автором и соавтором ряда модулей безопасности. Сейчас он занимается реализацией поддержки функциональности виртуальных серверов, контрольных точек/рестарта приложений и разрешений POSIX для файлов.



23.12.2010

Когда кто-либо впервые слышит о контейнерах, обычно возникает вопрос: “Как я могу создать защищенный контейнер?” Данная статья отвечает на этот вопрос, демонстрируя использование Linux Security Modules (LSM) для повышения безопасности контейнеров. В частности, вы узнаете, как определить целевое состояние в сфере защиты данных и достичь его с помощью модулей безопасности Smack и SELinux.

Для ознакомления с Linux-контейнерами рекомендуем прочесть статью "LXC: Linux container tools" (developerWorks, февраль 2009 г.).

Linux-контейнер в действительности является концептуальным понятием, которое надстроено над несколькими Linux-технологиями:

  • Области имен ресурсов, которые обеспечивают управление преобразованиями процессов, файлов, ресурсов SYSV IPC, сетевых интерфейсов и др. ресурсов в пределах контейнера.
  • Группы элементов управления, позволяющие задавать ограничения ресурсов в контейнерах.
  • Наборы ограничения полномочий, определяющие привилегии в контейнерах.

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

  • Libvirt — масштабный проект, в котором можно создавать виртуальные машины с использованием гипервизора Xen, эмулятора qemu, kvm и легких контейнеров.
  • Liblxc — набор библиотек и пользовательских команд, написанных таким образом, чтобы помочь разработчикам ядра быстро и легко тестировать функциональность контейнеров.

Поскольку руководство "LXC: Linux container tools" было написано на базе liblxc, в данной статье я продолжу использовать инструментарий данного проекта для рассмотрения практических способов усиления контейнеров. Однако все, что мы демонстрируем в данном руководстве, легко сделать и на базе проекта libvirt.

Основной игрок №1: LSM

Прежде чем мы начнем, предлагаю ознакомиться с кратким обзором LSM, если вы мало знакомы с данной инфраструктурой. Согласно статье в Википедии, “Linux Security Modules (LSM) — это структура, которая позволяет ядру Linux поддерживать множество моделей компьютерной безопасности, избегая предпочтений в пользу какой-либо одной реализации защиты данных. Структура лицензируется по условиям GNU General Public License и является стандартной частью ядра Linux начиная с версии 2.6.... LSM была разработана с целью предоставить все необходимое для успешного внедрения модуля полномочного управления доступом с минимально возможными изменениями ядра Linux. LSM позволяет избежать используемого в Systrace подхода передачи системных вызовов, поскольку он не масштабируется для мультипроцессорных компонентов и подвержен атакам TOCTTOU. Вместо этого LSM включает “перехватчики” (обратные обращения к модулю) в каждой части ядра, где обращение системы пользовательского уровня может привести к доступу к важным внутренним объектам ядра, таким как индексные дескрипторы файлов и контрольные блоки задач.... Проект LSM сфокусирован на решении проблем управления доступом и устранении необходимости внесения масштабных и сложных изменений в типовое ядро. Он не поддерживает виртуализацию и не предназначен для реализации общих механизмов “перехвата” или “обратного вызова”.... Реализованная в LSM задача управления доступом тесно связана с проблемой аудита системы, но имеет и свою специфику. Аудит требует протоколирования каждой попытки доступа. LSM не может этого обеспечить, поскольку это потребовало бы намного большего числа “перехватчиков” для выявления случаев, в которых “цепи короткого замыкания” в ядре дают сбои при системных обращениях и выдают код ошибки перед обращением к важным объектам.

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

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

Два основных модуля безопасности в Linux предлагают различные подходы к достижению баланса этих задач.

  • SELinux в первую очередь сфокусирован на детальном управлении, в то же время предлагая развитый язык политик для упрощения управления правилами.
  • Smack главным образом решает задачу простого управления доступом.

Основной игрок №2: SELinux

SELinux является наиболее известной системой MAC (мандатное управление доступом) для Linux. Хотя у нее достаточно противников, тот факт, что популярный дистрибутив Fedora® в течение многих лет выходит именно с SELinux, уже является основательным доказательством успеха этой системы.

SELinux конфигурируется с помощью модульного языка политик, что позволяет пользователям легко обновлять уже внедренные политики. Этот язык также имеет интерфейсы, позволяющие использовать операторы более высокого уровня для представления совокупности “разрешающих” операторов более низкого уровня.

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


Основной игрок №3: Smack

Smack (Simplified Mandatory Access Control Kernel — упрощённое мандатное управление доступом для ядра) позволяет маркировать все процессы, файлы и сетевые потоки простыми текстовыми метками. Вновь создаваемые файлы маркируются меткой создающего процесса. Существует небольшое число типов по умолчанию, которые всегда имеют четко определенные правила доступа. Процесс всегда может считывать и записывать объекты с такой же меткой. Полномочия обхода правил доступа Smack управляются с помощью функциональности POSIX. Например, задача, содержащая CAP_MAC_OVERRIDE, может переопределять правила; задача с CAP_MAC_ADMIN может изменять правила и метки. Более подробно с этими полномочиями можно ознакомиться в руководстве "POSIX file capabilities: Parceling the power of root" (Ресурсы).


Целевое состояние

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

  1. Создать контейнеры c изолированными файловыми системами для Web- и ssh-сервисов.
  2. Контейнеры должны быть защищены друг от друга. Контейнер vs1 не может читать файлы контейнера vs2 или останавливать его процессы.
  3. Хост-система может защищать свои ключевые файлы от контейнеров.
  4. Должны быть возможны внешние обращения к серверам Web и ssh в контейнерах.

Общая настройка

В данной статье мы продемонстрируем два эксперимента: сначала мы настроим контейнеры, защищенные SELinux, а затем — защищенные Smack. Предварительная настройка для обоих экспериментов в значительной степени сходна.

Вы можете проводить данные эксперименты на реальной машине, но, возможно, вы сочтете использование виртуальной машины более простым и надежным способом. Для использования qemu или kvm вы можете создать жесткий диск при помощи qemu-img create vm.img 10G.

Загрузите виртуальную машину с CDROM, используя команду типа kvm -hda vm.img -cdrom cdrom.iso -boot d -m 512M. Хороший вариант образа CDROM — загрузочный DVD для Fedora 10 for i386, который можно скачать с fedoraproject.org/get-fedora. Замените cdrom.iso в предыдущей команде именем файла, который вы скачали. В целом можно использовать параметры загрузки по умолчанию, только снимите флажок office and productivity и установите флажок software development. Вам также потребуется установить rpm-пакеты bridge-utils, debootstrap и ncurses-devel, например, используя менеджер пакетов yum.

Теперь необходимо скомпилировать ядро в соответствии с задачами. Скачайте rpm-пакеты с исходниками ядра, установите на них патч enable-netns.patch (см. раздел Загрузка) для организации сетевого пространства имен (оно доступно начиная с версии ядра 2.6.29, но не в Fedora 10), измените конфигурацию, затем завершите компиляцию и установку, введя нижеприведенные инструкции от имени root:

yumdownloader --source kernel
rpm -i kernel*
cd rpmbuild
rpmbuild -bc SPECS/kernel-*
cd BUILD/kernel-2.6.27/linux-2.6*
patch -p1 < ~/enable-netns.patch
make menuconfig
make && make modules_install && make install

Для обоих экспериментов на этапе make menuconfig выберите Network Namespaces (в меню Networking support -> Networking options). Для эксперимента с использованием Smack также зайдите в меню Security options, отмените выбор SELinuxи выберите следующий пункт —Smack. Также, возможно, понадобится изменить настройку загрузки default в /boot/grub/grub.conf с 1 на 0.

Теперь приступим к использованию liblxc. Руководство "LXC: Linux container tools" детально описывает основные возможности liblxc, поэтому в данной статье мы не будем на этом останавливаться. Просто запустите сценарий container_setup.sh (см. раздел Загрузка) для установки моста, по которому будут взаимодействовать сетевые устройства контейнера. Это также откроет ваш брандмауэр, который по умолчанию не настроен для поддержки моста, а также подготовит политику Smack (которую мы создадим позднее в файле /etc/smackaccesses), если вы проводите эксперимент со Smack. Сценарий container_setup.sh нужно будет выполнять после каждой перезагрузки или, если вы умеете, задать автоматический запуск этого сценария при загрузке.

Теперь машина готова, можно попробовать liblxc в действии. Можете скачать новейшую версию исходного кода с lxc.sf.net, используя cvs, и скомпилировать его при помощи нижеследующих команд:

cvs -d:pserver:anonymous@lxc.cvs.sourceforge.net:/cvsroot/lxc login
cvs -z3 -d:pserver:anonymous@lxc.cvs.sourceforge.net:/cvsroot/lxc co -P lxc
cd lxc
./bootstrap && ./configure && make && make install

Теперь, если вы посмотрите README, то обнаружите довольно много способов начать работу. Контейнеры могут быть очень легкими, поскольку они используют многие ресурсы вашей системы, в том числе файловую систему. Однако наша задача — реализовать некий простой уровень изоляции, поэтому мы с помощью сценария lxc-debian создадим полный образ debian chroot для каждого контейнера. Начните с создания контейнера с названием vsplain:

mkdir /vsplain
cd /vsplain
lxc-debian create
	container name: vsplain
	hostname: vsplain
	IP 10.0.2.20
	gateway: 10.0.2.2

Конфигурация этого контейнера хранится в каталоге /usr/local/var/lxc/vsplain. В файле cgroup вы увидите строки, начинающиеся с devices.. Это директивы к “белому списку” компонентов cgroup, которые опосредуют создание, считывание и запись элементов контейнером.

Запустите данный контейнер командой lxc-start -n vsplain. YПри появлении диалога входа войдите в контейнер, используя имя пользователя root и пустой пароль. Когда ваш контейнер загрузится, выполните

apt-get install openssh-server
apt-get install apache

Теперь можно установить соединение с контейнером по ssh с хоста kvm и посмотреть на его веб-страницу, используя 10.0.2.20 как IP -адрес vsplain и 10.0.2.15 как адрес хоста. Вы можете в любой момент закрыть контейнер с терминала root хоста kvm, используя команду lxc-stop -n vsplain.

Теперь для экономии времени можно клонировать две виртуальные машины по этому шаблону. Закройте вашу виртуальную машину и выполните:

cp vm.img selinux.img
cp vm.img smack.img

Контейнеры, защищенные SELinux

Предлагаемая SELinux стратегия защиты контейнеров, которую мы будем использовать, состоит из модуля политики; этот модуль был опубликован в списке рассылки refpolicy — SELinux Reference Policy development. Скачайте политику в каталог /root/vs в файлы vs.if, vs.fc и vs.te соответственно. Скомпилируйте и установите новый модуль следующим образом:

cp -r /usr/share/selinux/devel /usr/share/selinux/vs
cp /root/vs.?? /usr/share/selinux/vs/
cd /usr/share/selinux/vs
make && semodule -i vs.pp

Затем создайте контейнеры /vs1 и /vs2 с помощью lxc-debian и перемаркируйте их файловые системы, используя следующий скрипт:

mkdir /vs1; cd /vs1
lxc-debian create
	container name: vs1
	hostname: vs1
	address: 10.0.2.21
	gateway: 10.0.2.2
	arch: 2 (i386)
mkdir /vs2; cd /vs2
lxc-debian create
	container name: vs2
	hostname: vs2
	address: 10.0.2.22
	gateway: 10.0.2.2
	arch: 2 (i386)
fixfiles relabel /vs1
fixfiles relabel /vs2

При запуске созданных контейнеров (например, с использованием lxc-start -n vs1) вы скорее всего получите от системы аудита несколько сообщений о блокировке доступа SELinux. Не обращайте внимания — контейнер и разрешенные в нем сетевые службы работают нормально и изолированно от других контейнеров. Если вы протестируете контейнер vs1, выполнив mount --bind / /vs1/rootfs.vs1/mnt о его запуска, то обнаружите, что даже пользователю root будет отказано в доступе к ls /mnt/root.

Чтобы понять, как это работает, рассмотрим файл интерфейса vs.if. Он определяет интерфейс container, который принимает один параметр — базовое имя для определяемого контейнера. Файл vs.te обращается к этой функции дважды, с именами контейнеров vs1 и vs2. В данном интерфейсе $1 преобразуется в параметр, поэтому, $1_t становится vs1_t, когда мы вызываем container(vs1) (с этого момента допустим, что мы определяем vs1).

Наиболее важные строки — те, которые содержат vs1_exec_t. Контейнер работает в типе vs1_t; данный тип вводится, когда unconfined_t исполняет в контейнере /sbin/init, которая принадлежит к типу vs1_exec_t.

Остальная часть рассматриваемой политики в основном обеспечивает предоставление контейнеру необходимых полномочий доступа к объектам системы — сетевым портам, устройствам, консолям и т.д. Длина этого интерфейса обусловлена возможностями тонкой настройки, свойственными политике обращений SELinux. Как мы увидим, контейнер, защищенный Smack, строится на базе гораздо более простой политики; с другой стороны, он не может обеспечить такую же гибкую защиту от неправильной работы системных служб.

Осталось сделать еще одну вещь, чтобы завершить эксперимент с SELinux. Вы, возможно, заметили, что контейнер не может перезаписать свой $1_exec_t, т.е. /sbin/init. Однако он может выполнить следующее:

mv /sbin /sbin.bak
mkdir /sbin
touch /sbin/init

Итоговый /sbin/init будет принадлежать типу vs1_file_t. Как вы думаете, зачем такое может понадобиться администратору контейнера? Затем, что это позволяет запустить контейнер, включая демона ssh, в области unconfined_t, предоставив ему привилегированную оболочку и избежав ограничений SELinux, которые мы пытались ввести в действие.

Чтобы предотвратить такие действия, вам необходимо запустить контейнер с помощью специального сценария и проиндексировать sbin/init как vs1_exec_t до запуска контейнера. В действительности вы можете поместить копию первоначального init обратно в контейнер и проиндексировать ее, если администратор контейнера это позволяет. Мы же переназначим метку имеющемуся init:

cat >> /vs1/vs1.sh << EOF
#!/bin/sh
chcon -t vs1_exec_t /vs1/rootfs.vs1/sbin/init
lxc-start -n vs1
EOF
chmod u+x /vs1/vs1.sh

Теперь вам необходимо будет запускать контейнер, используя /vs1/vs1.sh вместо lxc-start.


Контейнеры, защищенные Smack

Перекомпилируйте ядро с использованием Smack. Вы можете просто ввести /root/rpmbuild/BUILD/kernel*/linux*, make menuconfig, зайти в меню security, отключить SELinux и активировать Smack. Затем просто повторите шаги make && make modules_install && make install.

Также запретите попытки конфигурирования SELinux из пространства пользователя. Это можно сделать при помощи графического интерфейса администрирования SELinux или отредактировав /etc/selinux/config и установив SELINUX=disabled. Кроме того, вам потребуется установить политику Smack при загрузке:

mkdir /smack
cd /usr/src
wget http://schaufler-ca.com/data/080616/smack-util-0.1.tar
tar xf smack-util-0.1.tar; cd smack-util-0.1
make && cp smackload /bin

Действующая политика Smack выглядит как в листинге 1:

Листинг 1. smackaccesses
vs1 _ rwa
_ vs1 rwa
vs2 _ rwa
_ vs2 rwa
_ host rwax
host _ rwax

Ее необходимо скопировать в файл /etc/smackaccesses. При запуске /bin/container_setup.sh она загрузит этот файл в smackload.

Политика довольно проста. По умолчанию любой идентификатор может читать данные, помеченные   _. Мы определяем новую метку host для данных хост-системы, к которым у контейнеров не должно быть доступа, и назначаем ее файловой системе cgroups в сценарии container_setup.sh. Эта метка должна быть назначена и другим файлам, требующим защиты, например, /etc/shadow.

Для разметки контейнеров определяем метки vs1 и vs2. По умолчанию каждый из них имеет доступ к собственным данным. Добавим правило, позволяющее им записывать _, чтобы обеспечить передачу сетевых пакетов. Контейнеры защищены друг от друга, поскольку vs1 не имеет доступа к данным vs2, и наоборот.

Как было сказано выше, возможность описывать или обходить правила доступа в Smack определяется настройками CAP_MAC_ADMIN и CAP_MAC_OVERRIDE, поэтому вам необходимо проконтролировать, чтобы в контейнерах не было этих возможностей. Это можно сделать с помощью вспомогательной программы dropmacadmin.c (см. раздел Загрузка). Компилировать ее следует статично, поскольку версии библиотек в контейнерах и хост-системе различаются:

gcc -o dropmacadmin dropmacadmin.c -static
cp dropmacadmin /bin/

Создайте новый контейнер с названием vs1:

mkdir /vs1; cd /vs1
lxc-debian create
	container name: vs1
	hostname: vs1
	address: 10.0.2.21
	router: 10.0.2.2
	arch: 2 (i386)

Проиндексируйте все файлы в файловой системе vs1 меткой vs1:

for f in `find /vs1/rootfs.vs1`; do
	attr -S -s SMACK64 -V vs1 $f
done

Теперь вам необходимо создать сценарий для безопасного запуска контейнера. Для этого он должен назначить vs1 меткой процесса и инкапсулировать /sbin/init данного контейнера в dropmacadmin, как в нижеприведенном примере:

cat >> /vs1/vs1.sh << EOF
#!/bin/sh
cp /bin/dropmacadmin /vs1/rootfs.vs1/bin/
attr -S -s SMACK64 -V vs1 /vs1/rootfs.vs1/bin/dropmacadmin
echo vs1 > /proc/self/attr/current
lxc-start -n vs1 /bin/dropmacadmin /sbin/init
EOF
chmod u+x /vs1/vs1.sh

Следующая команда дает vs1 права записывать в файловую систему tmpfs, которая будет смонтирована:

sed -i 's/defaults/defaults,smackfsroot=vs1,smackfsdef=vs1/' \
	/vs1/rootfs.vs1/etc/fstab

В результате файловая система tmpfs, смонтированная в /dev/shm, получит метку vs1, после чего vs1 сможет писать в нее. В противном случае сценарии инициализации vs1 не смогут создать каталог /dev/shm/network, который используется при настройке сети. Аналогично, если вы используете /tmp в оперативной памяти, вам будут необходимы те же самые опции.

Протестируем возможности несанкционированного доступа vs1. Создайте vs2 аналогично тому, как был создан vs1, заменяя vs2 на vs1 на каждом шаге. Затем смонтируйте корневую файловую систему в /mnt контейнера vs1:

mount --bind /vs1 /vs1
mount --make-runbindable /vs1
mount --rbind / /vs1/rootfs.vs1/mnt

Запустите контейнер с помощью vs1.sh. Обратите внимание, что вы по-прежнему можете видеть Web-страницы на vs1 и vs2 с хоста kvm. Также заметим, что vs1 не имеет доступа по сети к vs2 и не может просматривать файлы vs2:

vs1:~# ls /mnt/
  (directory listing)
vs1:~# ls /mnt/vs2/rootfs.vs2
  ls:/mnt/vs2/rootfs.vs2: Permission denied
vs1:~# mkdir /cgroup
vs1:~# mount -t cgroup cgroup /cgroup
vs1:~# ls /cgroup
  ls:/mnt/vs3: Permission denied
vs1:~# mknod /dev/sda1 b 8 1
  mknod: `/dev/sda1': Operation not permitted
vs1:~# mount /mnt/dev/sda1 /tmp
  mount: permission denied

Он может видеть файловую систему хоста; все, что необходимо защитить, должно быть проиндексировано меткой host. Это то, что мы сделали с файловой системой cgroup, и что помешало исполнению ls /cgroup.

Наконец, “белый список” компонентов cgroup защищает нас от создания и монтирования дискового устройства, если оно уже существует (например, в /mnt).

Данный пример монтирования системы приведен только для демонстрации и не является образцовым, поскольку при такой настройке администратор контейнера может удалить/mnt/dev/sda1, а также привести в беспорядок данные хост-системы.

Отметим, что если в системе SELinux стандартным (и простым) методом является предоставление контейнерам возможности взаимодействовать по сети, то для Smack верно прямо противоположное. На данный момент очень трудно добиться безопасного взаимодействия контейнеров. Однако в ближайшее время должна появиться возможность назначать метки IP-адресам, что позволит устанавливать политики взаимодействия контейнеров.

Еще одна проблема связана с тем, как мы настроили сеть Smack. Команда kill -9 -1 отменяет все задачи в системе. При использовании в контейнере эта команда должна останавливать задачи только в данном контейнере. Эта проблема решена в новых версиях ядра, но не в ядре Fedora 10, которое мы использовали. В нем сигнал -9 получат все задачи.

При защите контейнеров с помощью SELinux эта система не пропускает команды за пределы контейнера, поэтому команда kill -9 -1 вполне безопасна. Но в Smack задачи по умолчанию маркированы _, точно так же, как и сеть. Поэтому если мы разрешаем контейнеру записывать _, чтобы дать возможности сохранения данных в сети, и поскольку снятие задачи считается в Smack доступом на запись, это означает, что вы разрешаете администратору контейнера убивать любые задачи во всей системе.

Еще одно слабое место (которое имеется и у контейнеров SELinux) имеет отношение к псевдотерминалам Unix98. Откройте два графических терминала. В первом запустите vs1 и зайдите в /dev/pts. Вы увидите как минимум две записи входа, 0 и 1, по одной на каждый терминал. Из контейнера vs1 вы можете сохранять данные в запись, принадлежащую другому терминалу.

В ядре Fedora имеется два решения этой проблемы. Можно с помощью “белого списка” компонентов cgroup запретить контейнеру открывать компоненты. Однако это придется делать вручную каждый раз при запуске контейнера, чтобы предоставить ему доступ к его терминалу. Такого же результата модно добиться, используя метки SELinux и Smack.

Ядро 2.6.29 поддерживает пространство имен devpts. Контейнер перемонтирует /dev/pts, после чего он не сможет получить доступ к записям devpts, которые принадлежат другому контейнеру или хост-системе.


Заключение

Данная статья демонстрирует базовые инструменты создания контейнеров, защищенных LSM, но остается еще много задач, которые необходимо выполнить:

  • При использовании Smack требуется выбрать файлы, которые будут проиндексированы меткой host.
  • При использовании SELinux необходимо тонко настроить интерфейс container, а затем внедрить его в вышестоящую политику обращений.

Хотя эта работа продолжается и опыт использования контейнеров, защищенных LSM, накапливается сообществом, вам не следует целиком полагаться на данные механизмы в деле защиты от несанкционированных привилегированных пользователей.

Хотя утвердившихся рекомендованных методик создания контейнеров пока не существует (или мне о них не известно), есть несколько хороших идей, с которых следует начинать. Во-первых, помните, что вы стараетесь объединить две отчасти разнонаправленные задачи: минимизировать дублирование в контейнерах и хост-системах и одновременно обеспечить изоляцию. Одним из способов достижения этих целей может быть создание отдельной корневой файловой системы, в которой не будет контейнеров и которую надо будет разметить по такому типу, который все контейнеры смогут читать. Затем используйте свою версию сценария lxc-sshd для создания каждого контейнера на основе прототипа, создавая блоки “только для чтения” для основной части файловой системы контейнера и одновременно организуя в каждом контейнере частные области для записи и хранения файлов, например, таких как /scratch. Поскольку каждый контейнер имеет частное пространство имен, он может смонтировать любые файлы или каталоги, которые необходимо сделать частными и/или записываемыми, из своего частного совместно используемого каталога. Например, если ему нужен частный /lib, он может выполнить mount --bind /scratch/rootfs/lib /lib. Аналогично, администратор может задать выполнение mount --bind /scratch/shadow /etc/shadow каждым контейнером при загрузке.

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

Данный материал основан на работе, выполненной при поддержке Defense Advanced Research Projects Agency по соглашению № HR0011-07-9-0002.


Загрузка

ОписаниеИмяРазмер
Код этой статьиcode.zip3КБ

Ресурсы

Научиться

Получить продукты и технологии

  • Проект Linux Resource Containers на SourceForge.net — репозитарий кода контейнеров приложений для ядра Linux, промежуточное хранилище кода, который может быть отправлен в списки рассылки ядра Linux. (EN)
  • Используйте в следующем проекте разработки для Linux ознакомительное ПО IBM, которое можно загрузить напрямую с developerWorks. (EN)

Обсудить

Другие файлы для загрузки

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=604897
ArticleTitle=Руководство по защищенным Linux-контейнерам
publish-date=12232010