Замкнутая программная среда для linux

Содержание

Разработка замкнутой программной среды
SELinux.
В смысле, не понял?
К IMA хорошо бы иметь.
Молча.
Мне ещё раз повторить с каким документом.
Мне безразлично с чем был связан вопрос.
Нннуда.
Единственное что добавлю.
Re: Единственное что добавлю.
Автор волен решать что ему делать.
Операционные системы Astra Linux
Операционные системы Astra Linux

Разработка замкнутой программной среды

В рамках курсовой работы необходимо разработать замкнутую программную среду для Linux.

В целом нужно создать безопасную конфигурацию ОС по аналогии с astra-linux SE Смоленск 1.6, реализовать ЗПС и устранить возможность ее обхода через запись с /proc/pid/mem.

На сайте астры есть различные руководства и описания систем безопасности, как включить ту же ЗПС, руководства по разработке ПО для астры, установке. Однако я не нашел исходников, те что есть — https://wiki.astralinux.ru/pages/viewpage.action?pageId=1998854 для новых версий выдают 404, то есть файлов там нет.

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

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

Гуглите «песочница», «безопасный запуск программ», .

SELinux.

Познакомьтесь с этой системой. Правда, в Astra Linux она не используется, ибо западло было бы использовать разработку АНБ. Но для решения Вашей задачи оно вполне годно.

Создаёте для своего кода, точнее, для решения своей задачи отдельный контекст безопасности, куда включаете свой код и каком пользователям им разрешено пользоваться (так же доступ к каким портам, каталогам, etc) разрешён данному софту. Т.е., пишите политики безопасности.

Ну, в принципе, и всё.

Исходя из следующей модели:

Администратором ЗПС является root. Ему доступно изменение настроек ЗПС.
Возможность получения пользователем привилегий администратора с использованием уязвимостей как ядра, так и системного ПО — уже дает возможность исполнять свой код, таким образом оставляем данные проблемы за гранью нашего небольшого уютного ЗПС.

Я бы предложил следующую реализацию:

В ядре создается список, который будет хранить контрольные суммы всех исполняемых файлов. Для простоты можешь просто использовать radix tree.

Добавляется простой procfs интерфейс, который позволяет при наличии привилегий администратора добавить контрольную сумму в список из пункта 1.

В загрузчик исполняемых файлов со стороны ядра встраивается механизм, который производит вычисление контрольной суммы исполняемого файла, после чего производит поиск результата в списке из пункта 1. При отсутствии контрольной суммы в списке возвращаешь -EACCES.

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

Отключается доступ к механизмам ptrace для пользователей.

Изменяются параметры доступа в procfs для всех процессов пользователей на read-only.

Это довольно простая концепция, которую будет просто реализовать даже человеку, который ранее не работал с ядром.

Тем не менее, и она не является полноценной. Но для курсового проекта будет достаточно.

А мандатка то тут каким хером? Ему ЗПС нужен, а не разграничение прав доступа.

Если вам SE-1.6 нужна только как источник идей, можно с таким же успехом позырить сюда:

В смысле, не понял?

А мандатка то тут каким хером? Ему ЗПС нужен, а не разграничение прав доступа.

За тем хером, что в SELinux уже и ЗПС и мандатка в чистом виде реализованы. Учитывая Ваш же предыдущий комментарий, сразу и в ядре.

Ссылка на статью дана для того, чтобы у человека было хотя бы какое «теоретическое обоснование» для своего курсача. Именно эта модель в SELinux и применяется. Но у этой модели есть свои недостатки, которых лишена реализация, применяемая в Astra. Она там некая патентованная. Думаю, в рамках курсача он слегка задолбается реализовывать подобную «идеальную» модель.

UPD. Вдобавок (перечитал Ваш коммент), не факт что рут будет рулить системой всегда. В SELinux его, кстати, в правах тоже ограничивать. И серьёзно.

А разве пункты 1-2-3 не реализованы уже в Integrity Measurement Architecture в ядре?

Кстати, если нужна защита в том числе и ядра от действий рута, то можно посмотреть в сторону патчей kernel lockdown.

