Ющих сделать жизнь администраторов спокойнее. Это и изоля- ция сервисов (chroot), и защита от переполнений буфера (owl или grsecurity), и разграничение привилегий



Скачать 171.41 Kb.

Дата23.11.2016
Размер171.41 Kb.
Просмотров92
Скачиваний0

68
C H I P
|
L I N U X
2 / 2 0 0 5
a d v a n c e d
‡ ‰ Ï Ë Ì Ë Ò Ú  Ë  Ó ‚ ‡ Ì Ë Â
|
Что это и кто это?
|
На сегодняшний день существует много технологий, позволя- ющих сделать жизнь администраторов спокойнее. Это и изоля- ция сервисов (chroot), и защита от переполнений буфера (owl или grsecurity), и разграничение привилегий (например, LIDS
или RSBAC). Но согласитесь, было бы все же лучше, если бы некоторые небезопасные сервисы можно было физически пе- ренести на другой сервер (например, сервисы баз данных, раз- личные IM-сервисы и т. д.). «Как, — скажете вы, — у нас уже есть один сервер, самый мощный и лучший, зачем нам еще?»
Хорошо бы сделать так, чтобы на базе одного физического сер- вера можно было создать несколько виртуальных и на каждый из них установить свой дистрибутив и настроить его по вкусу.
Видимо, подобные мысли не давали покоя программисту и администратору Жаку Глина, и он придумал решение, которое было названо VServer (изначально оно носило имя Virtual
Private Server, но когда так стали называть другой проект, было принято решение о переименовании). По сути, это сервер вну- три сервера — со своими ресурсами, сетевыми интерфейсами,
памятью, ограничениями и пользователями. При этом серверы не видят и не влияют друг на друга. Свежую версию VServer можно найти в Интернете по адресу www.linux-vserver.org.
Кому, кроме администраторов, это решение может приго- диться? Говоря словами авторов, «всем, кому нужно управлять сервером». Вот несколько примеров, показывающих, в каких областях это применимо:
3
Хостинг. Полностью независимый от ограничений провайде- ра хостинг (то есть несколько отдельных виртуальных серверов в пределах одного физического).
3
Эксперименты с программным обеспечением. Согласитесь,
ê‡Á‰ÓθÂ
‚ ÒÂ‚ÂÌÓÏ
Á‡Ôӂ‰ÌËÍÂ
Современные компьютеры становятся все быстрее и быстрее, и грех этим не воспользоваться. Однако и тут есть свои подводные камни.
Предположим, у вас мощный компьютер с большим объемом оперативной и дисковой памяти, и вы хотите создать мощный сервер,
предоставляющий множество различных сервисов. «Без проблем», —
скажете вы — и будете не правы, потому что нужно еще сделать так,
чтобы сервер можно было легко администрировать и чтобы само решение было максимально безопасным.
Константин Лепихов

