Я создаю API, который принимает любую команду (в bash) и выполняет ее в корне. Я хочу убедиться, что эта команда является RO и ничего не пишет. Есть идеи, как это сделать? Может быть, он может временно отключиться с помощью таймера или что-то подобное?
3 ответа
2
Я не думаю, что это возможно. Вы можете убедиться, что все, что пишется в stdout или stderr , например, перенаправляется в /dev/null . Однако, если утилита хочет записать в файл, вы не сможете предотвратить или даже узнать это.
Стандартная практика безопасности - никогда не запускать ненадежные программы с привилегиями root.
2
Я не думаю, что в общем случае есть способ гарантировать, что случайная программа ничего не напишет. Вы смотрите на что-то похожее на решение проблемы остановки, с изюминкой (stdout и stderr также выставляются как дескрипторы файлов).
Однако вы можете создать небольшую библиотеку, которая переопределяет соответствующие горстки стандартных библиотечных вызовов, таких как creat(2), open(2), write(2) и некоторые другие, чтобы ничего не сохранять на диске. Скорее всего, это будет что-то похожее на libfaketime и должно быть разумно выполнимым. Он был бы переносим на любое приложение через механизм предварительной загрузки библиотеки LD_PRELOAD динамического загрузчика.
Однако это почти наверняка не будет полным решением. Особенно процесс, который запускается с правами root, может легко отменить любое из этого, если он знает, что его ожидает, и хочет творить зло. С одной стороны, это зависит от любых таких вызовов, проходящих через общие интерфейсы, такие как библиотека C, что не гарантируется; процесс может так же легко скопировать код библиотеки C непосредственно в свой собственный код. Это может сделать прямые вызовы к системным интерфейсам ядра. Библиотека C не волшебная вещь; это код пользовательского пространства, как и любой другой. И двоичный файл может быть статически связан, и в этом случае динамический загрузчик вообще не будет вызываться. Возможно, возможно обойти эти ограничения и предотвратить записи, но ...
Выполнение write(2) и friends no-ops также может привести к поломке на другом конце, когда процесс ожидает, что записанный файл будет содержать записанные данные.
А что если он ничего не пишет на самом деле, а просто читает пару файлов конфигурации, важных для безопасности (/etc/crypttab, /etc/shadow, /etc/bind/rndc.key, ... вы понимаете) и передает эти данные в другое место; по сети, возможно, или сбрасывает его так, чтобы он стал доступен через атаку по побочному каналу?
Я бы пошел на шаг дальше, чем Саванто. Стандартная практика безопасности должна состоять в том, чтобы не запускать ненадежное программное обеспечение, точка. И вам определенно не следует запускать ненадежное программное обеспечение от имени пользователя root. Для всего, что запускается от имени root, вы можете поставить пару препятствий на пути, но вы не можете гарантировать, что он не будет делать то, что он хочет. SELinux может помочь и, вероятно, проделает довольно долгий путь при правильном использовании, но это чудовищно для настройки, и он, вероятно, приведет к тому, что любые нарушения политики приведут к сбою рассматриваемого вызова с состоянием ошибки и, возможно, прерыванию жесткого процесса, поэтому он выиграл не будь изящным вообще.
Мне кажется, что наиболее близким к тому, что вы хотите сделать, и который будет работать в общем случае, будет изолированная виртуальная машина с возможностью отката модификаций, выполненных на диске (обычно называемых возможностью отката моментальных снимков), Это, однако, будет далеко не беспроблемным и приведет к большим накладным расходам, поскольку вы для всех намерений и целей запускаете второй экземпляр операционной системы со всем, что это означает.
0
Это не прямой ответ, но я бы искал песочницу или виртуальную машину.