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

SELinux.

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

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

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

UPD. «Теорию» начинать копать отсель — https://ru.wikipedia.org/wiki/Модель_Белла_—_Лападулы

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

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

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

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

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

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

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

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

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

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

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

UPD. «Теорию» начинать копать отсель — https://ru.wikipedia.org/wiki/Модель_Белла_—_Лападулы

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

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

https://sourceforge.net/projects/disec/files/digsig/digsig-1.5-rev/digsig_ker...

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

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

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

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

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

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

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

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

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

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

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

Молча.

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

grep 'yourapplication' /var/log/audit/audit.log | audit2allow -a -M yourapplication_local

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

semodule -i yourapplication_local.pp;reboot

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нннуда...

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы во всем правы /была не удачная шутка/.

https://github.com/search?q=sandbox

В целом нужно создать безопасную конфигурацию ОС

Я не знаю как подступиться к теме в принципе, с чего начать,

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

Да всё нормально.

Сам посмеялся. =)

Просто, если раскрыть тему, то в той же hardened gentoo, где SELinux на всю голову, там root может сделать emerge -uDN @world, обновив систему. Но вот выполнить программу, которая только что обновилась от его учётной записи, открыв некие файлы и получить доступ к их содержимому, уже нет. Без дополнительных усилий.

Просто, это работает. Я вот о чём. У этой реализации есть недостатки, но проще за основу я и не знаю что взять.

Впрочем, дело это ТС, как скажет так и будет. Если вопросы будут, чем смогу помогу. А так-то, пока из треда вышел. Всем успехов.

Я не знаю как подступиться к теме

тут был?
https://wiki.astralinux.ru/pages/viewpage.action?pageId=1212431
https://wiki.astralinux.ru/pages/viewpage.action?pageId=41190634

вообще то это тянет не на курсовую, а на диссертацию, если получится реализовать, как в Астре