69
Ì ‡ Ò Ú  Ó È Í ‡ V S e r v e r не совсем правильно производить отладку или разработку про- граммного обеспечения на рабочей системе, а вот делать это на отдельной машине было бы вполне логично.
3
Образовательные цели. Например, каждому студенту можно дать свой сервер, с которым он сможет делать все, что захочет.
Можно даже дать ему пароль root.
3
Изолированные серверы. Например, если нужно работать с каким-то приложением и необходим полный контроль за его действиями.
3
«Сервер-приманка» (honeypot). Незаменимая вещь для защи- ты и исследования сети.
3
Поддержка работы нескольких версий серверов и возмож- ность их независимого включения и отключения.
Кстати, и кошмар, связанный с резервным копированием,
может уйти в прошлое, ведь теперь сервер — это всего лишь ка- талог на диске, который можно скопировать когда и куда угод- но. А основная система — всего лишь минимальный набор па- кетов и ядро с vs-патчем. В системах промышленного уровня раздел с виртуальными серверами может храниться на LVM,
который находится поверх DRBD и т. д. Если вы используете файловую систему xfs, можно делать «снимки» раздела и сохра- нять их на устройстве для резервной записи — в общем, есть где разгуляться фантазии настоящего администратора. В слу- чае хостинга есть тоже одно неоспоримое преимущество — ре- альный биллинг, который можно гибко настраивать в пределах одной системы (ведь у каждого сервера только один IP, и его невозможно поменять или подделать).
|
Архитектура VServer
|
Linux VServer состоит из двух частей:
3
Патч к стандартному ядру Linux. Он добавляет поддержку контекстов безопасности, воплощающих основную идею
VServer. Они позволяют изолировать каждый VServer внутри основной системы и исключить их взаимное влияние друг на друга. Процесс, выполняющийся в рамках определенного контекста, может видеть лишь такие же процессы и исполь- зовать только IP-адрес, присвоенный данному контексту.
Процессам запрещено создавать устройства и открывать пря- мой доступ к ним (при этом данные ограничения действуют даже для суперпользователя).
3
VServers Tools. Набор программ для создания и управления виртуальными серверами. В основном все они написаны на языке командной оболочки, что позволяет их легко модифи- цировать под свои нужды. В том числе в VServers Tools вклю- чена и программа VServer, позволяющая запускать, останавли- вать и заходить в виртуальный сервер.
|
Изолированные области
|
Все системы на базе Linux или Unix имеют специальный вы- зов — chroot(). Он требуется в том случае, если нужно «поса- дить» процесс в отдельную директорию. После этого процесс,
для которого был сделан chroot(), будет считать, что директо- рия, в которой он находится, является корневым каталогом.
Вызов chroot() нельзя отменить. Единственное, что остается делать процессу в этой ситуации, — это отправляться в дирек- тории уровнем ниже, повторяя chroot() снова и снова. Вы,
наверное, уже догадались, к чему шло все это вступление: ос- новная идея технологии VServer — системные вызовы, позво- ляющие полностью изолировать запуск и исполнение про- цессов в определенных местах внутри сервера.
Виртуальный сервер изолирован в четырех областях:
3
Файловая система. Каждый VServer «посажен» в отдельную директорию главного сервера и не может «убежать» из из нее.
Это ограничение реализовано через вызов chroot(), имеющийся в любой Unix-совместимой системе.
3
Процессы. VServer может видеть только те процессы, кото- рые находятся в одинаковом с ним контексте безопасности.
Даже сервер с контекстом root может видеть только свои про- цессы (это сделано для того, чтобы он был более безопасным в использовании). Для просмотра всех процессов на всех вир- туальных серверах существует специальный механизм (кон- текст с номером 1).
3
Сеть. Каждый VServer имеет уникальные имя и IP-адрес, ко- торые могут быть использованы сервером для сетевых соедине- ний и ответов на запросы. Кроме того, это ограничение неза- метно для VServer.
3
Суперпользователи и их возможности. Суперпользователь,
работающий с VServer, имеет меньше привилегий по сравнени- ем с тем, который работает в обычной системе Linux. Напри- мер, он не может настраивать и отключать сетевые интерфейсы и многие параметры системы, а также подсоединять или отсое- динять файловые системы, работать с блочными устройствами и т. д. Грубо говоря, суперпользователь VServer имеет полный доступ только к тому, что в нем есть, а именно — к файлам и процессам, и большего ему не дано.
|
Взаимодействие между процессами
(System V IPC)
|
Все внутренние IPC-ресурсы изолированы от IPC-ресурсов других VServer. Для выбора необходимого в качестве ключа используется номер контекста безопасности каждого VServer.
2 / 2 0 0 5
L I N U X
|
C H I P
ꇷÓÚ‡ ÛÚËÎËÚ˚ vserver-stats: ÒÚ‡ÚËÒÚË͇ ‡ÍÚË‚Ì˚ı ‚ËÚۇθÌ˚ı
ÒÂ‚ÂÓ‚; ̇ Á‡‰ÌÂÏ Ô·Ì ssh-ÒÂÒÒËfl Ò Ó‰ÌËÏ ËÁ VServer

