Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Современное развитие человеческой цивилизации, вступившей в двадцать первый век, характеризуется наиболее интенсивным использованием компьютерных информационных технологий во всех сферах 11 страница



 

$ tune2fs -j /dev/hd?#

 

Она просто добавляет файл журнала /.journal в корневом каталоге модифицируемой файловой системы (если последняя не была размонтирована), или задействует для журнала скрытый inode (если перед модификацией файловая система была размонтирована). Добавлю, что обратное преобразование - еще проще, и осуществляется командой монтирования (о чем будет говориться в следующей статье).

 

Файловая система ReiserFS создается специально предназначенной для этого командой - /sbin/mkreiserfs из пакета reiserfsprogs. Для нее доступны многочисленные опции (-s для задания размера журнала, -f для принудительного переформатирования ранее существовавшей файловой системы иного типа, и т.д.), с которыми можно ознакомиться посредством man (8) mkreiserfs. И во избежание неожиданностей: если корневой раздел форматируется как ReiserFS, не лишним будет предусмотреть небольшой раздел под каталог /boot для размещения на нем файловой системы ext2fs.

 

Для создания XFS также существует собственная команда mkfs.xfs (из пакета xfsprogs). В ней предусмотрено несколько опций, каждая из которых имеет ряд субопций, принимающих численные значения. Важнейшие из них:

* -b, которая посредством субопции size=## позволяет задать размер блока данных в байтах, который должен быть кратен размеру страницы оперативной памяти (для платформы i386 - 4 Кбайт) и может варьировать в диапазоне от 512 до 65536 (по умолчанию - 4096);

* -d, определяющая параметры области данных файловой системы, такие, как количество самостоятельных областей раздела (Allocation groups, субопция agcount), или, напротив, их размер (субопция agsize);

* -l, специфицирующая параметры журнального файла, например, его размер (субопция size).

 

При использовании mkfs.xfs для достижения максимальной производительности рекомендуется в явном виде задать количество allocation groups - иначе оно будет определяться автоматически, что ведет к непроизводительным расходам ресурсов. Это делается из расчета - одна allocation group на 4 Гбайт дискового пространства. Далее можно установить размер файла журнала - здесь рекомендованное значение составляет 32 Мбайт. То есть для дискового раздела объемом в 20 Гбайт команда приобретет вид

 

$ mkfs.xfs -d agcount=5 -l size=32m /dev/hda1

 

Кроме всех перечисленных, команда mkfs.xfs имеет опцию -f (от force) - принудительное создание файловой системы XFS поверх любой существующей. Ее достаточно, если последняя была ext2fs (и, исходя из общих соображений, ext3fs, хотя я этого не проверял). Если же XFS создается поверх ReiserFS - после этого возможны ошибки при монтировании новой файловой системы. Впрочем, то же относится и к обратной процедуре (замене XFS на ReiserFS), а также, если любая из этих "продвинутых" файловых систем заменяется на разделе системой ext2fs. Они связаны с тем, что команда монтирования может распознать новосозданную XFS как дефектную ReiserFS, и наоборот.



 

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

 

$ dd if=/dev/zero of=/dev/hd?#

 

Ждать заполнения нулями всего устройства не обязательно - достаточно дать этой команде поработать секунд 10-20, после чего прервать ее комбинацией клавиш Control+D и перейти к созданию новых файловых систем.

 

И последнее, о чем следует сказать - о swap-разделе, созданном на этапе разбиения диска. Хотя файловой системы как таковой он не несет, но нуждается в определении, что достигается командой $ mkswap имя_устройства, к которой следует подходить со вниманием - применение ее к обычному разделу уничтожит на нем все данные.

14.1. Возможности стандартной системы разграничения доступа ОС Linux

 

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

 

Владельцы файлов

 

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

 

- владелец-пользователь не обязательно является членом группы-владельца;

 

- владельцем-пользователем нового файла является пользователь, что создал файл; владелец-группа нового файла определяется либо как первичная группа пользователя, что создал файл, либо как группа-владелец каталога, в котором создан файл;

 

- только владелец-пользователь может (и то не всегда, например, в BSD 4.x не может) передавать владение файлом другому пользователю и другой группе (последнее, только если он является членом текущей группы-владельца);

 

