Модуль parsec astra linux

Настройка разрешений PARSEC (Astra Linux)

В системах, оснащенных подсистемой безопасности PARSEC (система управления мандатным доступом) из-за разности уровней привилегий, необходимых для доступа к файлам, монитор SpIDer Guard в режиме работы по умолчанию ( Mode = AUTO ) не может перехватывать события о доступе к файлам с более высокими уровнями привилегий, нежели уровень привилегий, на котором запущен SpIDer Guard. Кроме того, в случае если пользователь работает на отличном от нуля уровне привилегий, утилита управления Dr.Web для файловых серверов UNIX из командной строки Dr.Web Ctl не может взаимодействовать с монитором SpIDer Guard и демоном управления конфигурацией Dr.Web ConfigD , работающими на других уровнях привилегий, в том числе может отсутствовать доступ к консолидированному карантину .

Для настройки разрешений необходимы права суперпользователя (пользователя root ). Для получения прав суперпользователя воспользуйтесь командой смены пользователя su или командой выполнения от имени другого пользователя sudo .

Настройка SpIDer Guard для перехвата событий доступа к файлам с любым уровнем привилегий

Для предоставления файловому монитору SpIDer Guard возможности обнаруживать доступ к файлам, имеющим любой уровень привилегий доступа, необходимо перевести SpIDer Guard в режим работы LKM (будет использован специальный загружаемый модуль ядра Linux , поставляемый совместно с Dr.Web для файловых серверов UNIX ).

Чтобы перевести SpIDer Guard в режим работы LKM , выполните следующую команду :

# drweb-ctl cfset LinuxSpider.Mode LKM

Для получения дополнительной информации используйте команду:

Настройка корректного запуска Dr.Web для файловых серверов UNIX на любом уровне привилегий

Чтобы все компоненты Dr.Web для файловых серверов UNIX корректно взаимодействовали между собой при их запуске на разных уровнях привилегий, внесите изменения в сценарий запуска демона управления конфигурацией Dr.Web ConfigD ( drweb-configd ):

1. Совершите вход в систему с использованием нулевого уровня привилегий.

2. В любом текстовом редакторе откройте файл сценария /etc/init.d/drweb-configd (необходимы права суперпользователя).

3. Найдите в этом файле определение функции start_daemon , в которой замените строку

«$DAEMON» -d -p «$PIDFILE» >/dev/null 2>&1

execaps -c 0x100 — «$DAEMON» -d -p «$PIDFILE» >/dev/null 2>&1

4. В некоторых ОС (например, Astra Linux SE 1.3) может потребоваться указать дополнительно зависимость запуска компонента от подсистемы PARSEC . В этом случае также необходимо модифицировать в этом файле строку:

# Required-Start: $local_fs $network

Измените данную строку следующим образом:

# Required-Start: $local_fs $network parsec

Источник

Модуль parsec astra linux

Настройка разрешений PARSEC (Astra Linux SE)

В дистрибутивах Linux, оснащённых подсистемой безопасности PARSEC , доступ приложений к файлам зависит от уровня привилегий. Поэтому по умолчанию SpIDer Guard может перехватывать события доступа к файлам ровно в той мере, в которой это предусмотрено его уровнем привилегий.

Кроме того, в случае если пользователь работает на отличном от нуля уровне привилегий, интерфейс пользователя Dr.Web для Linux не может взаимодействовать со SpIDer Guard и сервисными компонентами антивируса, работающими на других уровнях привилегий, в том числе может отсутствовать доступ к консолидированному карантину .

Если в ОС используется PARSEC и имеются учетные записи пользователей, работающих на уровнях привилегий, отличных от нулевого, необходимо выполнить специальную настройку Dr.Web для Linux, чтобы обеспечить взаимодействие его компонентов, запускаемых на различных уровнях привилегий.

В этом разделе рассматриваются следующие настройки PARSEC , обеспечивающие корректную работу Dr.Web для Linux:

• Настройка взаимодействия компонентов, запущенных на разных уровнях привилегий.

• Настройка автоматического запуска компонентов Dr.Web для Linux на уровне привилегий пользователя.

• Настройка SpIDer Guard для перехвата событий доступа к файлам.

Для осуществления этих операций необходимы права суперпользователя (пользователя root ). Для получения прав суперпользователя воспользуйтесь командой смены пользователя su или командой выполнения от имени другого пользователя sudo .

Настройка взаимодействия компонентов, запущенных на разных уровнях привилегий

Для ОС Astra Linux SE версии 1.6:

Внесите изменения в системный файл /etc/parsec/privsock.conf , наделив демон управления конфигурацией Dr.Web для Linux ( drweb-configd ) правом на использование механизма privsock . drweb-configd — сервисный компонент Dr.Web для Linux, обеспечивающий взаимодействие всех антивирусных компонентов между собой. Механизм privsock предназначен для обеспечения функционирования системных сетевых сервисов, не осуществляющих обработку информации с использованием мандатного контекста, но взаимодействующих с процессами, работающими в мандатном контексте субъекта доступа. Для этого выполните следующее:

1. В любом текстовом редакторе откройте файл /etc/parsec/privsock.conf . Добавьте в этот файл указанные строки:

2. Сохраните файл и перезагрузите систему.

Для ОС Astra Linux SE версии 1.5 и менее:

Внесите изменения в сценарий запуска демона управления конфигурацией Dr.Web для Linux ( drweb-configd ). Для этого выполните следующее:

1. Совершите вход в систему с использованием учетной записи, обладающей нулевым уровнем привилегий.

2. В любом текстовом редакторе откройте файл сценария /etc/init.d/drweb-configd .

3. Найдите в этом файле определение функции start_daemon() , в которой замените строку

«$DAEMON» -d -p «$PIDFILE» >/dev/null 2>&1

execaps -c 0x100 — «$DAEMON» -d -p «$PIDFILE» >/dev/null 2>&1

# Required-Start: $local_fs $network

Измените данную строку следующим образом:

# Required-Start: $local_fs $network parsec

5. Сохраните файл и перезапустите систему.

Настройка автоматического запуска компонентов на уровне привилегий пользователя

Для того, чтобы компоненты Dr.Web для Linux, с которыми взаимодействует пользователь, были доступны в его окружении (при работе пользователя на уровне привилегий, отличном от нулевого), внесите изменения в файлы настроек PAM для автоматического запуска требуемых компонентов Dr.Web для Linux при начале сессии пользователя и их завершения при окончании сессии (используется специальный PAM-модуль pam_drweb_session.so , разработанный «Доктор Веб», который запускает компонент-посредник drweb-session , связывающий между собой локальные копии компонентов, запущенных в окружении пользователя, с компонентами, работающими на нулевом уровне привилегий и запускающимися автоматически при загрузке ОС).

Для внесения изменений в настройки PAM вы можете использовать утилиту конфигурирования drweb-configure , входящую в состав Dr.Web для Linux (рекомендуется), либо внести изменения в необходимые файлы конфигурации вручную.

1. Использование утилиты drweb-configure

Для удобства настройки некоторых сложных параметров, обеспечивающих работоспособность Dr.Web для Linux, разработана специальная вспомогательная утилита drweb-configure .

1. Для включения или отключения автоматического запуска необходимых компонентов Dr.Web для Linux в окружении пользователя при его работе на уровне привилегий, отличном от нулевого, используйте следующую команду:

$ sudo drweb-configure session

где может принимать одно из следующих значений:

• enable — включить режим автоматического запуска нужных компонентов в сессии пользователя на его уровне привилегий.

• disable — отключить режим автоматического запуска нужных компонентов в сессии пользователя на его уровне привилегий (при этом ряд функций Dr.Web для Linux окажется недоступным).

2. Перезапустите систему.