70
C H I P
|
L I N U X
2 / 2 0 0 5
a d v a n c e d
‡ ‰ Ï Ë Ì Ë Ò Ú  Ë  Ó ‚ ‡ Ì Ë Â
Это позволяет создать удобную и гибкую среду для работы виртуального сервера. И каждая из перечисленных возмож- ностей может быть использована независимо от других.
|
Безопасность
|
Даже если вами было создано окружение, в котором процес- сы ограничены лишь собственным виртуальным миром и об- щаются с сетью только через выделенный IP-адрес, вы долж- ны сделать так, чтобы и ущерб, который могут вам причинить эти процессы, был минимальным. Для этого нужно создать виртуальные среды и дать им ограниченные привилегии root.
Как же можно ограничить процессы с правами root, которые обладают таким контролем над системой (например, могут просто перезагрузить компьютер)? Введите систему возмож- ностей (capabilities). Идея не нова, но мы считаем, что очень многие пользователи никогда не слышали о существовании подобной системы.
В старые времена систем Unix/Linux пользователь root
(обладающий идентификатором 0) имел возможность де- лать такие вещи, о которых другие пользователи даже не могли и мечтать. Весь доступ к ядру, системным вызовам или просто некоторым ресурсам прекращался, если иден- тификатор пользователя (или процесса, запущенного этим пользователем) не был равен нулю. Для того чтобы процесс с ID 0 мог хоть немного понизить привилегии, существовал только один путь — менять идентификатор на отличный от нуля. Одним словом, либо все, либо ничего. И вот тут-то и появилась система возможностей.
|
Система возможностей
|
Сегодня все, что отличает root от других пользователей, — это набор возможностей. Пользователь root обладает всеми воз- можностями, а другие — нет; ID 0 больше уже ничего не зна- чит — просто красивая цифра. На данный момент насчиты- вается около 30 возможностей. Можно сделать так, чтобы процесс утратил какие-либо возможности навсегда и они к нему больше никогда не вернулись.
Возможности позволяют уменьшить силу root — и это именно то, что нужно, если вы хотите создать собственного суперпользователя. Процесс с его правами, запущенный вну- три виртуального окружения, к примеру, может открыть порт перед 1024, но окажется не в состоянии отключить или пере- настроить параметры сетевого интерфейса. Рассмотрите внимательно файл /usr/include/linux/capability.h — и вы уви- дите, что это вполне реально.
Для VServer было придумано несколько новых возможнос- тей: например, new_s_context, позволяющая создать новый контекст, а также set_ipv4root, способствующая «привязке»
всех процессов внутри контекста к одному IP-адресу. Кстати,
все эти ограничения распространяются и на потомков про- цессов. Однако новые возможности нельзя отключить обыч- ным способом, то есть мы «посадили» VServer в chroot/s_con- text/ipv4root, но «убежать» его процессы оттуда уже не смогут.
Таким образом, используя существующие и новые системы возможностей, мы можем сделать для VServer некую среду,
где root будет ограничен в своих правах и не сможет влиять на работу основного сервера.
Для работы с системой возможностей в состав vserver-utils входят утилиты reducecap и chcontext. Мы продемонстриру- ем, как функционируют они и работает сама система возмож- ностей, на конкретном примере.
|
Работаем с контекстами
|
Утилита chcontext позволяет зайти в определенный контекст безопасности, выделенный для VServer, и запустить программу,
указанную в качестве аргумента, с правами, ограниченными этим контекстом. Таким образом, эта программа уже не сможет видеть процессы, запущенные на основном сервере.
Например, запустим два окна с приложением (пусть это бу- дет xterm), с одинаковыми ID пользователя.
В первом окне зададим команду:
xterm
Во втором окне выполним chcontext, запускающую ко- мандную оболочку. Затем попробуем ввести pstree и обнару- жим, что видно нам совсем немногое. Потом попробуем
«убить» xterm, находящуюся в первом окне, и убедимся, что этого сделать нельзя. Теперь выходим из оболочки и возвра- щаемся к привычным возможностям.
Во втором окне укажем следующее:
/usr/sbin/chcontext /bin/sh
pstree
killall xterm
exit
Таким же образом можно порождать внутри контекстов другие контексты, которые будут к тому же изолированы друг от друга.
|
Понижаем возможности
|
Утилита reducecap позволяет ограничить количество возмож- ностей процесса и его субпроцессов. Даже программа setuid не сможет увеличить число возможностей, ограниченное с помощью reducecap.
Рассмотрим это ниже на конкретном примере:
# Мы сейчас не с правами root
# Посмотрим текущий потолок возможностей
ëÔËÒÓÍ ÔÓˆÂÒÒÓ‚ ̇ «Ó‰ËÚÂθÒÍÓÈ» ÒËÒÚÂÏ ‚ÏÂÒÚÂ
Ò Á‡ÔÛ˘ÂÌÌ˚ÏË ÔÓˆÂÒÒ‡ÏË Ì‡ VServer

