Песочница для C кода

seccomp bpf.

ограничевая его права (запрет на системные вызовы,

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

отдельная куча)

Просто бесполезно.

В хромиуме такое реализовано, в NaCL.
При загрузке кода проводишь его анализ - не делает он ли чего-то плохого. Если делает - реджект. Думаю, опционально можно патчить сисколы налету.

С помощью ptrace можно.

Например так: https://github.com/jollheef/sandbox/blob/master/sandbox.c

p.s. Мопед не мой, я его только допиливал для себя.

Замечательно! Хотелось бы ещё узнать, есть ли подобное для *BSD

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

Если можно ограничить на уровне потока, то почему нет?

Это же для целого процесса, разве нет?

Это же для целого процесса, разве нет?

Да, это для целого. Тред не читай && сразу отвечай.

1) Перед загрузкой через dlopen посмотреть импорты можно.
2) Если нужно очень секьюрно, а модули пишет third party, то пусть присылают на подпись. Ты их тестируешь, изучаешь, чтобы там не было «вредоносного», подписываешь, отправляешь назад.

Хм, ну вообще-то многие пробовали разными способами как некоторые Си-подобные языки к движкам подключать, так и обычный С, но компилять его в специальный байткод, который потом исполнять vm, находящейся в движке. Так например работает q3 движок. С компиляется в байткод, затем исполняется vm.

С учётом современных технологий вроде llvm держать уже чисто vm у себя не нужно, можно брать промежуточный код, делать с ним нужные манипуляции, компилять в нативный и подгружать. Как тот же native client делает.

Можно запускать сторонний код в новом процессе, где предварительно вызвать seccomp(2) с нужными настройками и предусмотреть возможность общения с родительским процессом.

В Quake3 обычный C-код компилится в байткод с помощью модифицированного lcc и исполняется в виртуальной машине qvm.

Можно выковырять из движка и использовать.

В Quake1 был Quake C, отдельный язык, внешне похожий на C. В составе gmqcc, насколько я помню, даже небольшая виртуальная машина в комплекте с компилятором идёт.

запрет на системные вызовы

firejail --seccomp --private ./a.out
как вариант.

firejail

Какая интересная штука. Спасибо.

Интересно, зачем всё это было в кваке?

Дикие 90е луа-пистоны ещё не были в широкой моде.

Это понятно, но почему нельзя было такие вещи реализовать тупо в коде? В виде DLLки или статически линкуемого модуля?

В те времена можно было ненароком брикнуть что-нибудь клиенту?

«окирпичить»

Чтобы двигло каждый раз не компилить.

Но зачем ограничивать права кода то?

Чтобы ты во время игры биткойны не майнил и ддосы не устраивал.

Это понятно, но почему нельзя было такие вещи реализовать тупо в коде? В виде DLLки или статически линкуемого модуля?

можно, в quake2 как раз так и было.

преимущества байткода в quake3:

* 1 раз компилишь байткод, и он работает на всех платформах (типа как java).

* моддеры могут пересобирать игровые dll под все платформы без дополнительных инструментов типа вижуалов (которые тогда очень дорого стоили)

* не уверен, работало ли это, но вероятно было желание перезагружать игровой код без перезапуска движка (как со скриптами).

Во времена Quake III биткойнов ещё не было. Вопрос собственно был «зачем это всё во времена Quake III».

Чтобы игровой код один раз скомпилять и запускать везде. В Q2 игровой код к примеру надо отдельно компилять под разные платформы, это неудобно.

Плюс естественная песочница из коробки. Работа кода полностью ограничена движком.