Отключить функции system() и exec() в C и Pascal

Ну, вы можете попробовать:

#define system DontEvenThinkAboutUsingThisFunction
#define exec   OrThisOneYouClown

в заголовочном файле, но я почти уверен, что любая кодовая обезьяна, достойная их соли, может обойти такую ​​«защиту».

Мне было бы интересно понять, почему вы считаете это необходимым (может быть лучшее решение, если мы лучше разберемся в проблеме).

Единственное, что приходит на ум, это то, что вы хотите предоставить какой-нибудь онлайн-компилятор/раннер, похожий на проект Эйлера. Если бы это было так, то вы могли бы поискать в коде строку system<whitespace>( в качестве опции, но даже в этом случае определенная сторона могла бы просто:

#define InoccuousFunction system

чтобы обойти вашу защиту.

Если это это так, вы можете подумать об использовании чего-то вроде chroot, чтобы никто не мог даже получить доступ к любым опасным двоичным файлам, таким как shutdown (и этот конкретный зверь в любом случае не должен запускаться обычным пользователем) - другими словами, ограничьте их среду, чтобы что единственные вещи, которые они могут видеть, это gcc и ему подобные.

Одна из возможностей состоит в том, чтобы создать свою собственную версию таких функций и связать их с каждой программой, которую вы компилируете/связываете на сервере. Если символ найден в ваших объектах, он будет иметь приоритет.

Просто убедитесь, что вы их все ;)

Было бы гораздо лучше запускать программы от имени пользователя с минимальными привилегиями. Тогда вам не придется беспокоиться об удалении/доступе к системным файлам, завершении работы системы и т. д.

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

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

По сути, вы хотите запустить код в очень ограниченной среде; В Linux предусмотрен специальный флаг процесса, который отключает любые системные вызовы, дающие доступ к ресурсам, которых у процесса не было на момент установки флага (т. е. он запрещает открытие новых файлов, но любые уже открытые файлы могут быть доступ нормальный).

Думаю, в Windows должен быть аналогичный механизм.

Вы могли бы использовать что-то вроде этого

#include<stdlib.h>
#include<unistd.h>
#define system  <stdlib.h>
#define exec   <unistd.h>

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

#define <stdlib.h> system
#define <unistd.h> exec

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

Не совсем (из-за таких уловок, как вызов какой-либо библиотечной функции, которая вызовет саму system, или из-за того, что функциональность порождающих процессов может быть выполнена только с помощью системных вызовов fork и execve, которые остаются доступными...).

Но почему вы об этом спрашиваете?

Вы никогда не можете (как вы узнали) полагаться на пользовательский ввод, чтобы быть в безопасности. system и execXX вряд ли будут вашими единственными проблемами.

Это означает, что у вас есть следующие варианты:

1. Запустите программу в каком-нибудь джейле chrooted (не уверен, как это сделать на windows)
2. Сканируйте код перед компиляцией, чтобы убедиться в отсутствии «незаконных» функций.
3. Сканируйте исполняемый двоичный файл после компиляции, чтобы убедиться, что он не использует какие-либо «запрещенные» библиотечные функции.
4. Запретите компоновщику связываться с любыми внешними библиотеками, включая стандартную библиотеку C (libc) в Unix. Затем вы создаете свою собственную «libc», которая явно разрешает определенные функции.

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

Номер 4 потребует возни с флагами компилятора, но, вероятно, является самым безопасным из перечисленных выше вариантов.