2 / 2 0 0 5
L I N U X
|
C H I P
71
Ì ‡ Ò Ú  Ó È Í ‡ V S e r v e r
cat /proc/self/status
# Строка capBset показывает в основном 1
/usr/sbin/reducecap --secure /bin/sh
cat /proc/self/status
# capBset теперь показывает гораздо больше 0
# capEff теперь вся из 0, то есть у нас нет больше никаких
привилегий
# теперь попробуем стать root
su
cat /proc/self/status
# caEff содержит теперь гораздо меньше 0
# но попробуем проверить, root ли мы на самом деле
tail /var/log/messages
# это мы можем
/sbin/ifconfig eth0
/sbin/ifconfig eth0 down
# а это уже нет, таким образом, мы потеряли свои возможности
# супермена
exit
|
Работаем с VServer
|
Итак, после небольшого вступления попробуем поработать с
VServer. Для этого понадобится дистрибутив Linux (на базе
RPM или APT), ядро с vs-патчем и набор vserver-utils.
В дистрибутиве ALT Linux это может выглядеть таким образом:
# ставим ядро с поддержкой VServer
$ apt-get install kernel-image-vs-smp
# ставим утилиты для работы с VServer
$ apt-get install util-vserver
Теперь создадим наш маленький VServer:
$ vserver build
В данном случае — это произвольное имя виртуаль- ного сервера.
Далее утилита VServer создает структуру будущего виртуаль- ного сервера на базе текущего дистрибутива основного сервера.
Теперь зайдем в наш новый виртуальный сервер:
$ vserver enter
Здесь — также произвольное имя виртуального сервера.
После выполнения этой операции получаем стандартное приглашение командной оболочки, как будто бы мы зашли на этот сервер с клавиатуры. Редактируем конфигурацию по вкусу, не упуская из вида тот факт, что теперь у нас один
IP-адрес — и все службы, работающие на этом сервере, долж- ны быть привязаны только к нему.
Теперь запускаем наш VServer:
$ vserver start
И снова — произвольное имя виртуального сервера.
Теперь этот сервер доступен другим и может отвечать на за- просы извне (например, если запущен ssh, мы можем управ- лять им по ssh). Если возникнет необходимость остановить этот сервер, нужно просто набрать следующее:
vserver stop
В процессе создания VServer одноименная утилита запи- сывает в каталог /etc/vservers его конфигурацию, которая со- стоит из двух файлов: первый описывает общие параметры
(номер контекста, IP-адрес, включенные возможности),
а второй — порядок действий, выполняемых на этапе запус- ка/остановки. Для удобства обслуживания нескольких вирту- альных серверов существует скрипт init.d, позволяющий про- изводить их запуск или остановку выборочно. Существуют еще и утилиты для унификации содержимого VServer, про- смотра процессов, остановки/перезагрузки, а также многие другие. Все они входят в состав util-vserver или могут быть на- писаны самостоятельно, поскольку в основном это скрипты на языке командной оболочки.
|
Совместимость с другими
security-патчами
|
Предположим, вы создали виртуальный сервер и убедились,
что он работает, но все же чего-то не хватает. Все правильно,
полной уверенности не бывает. Ведь вы оградили себя систе- мой привилегий, возможностей, заперли всех в контексты,
но забыли самое главное — защиту «родительской» системы от самой себя и собственных ошибок. Переполнение буфера,
ненадежные права доступа, низкое качество кода выполняе- мых программ и ошибки ядра — все это осталось по-прежнему с вами: общие меры по защите никто не отменял. Обычно применяют патчи к ядру, исправляющие его код и добавляю- щие улучшения, связанные с безопасностью (например, патч
Openwall для ядер 2.4 и патч PaX для ядер 2.6). Также необ- ходимо соблюдать общие принципы безопасного админист- рирования — запрещать то, что не разрешено, и не включать то, что не нужно.
|
Аналоги и аналогии
|
Если вы хотите объяснить собеседнику что-то, о чем он не имеет совсем никакого представления, вы наверняка прибе- гаете к аналогиям. При описании VServer тоже сложно удер- жаться от этого метода повествования. Кажется, все, о чем здесь идет речь, вы уже где-то видели или слышали. Да, об- щие идеи витают в воздухе, поэтому неудивительно, что они приходят в головы разных людей почти одновременно. Мы
Накладываем ограничения
ä‚ÓÚ˚ Ë ÎËÏËÚ˚
На сегодняшний день для
VServer есть несколько пат-
чей (некоторые из них уже
вошли в нестабильную вер-
сию VServer для ядра 2.6),
позволяющих лимитировать
ресурсы, которые потреб-
ляются, во-первых, самим
сервером, а во-вторых,
пользователем внутри него.
Например, столь популяр-
ные дисковые квоты можно
использовать и внутри
VServer, а также задавать их
для каждого сервера в от-
дельности (при этом внутри
VServer дисковое простран-
ство будет ограничено
данной квотой). Можно ог-
раничивать количество за-
пущенных процессов внутри
VServer, задавать глобаль-
ный nice-уровень для всех
процессов и т. д. Кроме того,
есть возможность управлять
доступом к каталогу /proc,
что делает работу основного
сервера более безопасной.