Для получения справки по использованию drweb-configure для настройки PAM используйте команду:

$ drweb-configure —help session

2. Изменение файлов конфигурации PAM вручную

1. В файлы конфигурации PAM (расположены в каталоге /etc/pam.d ), в которых вызывается модуль PAM pam_parsec_mac.so , добавьте следующие записи типа session :

• Перед первой записью типа session :

session optional pam_drweb_session.so type=close

• После последней записи типа session :

session optional pam_drweb_session.so type=open

2. Сохраните измененные файлы.

3. Создайте символическую ссылку на файл pam_drweb_session.so из системного каталога, содержащего PAM-модули. Файл pam_drweb_session.so располагается в каталоге библиотек Dr.Web для Linux /opt/drweb.com/lib/ (например, для 64-разрядных ОС — в каталоге /opt/drweb.com/lib/ x86_64-linux-gnu/pam/ ).

4. Перезапустите систему.

Настройка SpIDer Guard для перехвата событий доступа к файлам

Чтобы перевести SpIDer Guard в режим работы Fanotify , выполните следующую команду :

# drweb-ctl cfset LinuxSpider.Mode Fanotify

Для получения дополнительной информации используйте команду:

Источник

«Хакер» — Русский бронированный Debian. Как устроена новая модель управления доступом в Astra Linux SE

Источник статьи: https://xakep.ru/2015/09/15/astra-linux-se/

От редакции

Россия, как известно, родина слонов. А также ракетных комплексов, подводных лодок, танков и, как оказалось, не менее бронированных операционных систем. Если ты рубишь в ИБ и живешь в России, то это как раз тот вид вооружений, которым ты можешь интересоваться и даже гордиться. Astra Linux SE — одна из таких ОС. Наш автор Евгений Лебеденко — специалист по таким системам, так что приготовься взглянуть на безопасность в Linux с самой серьезной стороны!

Операционные системы сегодня — это не просто набор служебных функций, который позволяет компьютеру работать. Операционки стали играть огромную роль в мире потребительской электроники: Microsoft приспосабливает Windows для всех возможных устройств, Apple экспериментирует с интерфейсом мобильных и десктопных систем, Google развивает Android и одновременно превращает в операционную систему Chrome.

В корпоративной среде прогресс ОС тоже идет по полной: программно-конфигурируемые сети (SDN), виртуальные серверы, глобальные и частные облака. Здесь на первый план выходит не юзабилити, а защищенность и соответствие жестким требованиям к безопасности.

Есть и еще одна область, в которой защита превыше всего, — это ОС для государственных и военных нужд. Это еще один параллельный мир операционных систем — безумно консервативный, но и в нем существует прогресс. Причем не только за рубежом, но и у нас. Показательный пример — это дистрибутив Astra Linux SE.

Пять лет. Полет нормальный

Astra Linux — не единственный российский защищенный дистрибутив. Есть и другие, и все они успешно прошли проверку в органах сертификации и нашли свои рыночные ниши. Детище НПО «РусБИТех» — не исключение. Astra Linux SE с завидной регулярностью получает сертификаты соответствия в системах сертификации ФСТЭК, Министерства обороны и ФСБ. Действующие на настоящий момент версии имеют «срок годности» до 2018 года.

На основе Astra Linux развернуты и функционируют десятки информационных систем — как в государственных, так и в коммерческих структурах. Среди них, например, такие крупные, как защищенная платформа для государственной автоматизированной системы гособоронзаказа.

В составе дистрибутива Astra Linux SE есть все необходимое, чтобы развернуть защищенную инфраструктуру

Astra Linux отметился и в популярной ныне теме импортозамещения. Вполне вероятно, что органы госвласти самого «санкционированного» российского региона — Республики Крым — будут использовать эту ОС в качестве базы для своей инфраструктуры ИТ. В общем, менеджерам «РусБИТех» есть чем гордиться. Но нас, конечно, больше всего интересуют не те достижения, что связаны с продажами и историями успеха.

