 |
|
|
|
Новые средства OC FreeBSD 5
Новые средства ОС FreeBSD 5 Ни для кого не секрет, что OС FreeBSD является весьма популярной на productive-серверах. Причиной тому служит высокая степень защищенности «системы по умолчанию» (т.е. система изначально больше ориентирована на безопасность, чем на удобство для пользователя), очень высокая производительность, чрезвычайно удобная система портов и обновления системы (cvsup). Как и все *nix, FreeBSD изначально ориентирована на использование в сети, поэтому она содержит качественный стек протоколов TCP/IP, очень мощный пакетный фильтр ipfw и неплохую поддержку множества сетевых технологий и протоколов. Не так давно появившаяся 5 ветка (на момент написания этой статьи последней была версия 5.1, вышедшая 9.06.2003) FreeBSD явилась результатом почти трехлетнего труда разработчиков и, несомненно, отвечает требованиям времени. В 5 версии ОС FreeBSD появилось достаточно много нововведений по сравнению с 4 веткой системы. Из них стоит выделить такие, как поддержка ACPI, экспериментальная поддержка MAC (Mandatory Access Controls), новая версия файловой системы UFS – UFS2. В этой статье рассказывается о новых средствах, появившихся или получивших более качественную поддержку в 5 ветке FreeBSD. Начнем с особенностей файловой системы – UFS2. Учтите, что по умолчанию FreeBSD 5.0 создает разделы с файловой системой UFS1, для создания UFS2-раздела можно специально указать типы sysinstall или воспользоваться командой newfs следующим образом: # newfs -U -O2 /dev/ad0s3d где опция -U означает включение режима soft-updates (будет пояснено далее), а -O – выбор версии UFS. Какие же это средства и каково их применение? Итак, среди наиболее важных нововведений можно выделить следующие:
Что же означают последние два пункта? Начну по порядку. Итак, что прежде всего требуется от файловой системы? Надежность и скорость. Эти два критерия являются основополагающими, но, к сожалению, более надежная система часто является более медленной. Надежность файловых систем всегда была и будет объектом пристального внимания разработчиков. Представим себе традиционную файловую систему, например, fat или ext2. Наиболее слабым местом любой ФС являются операции записи, т.к. они изменяют содержимое нескольких областей диска. При записи файлов происходит 2 процесса записи: запись данных и запись метаданных (информации об имени файла, его смещении, режиме доступа и т. д.), при этом метаданные хранятся в начале диска. При традиционной схеме данные и метаданные записываются синхронно. То есть метаданные записываются уже «по факту» записи основных данных. Такая схема использовалась традиционно в ufs, т.к. является достаточно безопасной. Недостатком такой системы является очень медленное обновление метаданных, что может вызвать большие потери данных при непредвиденных ситуациях. В таком случае запускается fsck, и эта программа проверяет блоки, помеченные как «занятые», на правильность (т.е. всем занятым блокам должны соответствовать корректные метаданные, иначе такие блоки нужно отметить как «свободные»). Следующим шагом развития ФС явилась асинхронная запись (режим работы ext2 по умолчанию или ufs, монтированной с опцией async). При этом метаданные записываются сразу же после записи основных данных, что дает очень существенный выигрыш в скорости по сравнению с предыдущей системой, но при этом страдает надежность. Если же в процессе записи неожиданно произошел сбой (например, отключение питания), то часто метаданные бывают неверны или указывают на несуществующие данные. Для устранения неполадок в файловой системе запускается программа fsck, назначение которой в исследовании всех метаданных на валидность и проверке всех занятых блоков. Естественно, при такой схеме возможна весьма существенная потеря данных и, кроме этого, fsck выполняется довольно долго, т.к. необходимо проверить все метаданные и все занятые блоки. Файловые системы следующего типа (можно даже сказать поколения) используют так называемый журналируемый режим (ext3, ntfs, reiserfs), который подразумевает следующее: метаданные записываются синхронно с основными данными, но на специальную небольшую область диска – журнал, находящийся в быстродоступном месте. После записи данных метаданные переносятся в положенное место. При возникновении неполадок fsck проверяет валидность метаданных, находящихся в журнале и осуществляет перенос валидных inode в нужное место, а также удаляет неправильные метаданные. Эта схема намного более надежна, чем первая, т.к. нет риска порчи большого количества метаданных. Кроме этого, fsck выполняется очень быстро, т.к. осуществляется проверка лишь малой части диска. Главный недостаток журналируемых ФС – более низкая производительность, т.к. метаданные должны записываться дважды. Это особенно заметно на серверах, которые интенсивно оперируют с данными (почтовые серевра, сервера баз данных). Для устранения этого недостатка был разработан новый тип записи метаданных, который и применяется во FreeBSD 5.x. При такой схеме, называемой soft-updates, метаданные пишутся в синхронном режиме, но не на диск, а в оперативную память. Логично сказать, что операции с памятью на несколько порядков быстрее операций с диском. После записи данных метаданные в памяти записываются на диск (т.е. записываются лишь однажды) в определенном порядке (в отдельных случаях это дает прирост производительности на 70% (!)). Порядок записи метаданных определяется специальным алгоритмом, который определяет приоритет каждого блока метаданных в памяти. При возникновении сбоя система просто откатывается примерно на полминуты назад и продолжает работу в нормальном режиме (нет даже необходимости в запуске fsck, поэтому система может спокойно монтироваться, даже не будучи корректно отмонтированной). Единственная проблема в наличии блоков, которые помечены как «занятые», но которым не соответствуют метаданные. Для устранения таких блоков, являющихся по сути дела мусором, применяется фоновая проверка (bgfsck), которая запускается и работает, не мешая нормальной работе системы, освобождает неправильно помеченные блоки. В таком случае в результате сбоя происходит потеря метаданных, находящихся в памяти, что не очень существенно, т.к. преимуществ у такой схемы все равно больше. Главным образом это, конечно, высокая производительность. Система soft-updates представляет собой компромисс между оптимальной производительностью (практически как у асинхронных систем) и оптимальной надежностью (практически как у синхронных систем). По моему мнению, систему с soft-updates идеально применять на серверах, испытывающих большую нагрузку. Есть еще одна из реализаций технологии soft-updates, когда метаданные записываются в энергонезависимую память, что дает еще больший выигрыш в надежности (фактически надежность журналируемых ФС и скорость soft-updates). Главным минусом, безусловно, является недостаточная поддержка энергонезависимой памяти и необходимость разработки специальных алгоритмов восстановления. Еще одно преимущество, присутствующее в ffs, – снимки файловых систем, так называемые snapshots, которые позволяют оперировать с файлом снимка так, как если бы он был реальной файловой системой (об этом читайте подробнее на странице http://www.mckusick.com/softdep или в /usr/src/sys/ufs/ffs/README.snapshot). Итак, разобравшись с теоретическим аспектом вопроса, можно переходить к его реализации на практике. Для поддержки режима soft-updates необходимо добавить следующие параметры компиляции ядра: options FFS options SOFTUPDATES (во FreeBSD 5 включены по умолчанию). Для включения режима soft-updates во FreeBSD 5 можно воспользоваться 2 способами. Наиболее универсальным является применение tunefs или указание флага -U при создании ФС со помощью команды newfs. # tunefs -n enable /dev/ad0s3d # newfs -U -O2 /dev/ad0s3d Для работы tunefs необходимо размонтировать систему, что удобнее делать в single-user mode. Напомню, что для перехода в такой режим можно воспользоваться следующей командой: # shutdowm now Enter a path to shell or press Enter for /bin/sh ... # umount /usr # tunefs -n enable /dev/ad0s3d # logout После чего раздел будет примонтирован со включенным режимом soft-updates. Для корневой файловой системы лучше всего включить необходимые режимы на этапе установки системы (для этого в редакторе disklabel программы sysinstall необходимо нажать и указать опции newfs – -U -O2). Хочу отметить, что режим soft-updates может применяться и для UFS1, но файловая система UFS2 является, на мой взгляд, более совершенной и продуктивной, чем UFS1, поэтому я не вижу причин для использования UFS1 (кроме, пожалуй, испытанности временем). Чтобы увидеть, в каком режиме работает та или иная файловая система, достаточно просто вызвать mount без аргументов: cebka/usr/src$ mount
Другая весьма полезная возможность, нашедшая применение во FreeBSD 5.0, – это возможность создания списков доступа (acl) к файловым объектам. Любой, кто работал с системой безопасности WinNT, сталкивался с подобной технологией. Отличие списков доступа от традиционной системы защиты файлов Unix, когда все пользователи разграничиваются на владельца, группу владельца и всех остальных, в возможности задания определённым группам и/или пользователям собственных прав доступа. Это выглядит следующим образом:
в первом случае владелец имеет право чтения и записи, группа – право чтения, остальные доступа к файлу не имеют; во втором случае наблюдается похожая ситуация, но доступ на запись к файлу имеет не только владелец, но и некий пользователь wheel_adm. На первый взгляд отличия не так велики, но система acls очень гибко управляет доступом к файлам, позволяя строить произвольные списки доступа, разграничивая права различных пользователей и групп. Для включения поддержки acls нужно включить следущую опцию компилирования ядра: options UFS_ACL (во FreeBSD 5 включена по умолчанию). Разберемся, как управлять списками доступа на практике. Сразу же отмечу, что использовать acls лучше всего на UFS2-системе, т.к. она была разработана с учетом данной технологии, в отличие от UFS1, где использовать списки доступа можно, но не рекомендуется. Итак, чтобы включить acls на файловой системе, можно воспользоваться несколькими путями: использовать tunefs (наиболее надежный способ, но требуется размонтирование ФС): # tunefs -a enable /dev/ad0s3d использовать опцию монтирования acls (лучше всего прописать в /etc/fstab): /dev/ad0s3d /usr ufs rw,acls 1 1 Примечание: хотя об использовании этой опции говорится в FreeBSD Handbook, но у меня она (опция) отказалась работать наотрез – пришлось использовать tunefs в single-user mode (для использования tunefs корневой системы я использовал аварийный диск, т.к. иначе отмонтировать невозможно). Для проверки введите mount без параметров: cebka/usr/src$ mount
Для просмотра acl для файла или каталога (будут показаны UNIX-права доступа к файлу, который не имеет расширенных атрибутов acl) используется команда getfacl: вывод прав доступа к файлу в «классическом» стиле UNIX: cebka /home/cebka$ ls -l test1
вывод прав доступа в виде acl: cebka /home/cebka$ getfacl test1 #file:test1 <-- имя файла #owner:0 <-- владелец( UID) #group:0 <-- группа (GID) user::rw- <-- права владельца (пользователь по умолчанию) group::r-- <-- права группы (группа-владелец по умолчанию) other::r-- <-- права всех остальных Как видно из примера, если имя пользователя или группы не указано, то подразумевается, что это пользователь или группа-владельцы файла. Естественно, что просматривать расширенные атрибуты для обычных файлов неинтересно, поэтому попробуем установить файлу «экзотические» атрибуты, которые нам позволяет использовать технология acls. Для этой цели используется команда setfacl (а вы как подумали?), для добавления нового режима доступа используется опция -m: # touch /tmp/test.tmp && chmod 0600 /tmp/test.tmp # setfacl -m user:test:rw,group:test:r /tmp/test.tmp этой командой были разрешены запись и чтение пользователю test и чтение группе test. В общем формат acl таков: «класс (пользователь(user), группа(group), others маска(mask)):наименование (имя для пользователя или группы, пустое поле означает объект по умолчанию (владелец файла для user и group), всегда используется для классов mask и others):права доступа (обычные права доступа в стиле UNIX)». Проверяем атрибуты файла: # getfacl /tmp/test.tmp #file:/tmp/test.tmp #owner:1 #group:1 user::rw- user:test:rw- group::—- group:test:r— mask::rw- <— максимальный режим доступа для «обычных» пользователей (не владелец) other::—- # su test $ cat > /tmp/test.tmp test ^D $ cat /tmp/test.tmp test Как видите, пользователь test имеет право записи и чтения из файла /tmp/test.tmp, обратите также внимание на вывод команды ls: # ls -l /tmp/test.tmp
Символ «+» означает наличие расширенных атрибутов в виде acl. Команда setfacl также используется для удаления специфических прав, для этого используется опция -x, которая с точностью до наоборот похожа на опцию -m. Также существует возможность чтения списка доступа из файла, что указывается опциями -M file и -X file соответственно. Полезной мне также показалась опция -b, которая удаляет все права доступа, кроме трех стандартных Unix-объектов (владелец, группа, остальные). Итак, как выяснилось, acl – очень полезная технология. Для тех кто не может пока представить себе, зачем это нужно, приведу несколько конкретных примеров:
# chown root:wheel example.key # chmod 000 example.key # setfacl user:bind:r example.key
Вывод: acls – очень полезное средство управления файлами и каталогами. Напоследок я бы хотел сказать несколько слов о технологии MAC, взятой разработчиками FreeBSD 5.0 из проекта TrustedBSD (www.trustedbsd.org). Что же может дать нам эта технология, и вообще, что она из себя представляет? Итак, в традиционном UNIX используются принципы равноправия всех пользовательских объектов, то есть пользователь может получить доступ к системным объектам, которые принадлежат ему. Технология MAC предполагает наличие метки уровня безопасности для любого системного объекта (под этим термином предполагаются процессы, файлы и каталоги, устройства, пользователи и т. п.) и строгого разграничения доступа между различными уровнями (определяется выбранным модулем MAC); для поддержки технологии MAC нужно указать опцию компиляции ядра: options MAС Сама система MAC состоит из набора модулей, выполняющих различные функции, из них можно выделить как и те, что реализуют политику разграничения доступа (mac_biba, mac_mls, mac_lomac) так и те, что выполняют разнообразные служебные функции. Для ознакомления с модулями системы MAC я направляю читателя к FreeBSD Handbook, так как там все описано достаточно подробно и нет смысла приводить здесь кучу материала, который уже есть в разжеванном виде. Далее я просто хочу немного поделиться впечатлениями от использования данной системы. Итак, я скомпилировал ядро с поддержкой всех MAC-модулей и поправил /boot/defaults/loader.conf для загрузки модулей при старте системы (дело в том, что многие модули не могут быть загружены во время работы системы и, в первую очередь, это модули, выполняющие разграничение уровней безопасности). Больше всего меня привлек модуль mac_bsdextended, позволяющий создавать правила для доступа к файловым объектам в стиле ipfw, но, к моему сожалению, команда: # ugidfw set 1 subject uid 1002 gid 1002 object uid 1 gid 1 mode arsw которая должна разрешить чтение, запись, смену атрибутов и административные полномочия (параметр mode arsw) для пользователя (subject) 1002:1002 над файловыми объектами, принадлежащими (object) пользователю и группе daemon, почему-то не сработала должным образом. Далее я проверил работу модуля блокировки интерфейсов mac_ifoff, который блокирует сетевые интерфейсы до их явного включения посредством sysctl. Этот модуль действительно работает так, как сказано в man 4 mac_ifoff – модуль предотвращает «забивание» очереди интерфейса на этапе загрузки системы простым путем – не давая проходить пакетам до явного использования команды: # sysctl security.mac.ifoff.other_enabled=1 Из политик, предусматривающих установку меток безопасности я отметил некоторую их громоздкость, хотя идея мне понравилась. Например, хотим сделать так, чтобы пользователи не имели доступа к процессам login-группы bind, а также отделить группу user. Идем в файл login.conf (просмотрев предварительно man 7 maclabel) и пишем что-нибудь подобное, выполняя разграничение классов: default: ---cutted--- :label=partition/1 bind: :label=partition/2 user: :label=partition/3 В данном примере пользователям с данным login-классом устанавливается метка модуля mac_partition, позволяющего выделить до 65535 групп процессов, определяемых номером, изолированных друг от друга в адресном пространстве (видны только процессы текущей группы). Использовать метки в принципе не так уж и сложно, проблемы могут возникнуть только со сложными метками (например, mac_biba), но информацию по формату меток легко получить из соответствующей страницы man. Учтите, что для установки меток mac-файлам используется команда setfmac label file [file2] ..., имеющая полезную опцию -R (рекурсивность обработки каталогов). Помимо этого для установки меток для процессов используется команда setpmac label command, запускающая процесс comand с меткой label. Для управления сетевыми интерфейсами используется опция ifconfig maclabel label. Для тех, кто решил воспользоваться преимуществами технологии MAC, я настоятельно рекомендую почитать страницу руководства maclabel(7), где достаточно понятно объясняется формат MAC-метки. Также полезной для рассмотрения является страница mac(4), где приводится список MAC-модулей и соответствующих man-pages. На этом я, пожалуй, завершу свое краткое описание технологии MAC (на самом деле технология MAC находится в стадии развития, поэтому детально все описывать не имеет смысла, т.к. в скором времени, возможно, изменится многое). Одно я могу сказать точно: у технологии MAC, несмотря на некоторую сложность, есть будущее, особенно если учесть тот факт, что существуют коммерческие решения, обеспечивающие те же принципы. А MAC бесплатна в рамках FreeBSD, что тоже немаловажно. Но самое главное – это новый подход к модели безопасности системы, позволяющий отделить критические объекты от остальных, повысив защищенность первых от последних (см. описания модулей mac_mls и mac_biba). Особенно мне интересной показалась идея файлового брандмауэра, хотя у меня она и не заработала. Остается только надеяться, что в будущих версиях MAC выберется из состояния «экспериментальная», будет более тесно интегрирована с системой и появятся новые удобные инструменты (впрочем, никому не возбраняется участвовать в их создании). Но пока я бы не рекомендовал использовать ее на productive-серверах, т.к. код еще сырой. Вывод всей статьи: FreeBSD 5 – это система, вобравшая в себя множество преимуществ и практически не имеющая (на мой взгляд) недостатков. Полезные ссылки на различные документы:
|
ВСЕВОЛОД СТАХОВКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