72
C H I P
|
L I N U X
2 / 2 0 0 5
a d v a n c e d
‡ ‰ Ï Ë Ì Ë Ò Ú  Ë  Ó ‚ ‡ Ì Ë Â
же попытаемся понять, на что похож VServer, попутно расска- зывая об аналогичных технологиях.
|
Виртуальные машины
|
В чем-то VServer является виртуальной машиной, но у него нет типичных недостатков, присущих любым виртуальным машинам или эмуляторам:
3
Скорость работы. VServer действительно работает с той же скоростью, что и обычный железный сервер, так как в дан- ном случае ничто не эмулируется и не «подделывается». То есть, он требует не больше ресурсов, чем, скажем, VMWare или qemu. С другой стороны, в VServer не существует такого понятия как блочное устройство, но имеются раздел, память и процессор с сетевым интерфейсом: процессам обычно большего и не требуется.
3
Архитектура. Это слабое место VServer. Нет возможности ус- тановить Windows или FreeBSD — вы ограничены архитекту- рой, поддерживаемой «родительской» системой. Впрочем, не стоит забывать, что это не эмулятор.
3
Ядро. В VServer существует единое ядро для всех. Это обсто- ятельство можно рассматривать и как удобство (согласитесь,
лучше менять ядро одновременно на всех серверах сразу, чем переставлять на каждом отдельно), и как недостаток (по сравнению, скажем, с UML или Xen, о которых речь пойдет немного ниже).
3
Управление памятью и ресурсами. В Xen можно назначить на каждую машину даже свой планировщик, а в VServer один имеется лишь один планировщик. В тестируемой ветке для ядра версии 2.6 встречаются идеи того, как это можно сделать и для VServer.
3
Расширенный мониторинг процессов и потребляемых ресур- сов. Находится в стадии активной разработки, и скоро эти функции можно будет использовать в полной мере.
|
Проекты, похожие на VServer
|
|
VE — Virtual Evironment
|
Еще в 2001 году существовал интересный проект Virtual
Evironment, впоследствии переименованный в Virtuozo. Разра- батывала его компания SWSoft (та самая, которая подарила нам ASPLinux). Потом проект как-то тихо перестал развивать- ся — вполне возможно, его вытеснил User Mode Linux. Архив
VE или Virtuozo (aspcomplete/) можно найти в Интернете на странице Пола Слейдена, посвященной VServer и размещен- ной по адресу www.paul.sladen.org/vserver.
|
UML — User Mode Linux
|
Интересный проект, интересная идея. Можно запускать соб- ственные ядро и систему в рамках основной системы, пере- гружать и отлаживать это самое ядро и многое другое. Еще до появления непосредственно VServer данный проект часто использовался в образовательных целях, а также находил применение в сфере хостинга и отладки программного обес- печения. Фантазия ограничена только Linux. Подробную ин- формацию по данному вопросу можно найти в Сети по следу- ющему адресу: http://user-mode-linux.sourceforge.net.
|
VPS — Virtual Private Servers
|
Коммерческий проект, представляющий собой ответвление
VServer, целиком и полностью предназначенный для организа- ции хостинга на базе VPS. Ресурсы, ориентированные на хос- тинг с помощью VServer: OpenVPS (www.openvps.org) и FreeVPS
(www.freevps.com).
|
Xen — The Xen virtual machine monitor
|
По сути, это микроядро для Linux, позволяющее запускать яд- ра других ОС. Поддерживаются изоляция, ограничения и уп- равление ресурсами. Довольно интересный и многообещаю- щий проект (вполне годится в качестве замены Win4Lin или
VMWare ESX/GSX, так как имеет опыт успешной эксплуата- ции Windows в среде Xen). Подробная информация размещена на сайте www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html.
|
RAD GNU/Linux
|
Проект, поддерживаемый Петром Савельевым, целью которого является создание дистрибутива для маршрутизаторов — про- стого в настройке и чем-то похожего на системы Cisco. RAD
GNU/Linux является хорошим примером применения ALT
Linux Sisyphus для разработки дистрибутивов. В системе ис- пользуется технология VServer. Сайт: www.radlinux.org.
|
Заключение
|
В завершение хотелось бы привести цитату разработчиков
VServer, чтобы лучше понять, как они представляют себе бу- дущее этой технологии.
«Идея виртуального сервера интересна, поскольку позво- ляет достичь более высокого уровня безопасности и сокра- тить количество административных задач, необходимых для его обслуживания — например, обычных операций, таких как резервное копирование и обмен данными. Службы вроде мо- ниторинга можно настроить лишь единожды (так как физи- ческий сервер всего один).
Сервер на базе Linux может одновременно выполнять мно- жество задач с высоким уровнем надежности и доступности.
В процессе развертывания обычного сервера, как правило,
многие сталкиваются со стандартной проблемой, когда запу- скаются и устанавливаются различные сервисы и службы,
многие из которых не используются или используются редко.
В процессе работы конфигурация многих таких служб теряет- ся или забывается, и многие тайны настройки бывают утраче- ны (вроде как настроил и забыл). Поэтому при переезде на новый сервер всегда что-либо теряется (иногда что-то очень важное — например, почтовый ящик начальника). VServer ре- шает эту проблему: вы делаете установку только один раз, а в дальнейшем работаете только с каталогом этого сервера, ко- торый можно легко скопировать и перенести на любое новое место — от обычного раздела на жестком диске до LVM- страйпа на внешнем FC дисковом массиве».
Учитывая все выше изложенное, вывод напрашивается сам собой: VServer — наиболее удобный и предпочтитель- ный метод установки и использования сервера на базе опе- рационной системы Linux. |


Поделитесь с Вашими друзьями:


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал