Изоляция ФС

Где написано? Не верь, используй chroot.

systemd-nspawn. виртуалка на минималках

В мане.

In particular, it is not intended to be used for any kind of security purpose, neither to fully sandbox a process nor to restrict filesystem system calls.

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

Навскидку, тебе может подойди тупо докер, там изоляция.

Задача очевидна - не пускать процесс куда-то вне своего «рабочего» каталога.

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

Используй FreeBSD вместо Linux. Там есть jail - это контейнер такой как он должен быть, а не тот изврат который в линуксах придумали с докерами. Но аккуратность всё равно надо соблюдать, иначе добавишь дыр своими действиями.

В частности

нужно будет файл внутрь «рабочего» каталога закидывать

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

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

Делаешь контейнер со своим бинарником, запускаешь контейнер и монтируешь каналог с данными

unshare. более минимальная виртуалка

В bsd остального нет, например оверкомита памяти. Поэтому не вариант.

Отдельный сервер без доступа к сети в охраняемом помещении. Для пущей безопасности лучше не включать.

Что ты несёшь?

Контейнеры тоже не без греха. Да и виртуалки, из недавнего см. SmmLock bug на процессорах amd

В linux существует mount –bind и hard links. Непонятно учитываются ли эти моменты в твоём понимании «рабочего каталога»

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

В BSD нет оверкоммита??? Для его там придумали!

Тебе нужен bubblewrap.

https://github.com/containers/bubblewrap

FireJail -- краткое и ознакомительное практическое руководство

Нашел решение. Вот так это делается:

auto err = mount(".", "/", nullptr, MS_BIND | MS_REC, nullptr) || pivot_root("/..", "/..") || chdir("/") || umount2(".", MNT_DETACH);

Чтобы не иметь доступа вне chroot, обычно делают:
unshare -u - обычный пользователь не сможет сбежать из chroot вызвав chroot
unshare -p - заизолировать дерево процессов чтобы не было видно процессов в /proc и обычного корня в них. Запускаемый под unshare процесс становится pid1
В принципе этих двух + setuid после чтобы внури cap_sys_admin снять наверняка должно хватить
Продвинутые контейнеры часто ещё кучу selinux ограничений вставляют, но обычно это не нужно если у тебя процесс в контейнере уже гарантровано не root. Если нужно в контейнере софт от рута пускать - то простого unshare может быть мало

auto в этом примере - storage class или выведение типов?

Попробуй после этого сделать в «контейнере» ls /proc/*/root/

bubblewrap, firejail

Ему выдаст «No such file or directory» на /proc т.к. он его туда не монтировал. А вот рассылать сигналы и может быть что-то ещё делать на узнанные как-то pid-ы можно. Но изолировать и их задачи не стояло.

А если он вызовет sys_mount?
Или запускаемому софту нужен /proc?
Да и mknod на устройство?
В случае unshare -p -u шансов выбраться даже с рутом внутри контейнера остаётся немного т.к mknod он не сделает, а /proc хоть и сможет подмонтировать, но после unshare -p там не будет других процессов с реальным корнем

Используй SunOS вместо FreeBSD. Там есть zone - это контейнер такой как он должен быть, а не тот изврат который в бздях придумали с джаилами. Ну и далее по тексту…