Передача данных на уровень конфиденциальности вниз

Сообщения
5
#1
Наверное глупость спрошу, но есть необходимость с уровня например 1 передать воздействия на уровень 0, это исполнитель работающий по сети в QNX. Там нет сокетов с мандатным разграничением, да и информация транслируется без грифа уже после обработки многоуровневой информации. Понятно, что обработка должна выполняться на верхнем, а результат принятия решение не содержит ничего, кроме указания например закрыть или открыть дверь. Не могу понять, как в С решать такую задачу, да еще и пройти сертификацию в МО. Или все необходимо переводить на верхний уровень и менять ос рв на ос сн? Дополнительно вытекает вопрос, почему нигде нет доходчивого материала, как с помощью астры конструировать ас с разными классами. Есть огромный выбор средств и было бы хорошо, Если бы для каждого класса была книга типа red-book, где указывались минимальные настройки средств для того, чтобы решать задачи класса СВТ при сертификации МО, ФСТЭК. А так ос похожа на набор дров который каждый может прикручивать как знает и нет уверенности, что эти подходы соответствуют планам развития ОС и требованиям регуляторов.
 

oko

New member
Сообщения
189
#2
to Константин1977
Она такой и является - набором из книжки "сделай сам". И это нормально, потому что ОС (пусть и СН) - это всего лишь многофункциональный инструмент...
Текущая RedBook, кстати, содержит необходимый минимум требований для тюнинга ОС под АС 3-2 класса. Конкретика уже определяется, исходя из требований закрытых документов (и обсуждать ее тут несколько не с руки)...
Из вашего описания несколько не понятна суть проблемы. Раскройте тему. Если вопрос в чтении мандатных меток при их передаче по сети, то вам придется модифицировать QNX с целью поддержки соответствующего ГОСТ (разработанного РусБинТех, ага). Если же чтение меток не нужно (достаточно определять сам факт передачи данных и парсить их), то принимайте иные меры защиты этого процесса от воздействия сторонних лиц и внутренних нарушителей. Возможности определяются по факту анализа вашей АС (модуль экстрасенсорики перегревается, так что без комментариев)...

ЗЫ Слив информации с высокого мандатного уровня на низкий противоречит принципам мандатной политики. Вкупе с закреплением мандатных меток в исполнительной документации за конкретными грифами делопроизводства - это уже разглашение государственной тайны со всеми вытекающими...
 
Сообщения
5
#3
to Константин1977
Она такой и является - набором из книжки "сделай сам". И это нормально, потому что ОС (пусть и СН) - это всего лишь многофункциональный инструмент...
Текущая RedBook, кстати, содержит необходимый минимум требований для тюнинга ОС под АС 3-2 класса. Конкретика уже определяется, исходя из требований закрытых документов (и обсуждать ее тут несколько не с руки)...
Из вашего описания несколько не понятна суть проблемы. Раскройте тему. Если вопрос в чтении мандатных меток при их передаче по сети, то вам придется модифицировать QNX с целью поддержки соответствующего ГОСТ (разработанного РусБинТех, ага). Если же чтение меток не нужно (достаточно определять сам факт передачи данных и парсить их), то принимайте иные меры защиты этого процесса от воздействия сторонних лиц и внутренних нарушителей. Возможности определяются по факту анализа вашей АС (модуль экстрасенсорики перегревается, так что без комментариев)...