Первый релиз Astra Linux вышел в конце 2009 года. С тех пор дистрибутив совершенствуется, следуя за основной веткой Debian, но при этом разработчики не забывают о главном — повышенной безопасности. Предприятие «РусБИТех» неплохо оснащено научными кадрами и при этом ведет активное сотрудничество с вузами и исследовательскими институтами, которые специализируются на информационной безопасности.

Черты, которые делают Astra Linux 1.4 уникальным, относятся как раз к этой теме. В фирменной подсистеме безопасности PARSEC используется формальная модель разграничения доступа. Она была разработана в Институте криптографии, связи и информатики Академии ФСБ России, а в оценке качества принял участие Центр верификации ОС Linux Института системного программирования РАН. Реализация этой модели в Astra Linux SE ведется поэтапно, и в версии 1.4 добавлена большая ее часть, но еще не последняя.

MAC в LSM. Далеко не фастфуд в управлении доступом

Прежде чем разбирать модель разграничения доступа в Astra Linux SE 1.4, следует вспомнить некоторые основы. Очевидно, что пользователям информационных систем требуется доступ к данным, а также к набору механизмов ОС, которые обеспечивают этот доступ, — например, к файловым системам и стекам сетевых протоколов.

Именно поэтому в моделях разграничения доступа пользователей именуют субъектами доступа. На самом деле доступ к данным пользователь получает не лично, а через программы, которые «переваривают» эти данные. Именно они и являются настоящими (действительным) субъектами доступа и представляют зарегистрированного в системе пользователя (номинального субъекта). Совокупность программ, которые получают доступ к данным в течение сеанса работы зарегистрированного пользователя, обычно именуется субъект-сессией.

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

Задача любой модели разграничения доступа — определить, разрешить (allow) доступ к тем или иным объектам для тех или иных субъектов (субъект-сессий) или отказать (deny) в нем в соответствии с правилами. Если коротко, любая модель разграничения доступа задает некоторые отношения между субъектами и объектами доступа.

Базовая (как говорится, «из коробки») модель безопасности в GNU/Linux — это DAC, дискреционная модель доступа (discretionary access control). Она представляет собой комбинацию произвольного управления доступом (субъект-субъектная модель) и доступа на основе списков (ACL — Access Control Lists).

Субъект-субъектная модель подразумевает, что каждому объекту сопоставляется один субъект — владелец объекта. Он наделен правом давать или отнимать доступ к этому объекту другим субъектам. ACL — это таблица, объединяющая субъекты и объекты доступа при помощи перечисления прав, которыми субъект обладает в отношении объекта.

В общем виде модель DAC в GNU/Linux соответствует «виртуальному» стандарту POSIX ACL (настоящая стандартизация POSIX.1e и POSIX.2с была свернута в силу безбрежности стандартизуемой предметной области) и для большинства случаев вполне подходит на роль «диспетчера доступа» субъектов к объектам.

В DAC-модели Astra Linux SE используется полновесная поддержка стандарта POSIX ACL

Однако защищенные операционные системы — это не «большинство случаев». Одно из важных требований, предъявляемых к ним органами сертификации, — это реализация принудительного контроля доступа, который устраняет определенный волюнтаризм модели DAC. Как и в некомпьютерном секретном делопроизводстве, модель принудительного управления доступом основана на сопоставлении меток конфиденциальности, присвоенных объектам доступа, с официальным разрешением (допуском, мандатом) субъекта. Именно это «официальное разрешение» (мандат) дало такой модели название MAC (Mandatory access control) — мандатное управление доступом.

