Я думаю, что многие детали вашего вопроса могут в равной степени относиться к тому avahi-daemon, на что я смотрел недавно. (Возможно, я пропустил еще одну деталь, которая отличается). Запуск avahi-daemon в chroot имеет много преимуществ, если avahi-daemon скомпрометирован. Это включает:
- он не может прочитать домашний каталог любого пользователя и удалить личную информацию.
- он не может использовать ошибки в других программах, записывая в / tmp. Существует как минимум одна целая категория таких ошибок. Например, https://www.google.co.uk/search?q=tmp+race+security+bug.
- он не может открыть любой файл сокета Unix, находящийся за пределами chroot, который другие демоны могут прослушивать и читать сообщения.
Пункт 3 может быть особенно приятным, когда вы не используете dbus или аналогичный ... Я думаю, что avahi-daemon использует dbus, поэтому он обеспечивает постоянный доступ к системному dbus даже изнутри chroot. Если вам не нужна возможность отправлять сообщения в системный dbus, отрицание этой возможности может быть довольно хорошей функцией безопасности.
управление им с помощью системного файла модуля
Обратите внимание, что если avahi-daemon был переписан, он может предпочесть полагаться на systemd для обеспечения безопасности и использовать, например, ProtectHome . Я предложил изменить avahi-daemon, чтобы добавить эти защиты в качестве дополнительного слоя, а также некоторые дополнительные защиты, которые не гарантируются chroot. Вы можете увидеть полный список вариантов, которые я предложил здесь:
https://github.com/lathiat/avahi/pull/181/commits/67a7b10049c58d6afeebdc64ffd2023c5a93d49a
Похоже, есть и другие ограничения, которые я мог бы использовать, если бы avahi-daemon не использовал сам chroot, некоторые из которых упоминаются в сообщении коммита. Я не уверен, насколько это относится, хотя.
Обратите внимание, что защита, которую я использовал, не ограничивала бы демона открытием файлов сокетов Unix (пункт 3 выше).
Другой подход заключается в использовании SELinux. Однако вы бы как бы привязывали свое приложение к этому подмножеству дистрибутивов Linux. Причина, по которой я положительно отнесся к SELinux, заключается в том, что SELinux детально ограничивает доступ, который имеют процессы к dbus. Например, я думаю, что вы часто можете ожидать, что systemdэтого не будет в списке названий шин, на которые вам нужно было отправлять сообщения :-).
«Мне было интересно, если использование системной песочницы безопаснее, чем chroot / setuid / umask / ...»
Резюме: почему не оба? Давайте немного расшифруем вышесказанное :-).
Если вы думаете о пункте 3, использование chroot обеспечивает больше ограничений. ProtectHome = и его друзья даже не пытаются быть такими же строгими, как chroot. (Например, ни один из именованных опций systemd не /runпомещается в черный список , куда мы склонны помещать файлы сокетов Unix).
chroot показывает, что ограничение доступа к файловой системе может быть очень мощным, но не все в Linux является файлом :-). Есть системные опции, которые могут ограничивать другие вещи, которые не являются файлами. Это полезно, если программа скомпрометирована, вы можете уменьшить возможности ядра, доступные для нее, в которых она может попытаться использовать уязвимость. Например, avahi-daemon не требует Bluetooth-сокетов, и я полагаю, что ваш веб-сервер тоже не нуждается :-). Так что не предоставляйте ему доступ к семейству адресов AF_BLUETOOTH. Просто белый список AF_INET, AF_INET6 и, возможно, AF_UNIX, используяRestrictAddressFamilies= опцию.
Пожалуйста, прочитайте документы для каждого варианта, который вы используете. Некоторые параметры более эффективны в сочетании с другими, а некоторые доступны не на всех архитектурах ЦП. (Не потому, что процессор плохой, а потому, что порт Linux для этого процессора не был так хорошо спроектирован. Я думаю).
(Здесь есть общий принцип. Это более безопасно, если вы можете писать списки того, что вы хотите разрешить, а не того, что вы хотите запретить. Например, определение chroot дает вам список файлов, к которым у вас есть доступ, и это более надежно чем сказать, что вы хотите заблокировать /home ).
В принципе, вы можете применить все те же ограничения самостоятельно перед setuid (). Это всего лишь код, который вы можете скопировать из systemd. Тем не менее, параметры системного блока должны быть значительно проще для написания, и, поскольку они представлены в стандартном формате, их будет легче читать и просматривать.
Поэтому я настоятельно рекомендую просто прочитать раздел «песочница» man systemd.execна вашей целевой платформе. Но если вы хотите наиболее безопасный дизайн можно, я не боялся бы попробовать chroot(а затем удалить rootпривилегии) в вашей программе , а также . Здесь есть компромисс. Использование chrootнакладывает некоторые ограничения на ваш общий дизайн. Если у вас уже есть дизайн, использующий chroot, и, кажется, он делает то, что вам нужно, это звучит довольно здорово.