- только владелец-пользователь может изменять права доступа к файлу. Безусловно, все, что может владелец-пользователь, может и суперпользователь.

 

Права доступа к файлам

 

Права доступа к файлам задаются, обычно, в виде списков контроля доступа (СКД) (Access Control Lists - ACL). В этих списках для каждого возможного субъекта доступа определяется перечень операций, которые он может выполнить над файлом.

 

Под субъектами доступа понимают пользователей или группы пользователей.Определенные права определенным субъектам доступа (например, суперпользователь, владельцу) присваиваются по умолчанию:

 

Ø суперпользователь имеет все права;

 

Ø пользователь-владелец имеет право изменять явно указанные права доступа, атрибуты SUID, SGID и, возможно, передавать владение файлом другому пользователю или группе.

 

Явно определяются права на чтение (r), запись (w) и выполнение (x) для трех субъектов доступа: владельца-пользователя, владельца-группы, остальных пользователей. Семантика прав зависит от типа файла.В UNIX существуют такие типы файлов:

 

Ø обычные файлы (regular files);

 

Ø каталоги (directories);

 

Ø символические связки (symbolic links);

 

Ø файлы устройств (device files);

 

Ø именуемые каналы (named pipes);

 

Ø сокеты (sockets).

 

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

 

- право на чтение дает возможность получить имена файлов, что содержатся в каталоге (и только);

 

- право на запись дает возможность создавать и удалять файлы в каталоге;- право на выполнение дает возможность:

 

1) получить атрибуты файлов (если разрешенное чтение каталога);

 

2) получить доступ к файлам, что содержатся в каталоге (если такое право есть для всех каталогов на пути к данному).

 

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

 

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

 

14.2. Недостатки стандартной системы разграничения доступа ОС Linux

 

В ОС Linux в стандартной системе разграничения доступа можно выделить такие недостатки:

 

- избыточность полномочий суперпользователя;

 

- вторая проблема связана с необходимостью изменения текущего уровня привилегий пользователя для выполнения некоторых действий (например, для изменения пароля пользователю нужно временное разрешение на запись в файл /etc/shadow или аналогичный). Традиционно это достигалось путем установки флага SUID (или SGID) на файлы выполняемых модулей программ в результате чего, порождаемый при запуске такого файла процесс, приобретает не такие права, что запустил его пользователя, а права владельца файла.

 

- запуск всех фоновых системных процессов (демонов) процессом init() - прародителем всех процессов, с привилегиями суперпользователя, в результате чего системные серверы ОС (почтовый сервер, Samba сервер, FTP сервер, и тому подобное) работают от имени root’а.

 

14.3. Возможности наиболее известных средств совершенствования разграничения доступа ОС Linux Возможности системы LIDS

 

(Linux Intrusion Detection/Defence System – система выявления и защиты от вторжения)

 

LIDS - это Linux Intrusion Detection/Defence System - система выявления и защиты от вторжения. Это патч для ядра Linux, который добавляет много новых возможностей для повышения безопасности ОС целом. LIDS позволяет запретить или ограничить доступ к файлам и памяти, блочным устройствам, сетевым интерфейсам, запущенным программам и т.д. даже для root’а. Правильнее сказать, именно для root’а, поскольку ограничить доступ для простого пользователя можно и стандартными средствами Linux. Данная система предназначена для защиты от хакера, который воспользовавшись "дирою" в какой-либо программе, получил правая root’а.

 

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

 

LIDS обеспечивает следующую защиту:

 

* LIDS может защитить важные файлы и директории на вашем жестком диске независимо от типа файловой системы, так что никто (даже суперпользователь) не сможет их изменить. LIDS позволяет распределять права доступа к файлам, пристроил и т.д. на уровне программ, а не на уровне пользователей. Например, можно запретить доступ к файлу /etc/shadow для всех и вся так, что он даже при ls/etc видный не будет и дать к нему доступ на чтение программам /bin/login /bin/su на чтение-запись программе /usr/bin/password, то есть тем программам, которые действительно нуждаются.

 

* LIDS может также защитить важный процесс от уничтожения.

 

*LIDS может защитить любую операцию введения-выведения от несанкционированной программы. Она может также защитить ваш жесткий диск, включая защиту MBR.

 

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

 