В GNU/Linux попытки расширения DAC-модели безопасности MAC-моделью предпринимались с 2001 года. Именно тогда АНБ США показало первую версию SELinux с реализацией мандатного управления доступом на основе формальной модели MLS (Multilevel Security). Было предложено включить MLS в состав ядра версии 2.5. Благо сообщество разработчиков Linux такое решение отвергло. Наряду с SELinux похожие реализации MAC-модели разрабатывались в рамках проекта AppArmor и, позже, — в Smack, TOMOYO и других. С какой стати отдавать предпочтение какому-то одному из них?

Вместо жесткой интеграции MAC-модели в состав ядра было принято соломоново решение: использовать расширение модели безопасности GNU/Linux. Она продолжит базироваться на модели DAC, но с использованием особых модулей ядра. В них можно реализовать какой угодно вариант модели управления доступом. Это решение было претворено в жизнь в виде фреймворка LSM (Linux Security Modules), который официально включили в ядро Linux 2.6.

Идея LSM проста. На ключевые с точки зрения управления доступом функции ядра навешивается совокупность «крючков» — хуков (hooks). Они представляют собой интерфейсы подключения обработчиков из модуля LSM, которые вызываются в том случае, если нужен контроль доступа. То есть фреймворк LSM предоставляет разработчику модуля LSM возможность перехвата управления в ходе выполнения тех участков кода ядра, которые отвечают за реализацию доступа субъектов к объектам.

В ядро новой версии Astra Linux SE включен известный патч безопасности PaX, который обеспечивает возможность тонкой настройки разрешений для приложений при их работе со страничной памятью.

Прелесть такого подхода заключается в том, что внутри модуля LSM можно реализовать любую модель управления доступом — как общего назначения, так и с учетом специфических особенностей эксплуатации системы. Естественно, эффективность подхода LSM напрямую зависит от широты охвата хуками функций ядра Linux. Но с этим, судя по всему, проблем нет. С момента включения LSM в ядро 2.6 по настоящее время было реализовано около двухсот хуков, и их внедрение ведется параллельно с появлением новых функций ядра.

Фреймворк LSM не заменяет модель DAC — она остается «первой линией обороны». Обработка хуков LSM начинается только после успешного прохождения контроля доступа по линии DAC. Такая двухъярусность позволяет не перегружать функциями безопасности те системы, где это не нужно. Там можно попросту не использовать LSM.

Безопасность SELinux базируется как раз на модулях LSM, равно как все остальные рассмотренные выше проекты, которые реализуют мандатное управление доступом. Подсистема безопасности PARSEC, функционирующая в составе Astra Linux SE, — это тоже модуль LSM. И даже не один.

В Astra Linux SE подсистема безопасности PARSEC базируется на фреймворке LSM

XPARSEC

Подсистема безопасности PARSEC в Astra Linux SE 1.4 содержит модуль XPARSEC, благодаря которому сервер X.Org получает возможность определять привилегии клиента X.Org (программы с графическим интерфейсом) и передавать их с использованием модифицированного X-протокола менеджеру окон Fly-wm. Тот выполняет привилегированные операции во время запуска клиента X.Org с различными мандатными контекстами. При этом на рабочем столе Fly отображается:

мандатный контекст пользовательской сессии в системном лотке (область tray);
мандатный уровень каждого окна;
мандатный уровень всех приложений, размещенных на рабочем столе Fly;
уровень доверенности окна для локально и удаленно запущенных приложений (цвет рамки окна приложения).

В качестве DE в Astra Linux используется Fly — «брат по коду» KDE 4. В отличие от KDE, Fly — защищенная рабочая среда

Контроль доступа, контроль целостности и роли

Поскольку Astra Linux вовсю используется в разных проектах, связанных с обработкой информации различных уровней конфиденциальности, у разработчиков уже есть статистика, по которой можно судить о корректности реализации модели управления доступом. Не менее важны исследовательские работы, в которых формировались модели нарушителей в рамках известных уязвимостей информационной безопасности CVE (Common Vulnerabilities and Exposures).