ЗЫ Слив информации с высокого мандатного уровня на низкий противоречит принципам мандатной политики. Вкупе с закреплением мандатных меток в исполнительной документации за конкретными грифами делопроизводства - это уже разглашение государственной тайны со всеми вытекающими...
У нас имеется оборудование, измерительное и исполнительное, подключаемое через сетевые интерфейсы в общем не поддерживающие мандатный механизм меток. Это ос рв и платы на микропроцессорах, работающих без операционных систем напрямую поддерживая стек необходимых tcp udp, ip, Arp, icmp. В этих интерфейсах гуляет инфа уровня 0, но никаких меток на уровне IP не поддерживает, потому как разработчику было ничего не известно про ЗИ. Но вот для принятия решения на нескольких операторских астрах в дело вступает некоторая информация уровня дсп, которая используется только в алгоритмах принятия решения. Процессы, который ее принимают также принимают информацию от тех самых каналов с уровнем 0. После выполнения некоторых алгоритмов и участия оператора принимается решение, которое по составу данных не является дсп и может быть выдано исполнителю удаленному по сетевым каналам. Получается, что с уровня дсп необходимо передать решение на уровень ниже и при этом замечательно было бы исключить мандатные метки, поскольку исполнитель не владеет механизмом мандатных меток. Но тут конфуз - правила запрещают передачу любых данных вниз по уровню. Это как если бы человеку, прочитавшему дсп запретили общаться со всеми, кто не имеет метки дсп, даже на бытовые темы. То Есть защищается не информация, а носитель информации. Я не пробовал пока писать код на с, для формирования потока на сервере, получившего запрос с уровнем 1. Подозреваю, что при попытке передать инфу через указатель между потоками с 1 в 0 будет сформировано какое-то прерывание, либо что-то будет блокировано средствами ос сн. Пока я хочу разобраться какие решения в этой области являются законными, ведь предстоит сертификация МО. Возможно есть вообще другие подходы в решении таких задач.
 

oko

New member
Сообщения
189
#4
to Константин1977
Для справки: пометка "Для служебного пользования" де юре имеет силу только для органов исполнительной власти, атомной промышленности и космической промышленности (см. ПП РФ 1233 за 1994 г.). В остальном - это не более чем "условное ограничение", поскольку ФЗ "О служебной тайне" до сих пор нет...
Нарисуйте, пожалуйста, схему потоков и прикрепите к своему сообщению, потому что модуль экстрасенсорики подсказывает, что:
  • сетевая подсистема Astra Linux не зависит от сессии пользователя - она только маркирует исходящие пакеты в соответствии с ГОСТ (не проверял в 1.6, но в 1.5 точно не зависела);
  • маркированные поля сетевых пакетов не влияют на их прием средствами любой другой ОС, не знающей про эти поля и про ГОСТ по мандатной маркировке;
  • вам не нужны мандатные метки в принципе, вам важен факт передачи "обратных" данных к системам под управлением QNX (генерируемых в сессии 1 под Astra Linux, правильно понимаю?);
  • передача исходных данных от QNX в Astra Linux через сетевой стек у вас уже реализована (это так?);
  • по линии МО РФ у вас вообще Astra Linux 1.4, которая о мандатной маркировке сетевых соединений слыхом не слыхивала (это так?).
Если все описано верно, то принципиальных проблем не вижу. Напишите тестовый сервер для Astra Linux с базовым функционалом и проверьте...
Подозреваю, что при попытке передать инфу через указатель между потоками с 1 в 0 будет сформировано какое-то прерывание
Здесь вы под словами "поток" и "указатель" имеете в виду потоки сетевого трафика и адресацию или обращение к "процессам" (для nix да, к "потокам"), исполняемым в памяти Astra Linux на разных мандатных уровнях?
 