* Посредством LIDS можно запретить загрузку/выгрузку модулей ядра, это защитит систему от запуска модулей-троянов, собранных хакером для собственных нехороших потребностей.

 

* LIDS позволяет запретить перезапуск системы, так что человек, что не находится у непосредственной близости от кнопке RESET, перезагрузить систему не сможет.

 

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

 

Когда кто-нибудь сканирует твою систему, LIDS может найти это и сообщить администратору. LIDS может также обратить внимание на любую деятельность (активность) в системе, которая нарушает правила.

 

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

 

В этом случае, LIDS может также выключить сеанс пользователя сразу.

 

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

 

Возможности системы RSBAC (Rule Set Based Access Control for Linux)

 

RSBAC (Rule Set Based Access Control for Linux - система управления доступом ОС Linux на основе набора правил) - это надстройка над ядром Linux, а также комплект утилит управления, который позволяет создать на базе любого дистрибутива Linux защищенную систему. Реализация механизмов обеспечения безопасности выполнена на уровне ядра системы и позволяет эффективно контролировать все процессы. Системные вызовы, что задевают безопасность, дополняются специальным кодом, что выполняет обращение на центральном компоненте RSBAC. Этот компонент принимает решение о допустимости данного системного вызова на основе многих параметров:

 

- типа приглашаемого доступа (чтение, запись, выполнение);

 

- субъекта доступа;- атрибутов субъекта доступа;

 

- объекта доступа;

 

- атрибутов объекта доступа.

 

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

 

В RSBAC включенные следующие модули, реализующие разные функции в модели управления доступом:

 

· MAC (Mandatory Access Control). Модуль MAC обеспечивает принудительное управление доступом на основе классической модели Белла-Лападули, цель которой - не допустить перетекания информации из более секретных объектов в менее секретные.

 

· FC (Functional Control). Данный модуль реализует простую ролевую модель, в которой доступ к системной информации разрешен только администраторам системы, а доступ к информации, связанной с безопасностью, разрешенный только офицерам безопасности.

 

· SIM (Security Information Modification). Модуль SIM обеспечивает возможность модификации данных, помеченных как «security information», только администраторами безопасности.

 

· PM (Privacy Model). Данный модуль реализует модель безопасности, направленную на обеспечение частности личных данных. Основная идея заключается в том, чтоб пользователь мог получить доступ к персональным данным только если они ему необходимы для выполнения текущей задачи и если он авторизован на ее выполнение. Кроме того, цель выполнения текущей задачи должна совпадать с целью, для которой эти данные собранные или должно быть получено согласие субъекта этих данных

 

.· MS (Malware Scan). Этот модуль обеспечивает сканирование всех файлов на наличие вредного кода. Дополнительно, данный модуль может контролировать все запросы на чтение файлов и соединений TCP/UDP. В текущей версии модуль умеет находить вирусы Bliss.A, Bliss.B, VHP-648, Israeli, Eddie2, Dark Avenger и 1704C.

 

· FF (File Flags). Модуль FF предоставляет механизм установки и проверки флагов на файлы и каталоги. Причем, модифицировать флаги разрешено только офицерам безопасности системы. Пока поддерживаются флаги execute_only (для файлов), read_only (для файлов и каталогов), search_only (для каталогов), secure_delete (для файлов), no_execute (для файлов) и add_inherited (для файлов и каталогов). Значение флагов ясное из их названия и, конечно, знакомое тем, кто пользовался механизмами атрибутов и прав в файловой системе Novell NetWare.

 

- RC (Role Compatibility). Данный модуль определяет 64 роли и 64 типа для каждого вида объекта. Виды объектов могут быть следующими: file, dir, dev, ipc (interprocess communication), scd (system control data), process. Для каждой роли отношения к разным типам и другим ролям настраивается индивидуально, в зависимости от вида запроса. Используя данный модуль, можно настроить разделение обязанностей, между администраторами избежав при этом назначения избыточных прав.

 

· AUTH (Authorization Enforcement). У этого модуля задача очень конкретная — контролировать запросы процессов на изменение текущего идентификатора пользователя. Под контролем данного модуля программе недостаточно просто иметь установленный бит suid ей необходимый специальный атрибут, что позволяет такое действие. Причем, он может быть, как глобальным (uid может быть изменен на ком-либо), так и учетным (процесс может изменить свой uid только на определенные).

 

