Я потратил больше часа на поиск ответов в Интернете, но, что удивительно, ни один из них не подошел к моей проблеме.
У меня есть небольшой выделенный сервер, на котором я размещаю несколько вещей. В основном: сервер Owncloud и несколько веб-сайтов для меня и моих друзей (в основном такие вещи, как Wordpress, MediaWiki ...).
Я использую Nginx с разными сайтами (по одному файлу conf.d на сайт).
Для каждого сайта, которому нужен php, я создаю пул php-fpm.
Для каждого сайта:
Это хорошая практика? Есть ли в этой схеме какие-то изъяны?
На моем Owncloud хранится довольно конфиденциальная информация (даже если она зашифрована и это «просто» частный сервер: я не ЦРУ или большая компания).
Следует ли мне запускать другой сервер Nginx в chroot для Owncloud или моя установка достаточно безопасна?
У вас все правильно (пулы PHP-FPM работают под разными пользователями), за некоторыми исключениями.
Скажите, что ваши рабочие процессы NGINX работают как nginx а пул PHP-FPM работает как foo.
Проблемы, расположенные сверху вниз по списку:
Я установил, что файлы каждого сайта принадлежат пользователю [website_user]: [nginx]
Неправильно. Если скрипт PHP создает некоторые файлы (например, обрабатывает загрузки), то владельцем файла может быть foo:foo. Следовательно, нет гарантии, что NGINX сможет прочитать его позже.
Итак, лучший подход - иметь все файлы, принадлежащие foo:foo с начала.
Теперь нужно иметь пользователя, который запускает рабочие процессы NGINX. быть членом foo группа пользователей. Сложно? Не так:
usermod -a -G foo nginx
Это сделает nginx пользователь будет в foo группа пользователей сайта (дополнительная). Другими словами, nginx пользователь теперь является частью этих групп: nginx и foo. Пользователь сайта foo является членом только foo.
Для еще одного веб-сайта, который будет работать под bar пользователя в другом пуле PHP-FPM, вы сделаете то же самое: добавьте nginx пользователя в группу пользователей bar.
Таким образом, теперь вы можете очень гибко определять, что NGINX может видеть, а что нет, настроив групповую часть chmod настройки.
Если вы хотите сейчас, у вас может быть наименее ограничительный chmod, и это будет 0750 для режиссеров и 0640 для файлов. Тогда NGINX может видеть все, и PHP-FPM тоже. Простой способ установить это в файлах сайта:
chmod -R u=rwX,g=rX,o= /path/to/site/dir
я использую X так что бит исполняемого файла (то есть обхода в контексте dirs) устанавливается только для каталогов. Таким образом вы получите желаемое 0750 только для директорий, пока файлы 0640.
Но вы легко можете пойти более строгим. Скажем, NGINX не следует читать /config.php потому что он читается исключительно пользователем PHP и не требует "чтения" NGINX, поэтому вы можете легко:
chmod 0600 config.php
И все равно будет работать по желанию.
Если вы не выполняете никаких проверок существования файлов в конфигурации NGINX (например, no if (-f $request_filename) {), то вы даже можете установить такой же 0600 в каждом файле PHP или даже 0400 для конфигурации блокировки :) Например. смотри мой пост на Конфигурация блокировки Magento.
Я беру на себя смелость добавить то, что считаю очень интересным и что, как ни странно, мало освещалось в сети.
В течение нескольких лет рекомендуется отключать OPcache при выполнении общего хостинга с использованием пулов. Хорошо известной проблемой безопасности было то, что OPcache разрешал PHP-процессу пула доступ к файлам другого пула, даже если у пользователя не было прав на эти файлы.
Оказывается, эта ошибка исправлена, но:
Итак, если ваша версия PHP обновлена (PHP7 <7.0.14 и PHP5 <5.6.29), вы МОЖЕТЕ безопасно включить OPcache в среде пула общего хостинга, если вы добавите эти параметры в свои настройки:
opcache.validate_permission=1
opcache.validate_root=1
opcache.use_cwd=1