Сообщения
5
#5
1. Планируется использовать 1.6, поскольку в версиях <1.5 поставщик не мог собрать драйвер последовательных каналов. В 1.5 есть некоторые глюки, которые вроде поправили в 1.6.
2. Те средства, что не знают о маркировке полей вроде не пострадают, но они же при обмене в TCP/IP выдают ответные пакеты, которые будут без меток и уже ОС может не принимать такие пакеты. То есть TCP сессия не сможет по всей вероятности функционировать выше уровня 0. Интересно знать как дело обстоит наверняка.
3. Да нам мандатные метки не нужны и при передаче конфиденциальных данных в сетевой среде думаю о возможности применить VPN. Имею ввиду ту подсеть, где выполняется передача конфиденциальной информации. Там где имеем исполнители и датчики использовать обычные сетевые средства.
4. Да QNX был реализован и датчики на основе SoC без ОС и терминалов. То что QNX должен был подпадать под сертификацию это очевидно, но вот не так очевидно с ячейкой, которая выполнена на SoC - она имеет только сетевой интерфейс, но весь код написан без ОС и ячейки не имеют терминалов и других пользовательских интерфейсов.
5. Почему 1.4? Разве 1.6 отсутствует для МО?
На предлагаемом рисунке весьма условно нарисованы возможные потоки данных. Там где стоит знак вопроса у меня есть сложности понимания в возможности работы таким образом. Ряд вопросов:
1. Как я понимаю, некоторые устройства в /dev/ могут быть переведены на уровень 1 для возможности управления ими с уровня пользователя 1 или это делается иначе через группы?
2. Для работы с данными уровнем ниже возможно только их чтение и корректировка недопустима. То есть такие данные должны быть изменены с уровня 0 например другим пользователем или процессом
3. Можно ли передавать данные внутри процесса сервера между потоками разных уровней. Как я понял сервер может слушать с уровня 0 и при обращении клиента с меткой 1 следует создавать поток (thread) обслуживающий клиента на уровне 1. Но с этого уровня поток (thread) уже не сможет работать с клиентами и серверами, имеющими уровень 0. Таким образом у сервера должны быть потоки (threads) для работы с клиентами и серверами уровня 0. Так как потоки (threads) наследуют общее пространство данных, кроме стека, то тут появляется возможность обмена данными между ними. Механизм установки метки при создании потока (thread) в процессе распространяется на процесс или на поток - это не совсем понятно. Если на процесс, то все имеющиеся открытые файлы и вновь открываемые, в том числе и сокеты, будут наследовать уровень 1. Как тогда возможно работать с клиентами и серверами с уровнем 0?
4. Для класса АС 2 в РД указано, что операторы имеют равные права, но информация хранится на разных носителях. Это значит, что на одном носителе не может быть двух уровней информации? Стоит ли рассматривать ОЗУ СВТ как носитель в этом случае, или только диск может быть носителем и вся информация на нем должна быть одного уровня? То есть весь диск либо 0, либо 1, но не 0 и 1. Как это соотносится с ОС СН?
sch.PNG
 

oko

New member
Сообщения
189
#6
to Константин1977
Разработчиком софта под Astra Linux в режиме мандатной политики не являюсь, поэтому провел ряд примитивных экспериментов...
Проверил на примере взаимодействия Astra Linux со сторонней машиной web-сервером. При входе пользователя в "Уровень-0" обмен TCP-трафиком прекрасно отрабатывает. При входе под "Уровень-1" (тип КЦ не важен) - блокировка любых соединений.
В то же время ICMP-трафик свободно проходит. С UDP не играл, но модуль экстрасенсорики подсказывает, что маркировка касается только TCP...
Прекрасно себя чувствуют сервисы, не зависящие от пользовательской сессии (проверил для openssh-server и samba под Astra Linux), т.е. принцип "блокировка любых потоков, если хотя бы один пользователь повысил мандатную метку сессии" не исполняется (что странно, во всяком случае для клиентского варианта использования, зато хорошо для серверного)...
Вижу три возможных варианта:
  1. Выяснить у РусБинТеха вопросы, касающиеся разработки сетевых сервисов, зависящих от уровня МРД (МКЦ) пользовательской сессии, и следовать их рекомендациям. Что, по понятным причинам, муторно и долго. Зато самый правильный вариант.
  2. Написать простейшую клиент-серверную схему под UDP-трафик и проверить - если заработает, то переориентировать вашу результирующую схему под UDP. Что, по понятным причинам, снижает стабильность работы всей схемы в целом. С другой стороны, раз QNX, значит, СРВ, значит, использование UDP по-своему уместно :)
  3. Переориентировать вашу схему под следующий костыль:
  • сетевой сервис работает независимо от пользовательской сессии через systemd (аналогично openssh-server) и принимает/передает любые данные по сети от любых (или явно заданных) устройств;
  • сетевой сервис "пишет" принятые данные в какой-либо file1 с меткой "ehole" (см. Руководство и wiki), т.е. мандатный механизм игнорируется;
  • данные из file1 отображаются в сессии пользователя с уровнем 0 и выше (через другой сервис или другой поток того же сетевого сервиса);
  • пользователь генерирует ответ, который пишется в file2 с меткой "ehole", т.е. мандатный механизм игнорируется;
  • сетевой сервис читает этот файл-ответ пользователя и высылает данные по сети на другие устройства (например, в СВТ под управлением QNX);
  • по результатам генерации данных сетевой сервис "очищает" file2, чтобы не допустить долговременного хранения "высоких" данных в файле, доступном на чтение под любым уровнем мандатной политики;
  • права доступа к file2 можно задать дискреционно и только для нужного сетевого сервиса, забрав их у пользователя напрямую (тогда сервис будет читать file1 и file2 и отображать данные в контексте пользователя) - это еще на порядок снизит риск утечки информации;
  • file1 и file2 можно держать в ОЗУ, если поток данных небольшой, через монтирование tmpfs куда-нибудь в /mnt/tmp или иной каталог, что повысит скорость их обработки (ЖМД не будет использоваться) и позволит явно задать мандатные метки на эти файлы (возможно, такой механизм есть и для pipe или иных нативных средств, но это надо узнавать у разработчиков).