· ACL (Access Control List). ACL - самый «прикладной модуль» из данного списка. Он определяет, какие субъекты могут получить доступ к данному объекту, и какие типы запросов им разрешены. Субъектом доступа может быть как простой пользователь, так и роль RC и/или группа ACL. Объекты группируются по видам, но каждый имеет собственный список ACL. Если права доступа к объекту не заданы явно, они наследовались от родительского объекта с учетом маски наследования прав. Эффективные права доступа субъекта к объекту состоят из прав, полученных непосредственно, и прав, полученных через назначение на роль или членство в группе ACL. Такой подход к назначению прав покажется очень знакомым специалистам, работающим с NetWare. Более того, утилита управления acl_grant имеет режим совместимости по названиям прав с аналогичной утилитой NetWare.

 

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

 

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

 

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

 

Таким образом, выполняется основная задача - жесткое разграничение доступа в системе. Аутентификацией и авторизацией RSBAC не занимается - с подобными задачами успешно исправляются другие средства.

 

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

 

RSBAC можно интегрировать с любым дистрибутивом Linux, необходимо лишь внести соответствующие исправления в начальные тексты ядра системы. Эта процедура осуществляется посредством стандартной утилиты patch из прилагаемого файла-«заплатки» который предлагается для разных версий ядра. После этого происходит его обычная настройка (make config, make menuconfig и т.д.), при этом в настройке появляется несколько новых пунктов. После загрузки ядра (а их рекомендуется собрать два: одно «боевое», а другое - наладочное, позволяющее проводить настройки свойств RSBAC, но с отключенными «сторожевыми функциями») настройка системы проводится посредством прикладных утилит администрирования. Настройка возможна как посредством иерархической системы меню, так и посредством командной строки с параметрами. Меню из страницы руководства представлены как на английской, так и на российской языках. Система обеспечена документацией с подборкой теоретических материалов, где описанные все модели защиты, что используются. Из основного сервера проекта RSBAC имеется ссылка на дополнительные материалы, среди которых имеется прекрасная статья с пошаговыми инструкциями по ознакомлению с системой, позволяющая благополучно миновать много «узких мест».

 

Возможности системы Security-Enhanced Linux

 

Вторая система - Security-Enhanced Linux имеет такое же назначение, как RSBAC и также является дополнениями к ядру с набором утилит.

 

Security-Enhanced Linux обеспечивает гибкую архитектуру принудительного контроля доступа (flexible mandatory асcess control architecture - FLASK) использующий развитой язык описания конфигураций политики безопасности. С использованием этого языка описаний разработанная конфигурация системы, что реализовывает идеологию Type Enforcement -это матрица доступа, организованная в классы эквивалентности. Так как обычная матрица доступа является двухмерной таблицей, по одной осе которой размещаются субъекты доступа (процессы, пользователи), по другой - объекты доступа (файлы, каталоги, устройства и другие ресурсы), а в ячейках на пересечении указываются операции, которые субъект может выполнять над объектом, то в системе с большим количеством сущностей построить такую матрицу может оказаться просто невозможным. Поэтому в данной системе объединяют объекты (похожих по свойствам) и субъекты (похожих по функциям) в классы эквивалентности и строят матрицу для классов, проведя, фактически, типизацию сущностей.

 

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

 

В политике безопасности также определенный набор ролей. Для пользователей первичная установка роли происходит в процедуре регистрации (login), а переключение роли - посредством команды newrole (в некотором роде аналог su). Системные процессы работают с ролью system_r, обычные пользователи — с ролью usr_r, а для системных администраторов зарезервированная роль sysadm_r.

 

Для каждой роли в политике безопасности задается набор доменов, в которых допускается работа с этой ролью. Всем предназначенным для пользователя ролям назначается стартовый домен: user_t для роли user_r и sysadm_t для роли sysadm_r. По мере выполнения программ, что запускаются из стартовой оболочки shell, может происходить автоматическое перемещение в другие домены для обеспечения изменения привилегий. Выбор домена, в который должно быть проведено перемещение осуществляется не только исходя из типа программы, что запускается, но и с учетом текущего домена. В частности, при запуске браузера Netscape обычным пользователем (текущий домен user_t), произойдет перемещение в домен user_netscape_t, а при запуске этой же программы администратором (текущий домен sysadm_t) перемещения произойдет в другой домен-sysadm_netscape_t. Такой подход не позволит программе выполнить потенциально опасные действия - соответствующий домен серьезно ограничит права администратора. В обычных дистрибутивах Linux в случае с браузером Netscape проблема развязывалась проще - в настройке по умолчанию программа просто не запускалась с правами root.

 