Проверке подверглись известные «проблемы» модели Белла — Лападулы. К примеру, деклассификация — когда пользователь с высоким уровнем конфиденциальности случайно или намеренно помещает данные из объекта с соответствующей мандатной меткой в объект с меткой более низкого уровня. Или нарушение логики доступа к данным при обработке потока информации в распределенной среде.
Моделировалась и проблема компрометации субъекта доступа, в ходе которой повышается уровень его привилегий (включая получение привилегий PARSEC). В результате можно получить возможность управлять доступом к защищаемой информации.

Очевидное решение таких проблем — это модификация формальной модели управления доступом. В случае Linux это делается добавлением модулей LSM, которые реализуют систему PARSEC. Ее основой стала мандатная сущностно-ролевая ДП-модель. Разработка ведется в рамках научной школы в Институте криптографии, связи и информатики Академии ФСБ России.

Подсистема безопасности PARSEC — не только LSM-модули, в которых реализована та или иная модель управления доступом, но и «обвязка»: собственная файловая система parsecfs, конфигурационные файлы, демоны и утилиты

В общем случае эта модель относится к классу ДП-моделей, то есть моделей управления доступом (Д) и информационными потоками (П), в которых учитывается не только единичный акт доступа к данным, но и направления распространения потоков информации при выполнении операций над данными.

Кардинальное отличие мандатной сущностно-ролевой ДП-модели от «классики» MAC — это объединение мандатного и ролевого управления доступом. При этом традиционный подход (уровни конфиденциальности, категории безопасности) мандатной модели в ней усиливается применением мандатного же контроля целостности (MIC, Mandatory Integrity Control) — механизма, который нашел широкое применение в семействе операционных систем Windows, начиная с релизов Vista и Server 2008.

Мандатная сущностно-ролевая модель управления доступом в версии 1.4 Astra Linux SE относится к широкому классу ДП-моделей

Приоритет в мандатной сущностно-ролевой ДП-модели — это MAC-модель, усиленная ролевой моделью и моделью управления целостностью

Фактически управление целостностью (integrity) правильнее называть управлением уровнем доверия. К традиционной проверке целостности данных (например, на основе подсчета их контрольных сумм) механизм MIC отношения не имеет. Назначаемые объектам и субъектам доступа уровни доверия дополняют традиционную модель управления доступом и гарантируют, что субъекты с низким уровнем целостности (IL — Integrity Level) не могут влиять на объекты с более высоким уровнем целостности.

Реализация мандатной сущностно-ролевой модели в Astra Linux SE 1.4 поддерживает наличие двух уровней целостности: высокий (hi) и низкий (low). Этого достаточно для разделения субъектов и объектов доступа на доверенные и недоверенные. При этом переменная, которая определяет значение IL, может принимать одно из 255 значений. Это означает, что в последующих реализациях модели может появиться более чем один уровень целостности. Подобный подход используется в модели MIC операционных систем Windows, поддерживающей пять (от untrusted до system) значений IL.

Еще одна важная особенность мандатной сущностно-ролевой модели — это учет иерархичности организации как ряда объектов доступа, так и функций (ролей), выполняемых субъектами. Такой учет позволил отнести и подобные объекты, и роли субъектов доступа к единой категории «сущность». В рамках этой категории могут формироваться отношения иерархии. Например, каталог может считаться сущностью-контейнером. Размещенные в нем объекты — файлы и подкаталоги — будут для него дочерними сущностями.

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

Что дает учет иерархии сущностей? Например, совместно с моделями MAC и MIC он позволяет определять правила размещения обычных объектов-сущностей с разными мандатными метками и уровнями IL в сущности-контейнере с определенными мандатной меткой и уровнем IL. Именно эта возможность и используется в текущей реализации сущностно-ролевой модели путем добавления к DAC-, MAC- и MIC-атрибутам директорий (напомним, что это — сущности-контейнеры) дополнительных атрибутов ccnr и ccnri. Они ограничивают возможность размещения в контейнерах объектов с мандатными метками и уровнями целостности, которые превышают таковые у самой директории.