И каким образом SELinux реализует ЗПС в чистом виде?

К IMA хорошо бы иметь.

TPM. Это такая. «несколько более сложная» реализация.

Так ему же реализовать нужно, а не использовать готовое 🙂

Молча.

Есть некое приложение. При включённом SEL его запускаем, предсказуемо обламывается. Смотрим

Далее устанавливаем для него политику и делаем reboot:

Без reboot система политику не применит. Перезагрузить модули безнаказанно тут не получится.

Приговор — читать SELinux administration guide вплоть до полного просветления.

Приложение обламывается на этапе запуска, или при использовании каких-либо системных вызовов уже после того, как приложение запустилось?

Мне ещё раз повторить с каким документом.

Вам стоит познакомиться?

Если что, то выше это была не просьба.

Мой вопрос выше был не по причине того, что я не знаю как работает SELinux, а должен был тебя навести на мысль о том, что ты, вероятнее всего, не прав.

Так что будь добр рассказать мне, на каком этапе SELinux запретит исполнение.

Мне безразлично с чем был связан вопрос.

В контексте данного обсуждения (реализации системы, аналогичной применяемой в Astra Linux для ЗПС), это оффтоп. Изучение дополнительных материалов по теме производится в личное время Самостоятельно.

Ну либо не изучается вовсе.

SELinux не запретит запуск приложения, а отфутболит его на этапе запуска системных вызовов, мой некомпетентный друг.

Это значит, что никакой замкнутой программной средой данная схема не является.

Так что перед тем, как советовать кому-то читать что-то — начни с прочтения сам.

Нннуда.

«Скажешь правду, потеряешь друга». =)))

К ЗПС-то в SELinux претензий, как я понимаю, больше нет? Ну и то хорошо. =)))

Ты не понимаешь разницы между замкнутой программной средой и разграничением прав доступа.

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

Если у тебя исполняется недоверенный код, то это уже не ЗПС.

Единственное что добавлю.

Так это то, что если будете экспериментировать с SELinux, то делайте это не на «боевой системе», а в сторонке. Иначе можно многие скорби хапнуть. Это не просто «галочка», типа кликнул и всё работает. Security labels должны применяться ко всей системе и может получиться нехорошо, если система жёстко ляжет. Под SEL даже не всё может работать, кстати.

Можете так же AppArmor посмотреть. Идея в принципе как в SEL, но более простенько. Например, при копировании файла из SEL с ним передаётся его контекст безопасности. AppArmor столь глубоко не лазит.

Читайте также: Monkrus windows 10 v20h2

В остальном. В удалённых всё написано. =)))

Re: Единственное что добавлю.

Это конечно шутка. Посоветовать автору топика разработать виртуальную машину.

Автор волен решать что ему делать.

Либо посмотреть как люди делают и дальше принять решение как улучшить. Либо велосипедить с нуля чего-то на эту тему, в рамках курсача, учитывая то, что средств в аналоги вбито было мама не горюй сколько. И со стороны АНБ (SELinux они заплтчили) и со стороны инфотекса и прочих организаций в РФ.

Вопроса при чём здесь «виртуальные машины» я не задаю просто потому, что боюсь услышать ответ. =))) Это во-первых. А, во-вторых, потому, что vm это не панацея и существуют методы выхода за пределы vm. Но в контексте обсуждавшейся темы, это всерьёз и надолго. =)))

Источник

Операционные системы Astra Linux

Оперативные обновления и методические указания

Операционные системы Astra Linux предназначены для применения в составе информационных (автоматизированных) систем в целях обработки и защиты 1) информации любой категории доступа 2) : общедоступной информации, а также информации, доступ к которой ограничен федеральными законами (информации ограниченного доступа).

1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).

Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».

На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.

Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи!

Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.

В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.

Очередные обновления (версии) предназначены для:

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

Оперативные обновления предназначены для оперативного устранения уязвимостей в экземплярах, находящихся в эксплуатации, и представляют собой бюллетень безопасности, который доступен в виде:

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

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

Источник

Операционные системы Astra Linux

Оперативные обновления и методические указания

Очередные обновления (версии) предназначены для:

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

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

Источник