В целом, последний вариант уместен, потому что разработчики Astra Linux сами ввели метку ehole. С другой стороны, с ней близко не работал - надо пробовать и тестировать...
И да, передача данных между fork-потоками (thread) на разных уровнях сессий, например, через pipe, будет запрещена по умолчанию. При условии штатной работы всех защитных механизмов, разумеется...

ЗЫ Обычно по линии МО РФ речь идет об 1.4. Потому что ее закупали в свое время вагонами и теперь необходимо куда-то внедрять, чтобы отбить затраты :)
 

oko

New member
Сообщения
189
#7
*update*
Проверил UDP - маркируется. Так что вариант с перестроением схемы под другой тип трафика не проходит...
Остается вариант с ehole. По приведенной схеме получилось реализовать миниатюрную связь клиент-сервер. В целом, никаких проблем, особенно если поток данных в file1/2 небольшой...
 

cogniter

Moderator
Team Astra Linux
Сообщения
406
#8
Наверное глупость спрошу, но есть необходимость с уровня например 1 передать воздействия на уровень 0, это исполнитель работающий по сети в QNX. Там нет сокетов с мандатным разграничением, да и информация транслируется без грифа уже после обработки многоуровневой информации. Понятно, что обработка должна выполняться на верхнем, а результат принятия решение не содержит ничего, кроме указания например закрыть или открыть дверь. Не могу понять, как в С решать такую задачу, да еще и пройти сертификацию в МО. Или все необходимо переводить на верхний уровень и менять ос рв на ос сн? Дополнительно вытекает вопрос, почему нигде нет доходчивого материала, как с помощью астры конструировать ас с разными классами. Есть огромный выбор средств и было бы хорошо, Если бы для каждого класса была книга типа red-book, где указывались минимальные настройки средств для того, чтобы решать задачи класса СВТ при сертификации МО, ФСТЭК. А так ос похожа на набор дров который каждый может прикручивать как знает и нет уверенности, что эти подходы соответствуют планам развития ОС и требованиям регуляторов.
Начните с общения по своим вопросам с техподдержкой. Также есть руководство для разработчиков, есть литература по Астре и так далее. Готовых рекомендаций для разработчиков софта для его сертификации пока нет
 
Сообщения
5
#9
Начните с общения по своим вопросам с техподдержкой. Также есть руководство для разработчиков, есть литература по Астре и так далее. Готовых рекомендаций для разработчиков софта для его сертификации пока нет
Возможно проводится обучение в этом направлении. Нам постоянно приходят различного рода предложения в обучении, но все касается администрирования. Не отказался бы от прохождения обучения для разработчиков ПО АС, если такое кто-либо организует.