Чтобы создать дочерний объект в отмеченных подобным образом директориях, даже с мандатными метками и уровнями IL ниже, чем у «родителя», субъект должен иметь соответствующие PARSEC-привилегии. Равно как и для установки ненулевого значения указанных атрибутов. При этом установка этих атрибутов не мешает просмотру объектов внутри директории.

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

Правила разграничения доступа в мандатной сущностно-ролевой ДП-модели учитывают иерархическую организацию ряда сущностей-объектов доступа

Скрипт инициализации правил разграничения доступа для ключевых директорий корневой файловой системы Astra Linux SE

Реализовав в LSM-модулях PARSEC мандатную сущностно-ролевую ДП-модель, разработчики не забыли и о средствах ее администрирования. Ведь набор утилит мандатного управления доступом в Astra Linux SE 1.3 был ориентирован на традиционную MAC-модель и не учитывал рассмотренные выше новшества.

В версии 1.4 появилась совокупность утилит pdp-, которые поддерживают просмотр и модификацию как традиционных MAC-атрибутов (уровни и категории), так и MIC-атрибута (уровни целостности) и дополнительных атрибутов (ccnr, ccnri, ehole). Впрочем, утилиты из предыдущей версии никуда пока не делись и применяются, чтобы облегчить администраторам уже функционирующих информационных систем миграцию субъектов и объектов доступа на новую модель.

В настройках среды окружения нового варианта подсистемы PARSEC первую скрипку играют новые pdp-утилиты

Распространение абстракции «сущность» не только на объекты доступа, но и на роли, реализуемые субъектами, позволяет применить подобный подход и к иерархии «роль-контейнер» — «дочерняя роль». Правда, в реализации модели для Astra Linux SE 1.4 gjkysq переход к ролевому управлению не выполнен (сущности-контейнеры «административная роль» и «индивидуальная роль» еще пусты).

Сейчас вовсю идет разработка версии 1.5, где в полном объеме будет реализована главная особенность мандатной сущностно-ролевой модели — приоритетное выполнение требований мандатного управления доступом при реализации ролевого управления в сочетании с мандатным контролем целостности.

Следует еще задать вот какой вопрос: корректна ли новая, достаточно сложная и для понимания, и для реализации модель управления доступом? Не несет ли она на логическом уровне возможностей для несанкционированного доступа? Достоинство Astra Linux SE здесь в том, что корректность его решений проверяет научное сообщество. В частности, в процессе занят Центр верификации ОС Linux Института системного программирования РАН — там разрабатываются тесты и технологии тестирования как модулей ядра Linux, так и в целом инфраструктуры LSB (Linux System Base).

Так, Центром в рамках проекта Linux Deductive Verification на основе методологии дедуктивной верификации последовательных программ был разработан набор свободно распространяемых инструментов верификации — Astraver Toolset 1.0. Они помогают убедиться в корректности реализации LSM-модулей подсистемы PARSEC, которые поддерживают новую мандатную сущностно-ролевую модель. Они же помогут тестировать и будущие версии Astra Linux SE.

В tray-области рабочего стола Fly-wm для пользователя отображается его уровень конфиденциальности и категории безопасности

Файловый менеджер fly-fm отмечает цветовыми метками документы с разными MAC-атрибутами и цветной рамкой уровень доверенности окна приложения

Выводы

К отечественным системным программным разработкам, особенно если они ведутся на основе опенсорсных проектов, зачастую относятся с изрядной долей снисхождения. Мол, сложно ли? Любой сможет взять отовсюду понемногу и сделать нечто, выдаваемое за свое. Возможно, иногда так и есть. Но только не в области операционных систем специального назначения. Их разработка скрупулезна, а сертификация проходит не для галочки. Именно такой подход продемонстрирован в Astra Linux SE 1.4, и именно его можно ожидать в последующих версиях этой операционной системы специального назначения.

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник