ACL как одно из решений проблемы работы web-сервера под root

Простой и эффективный способ с использованием Access Control Lists

Я довольно часто встречал конфигурацию, когда web-сервер работает под root, чтобы обойти жёсткие права доступа, установленные на каталоги пользователей. Рассмотрим на примере: предположим, что пользовательские сайты расположены в /home/<username>/, при этом права на каталог home установлены в 0711 (rwx--x--x), а права на пользовательские каталоги установлены в 0700 (rwx------). Такие права устанавливаются, чтобы изолировать пользователей друг от друга — один пользователь не сможет зайти и посмотреть домашний каталог другого пользователя. Такая мера популярна у администраторов виртуального (shared) хостинга.

Для того, чтобы web-сервер мог нормально обслуживать сайты, обычно используется одно из следующих решений:

• web-сервер работает под учётной записью root;
• права на домашний каталог устанавливаются в 0750 (rwxr-x---), а пользователь, под которым работает web-сервер, вносится в группу, которой принадлежит пользователь.

Недостаток первого способа очевиден — опасно жить под root. Второй способ тоже не подарок; к тому же у разных *nix разные ограничения на максимальное количество дополнительных групп, членом которых может являться пользователь.

Хотя второй способ безопаснее, всё можно сделать проще с использованием ACL.

Для этого должны выполняться следующие два требования:

1. Файловая система должна поддерживать ACL (и быть смонтирована с поддержкой ACL). ACL поддерживают следующие файловые системы (список не претендует на полноту): EXT2, EXT3, EXT4, ReiserFS, XFS, JFS;
2. В системе должен быть установлен пакте, содержащий программы setfacl и getfacl (в дистрибутивах, основанных на Debian, пакет называется acl).

Предположим, что web-сервер работает от имени www-data. Тогда, чтобы разрешить пользователю www-data читать домашние каталоги пользователей, достаточно выполнить такую команду:

Подробное описание команды setfacl приведено здесь.

Желательно, чтобы простой пользователь не мог получить права www-data, ибо после этого пользователь сможет прочесть все незащищённые файлы других пользователей (в принципе, он и так это может сделать, запросив требуемый файл через web). Для защиты от подобных инцидентов все важные файлы (например, тот же wp-config.php в WordPress) должны иметь минимальные права доступа (например, 0400 — r--------): в этом случае у www-data не будет прав на чтение файла, а у PHP-интерпретатора, выполняющегося с правами пользователя, будут.

Связанные записи

• Скажи «Нет!» взломщику: часть 2 (1)
• Скажи «Нет!» взломщику (12)
• Модуль поддержки tcpwrappers для nginx (1)
• Запрет выполнения файлов на /tmp (2)
• ngx_drop_privs: принцип минимальных привилегий в nginx (3)

Автор: Vladimir; опубликовано в: Linux, Администрирование; метки: ACL, Linux, безопасность