Для администраторов в Security-Enhanced Linux заданные достаточно жесткие ограничения. В частности, нельзя зайти в систему отдаленно - при необходимости такой процедуры необходимо сначала провести вход обычным пользователем, а затем переключаться на административную роль посредством команды newrole, что проводит дополнительную аутентификацию. Впрочем, и в большинстве современных Unix-подобных системах администратору также запрещенный отдаленный вход и для этой цели используется команда su. Пример с браузером не случайный - ему уделено особенное внимание в перечне цели политики безопасности. Во избежание выполнения браузером вредного динамического кода (Java-апплеты, сценарии JavaScript), для него определенный специальный домен (точнее, два домена — для пользователей и администраторов), что будет обмежевывать полномочие. Причем, определяются два подтипа: один ограничивает доступ браузера к локальным файлам только чтением, другой допускает запись в них. Политика безопасности должна контролировать разные формы прямого доступа к данным, поэтому в ней определяются разные типы для устройств памяти ядра (kernel memory device), дисковых устройств, специальных файлов в каталоге /proc, а также разные домены для процессов, которым необходимый доступ к этим ресурсам. Обеспечение целостности ядра достигается определением разных типов для загрузочных файлов, объектных файлов модулей, что подключаются, утилит для работы с модулями и файлов конфигурации модулей. Соответствующим процессам, которым нужное право записи в эти файлы, назначаются специальные домены.Системное ПО, файлы конфигурации и журналы также нуждаются в защите. Для этой цели также определяются отдельные типы для системных библиотек, выполняемых файлов, файлов конфигурации и журналов, а работающим с ними программам и ролям назначаются специальные домены.

 

Запись журналов может вести только система регистрации (syslog), а модификация системного ПО проводится только администраторами. Имеется решение и для уже упомянутой проблемы, свойственной программам с повышенными привилегиями (с установленными флагами suid или sgid). Для таких программ также назначаются отдельные домены, что не позволяют им превысить необходимые полномочия.

 

Политика безопасности уделяет особенное внимание тщательному разделению процессов по привилегиям и защита привилегированных процессов от выполнения ошибочного или опасного кода. Путем установки атрибута ехecutable только на необходимые для выполнения привилегированным процессом программы, политика безопасности может достичь того, что при входе в привилегированный домен процесса будет разрешено выполнение только стартовой программы для данного домена, динамического компоновщика и системных библиотек, что разделяются. Администратор ограничен выполнением системных программ и программ, созданных им самим — выполнение программ, созданных другими пользователями запрещено. Более того, система минимизирует взаимодействие между обычными предназначенными для пользователя процессами и системными. Только системным процессам и администраторам разрешенный доступ к записям в procfs, что относится к другим доменам; ограничено использование вызова ptrace по отношению к другим процессам и доставка сигналов между разными доменами. При использовании файловой системы также употреблены дополнительных мероприятий осторожности: домашние каталоги администраторов и обычных пользователей отнесены к разным типам; создаваемым в каталогах общего пользования (/tmp и др.) файлам также присваиваются разные типы, в зависимости от домена, который их создал.

 

14.4. Сравнительный анализ средств усовершенствования системы разграничения доступа ОС Linux

 

Сложность. Самой сложной системой является Security-Enhanced Linux (необходимости изучения специального языка конфигурации). Система RSBAC также сложная и это наибольшая ее проблема. Использование сложных моделей доступа требует очень четкого контроля по логике превращений и проверок доступа - малейшая ошибка и путем хитрых комбинаций система теряет контроль над ситуацией.


Дата добавления: 2015-08-27; просмотров: 150 | Нарушение авторских прав







mybiblioteka.su - 2015-2024 год. (0.029 сек.)







<== предыдущая лекция | следующая лекция ==>