Запретить Apache / PHP запускать код, влияющий на другой vHost
СИТУАЦИЯ
В моем каталоге /var/www/ есть несколько папок.
Создаются пользователи, которые контролируют определенный каталог ... /var/www/app1 принадлежит к app1:app1 (www-data является членом группы app1).
Это отлично работает для того, что я хочу.
ПРОБЛЕМА
Если пользователь app1 загружает PHP-скрипт, который изменяет права доступа к файлу / папке для чего-либо в структуре каталогов app2s, процесс Apache (так как на сервере установлен только один) будет более чем счастлив запустить его, поскольку у него есть необходимые разрешения. для доступа к папкам и файлам /var/www/app1а также/var/www/app2.
РЕДАКТИРОВАТЬ:
Насколько мне известно, что-то вроде /var/www/app1/includes/hack.php:
<?php
chmod("/var/www/app2", 777);
?>
Это будет запускать процесс Apache (принадлежащий www-data), поскольку у него есть разрешения на изменение каталогов /var/www/app1 и /var/www/app2. Тогда пользователь app1 сможет использовать cd /var/www/app2, rm -rf /var/www/app2 и т. д., Что явно не очень хорошо.
ВОПРОС
Как я могу избежать этого перекрестное загрязнение процесса Apache? Могу ли я указать Apache запускать только сценарии PHP, которые влияют на файлы / папки, которые находятся в соответствующем корневом каталоге vHost и ниже?
@ Nic3500 - Это не дубликат. Это относится к разрешениям файлов / папок, этот вопрос касается кросс-каталоговых сценариев apache / php. Во всяком случае, это дубликат: PHP - отдельный open_basedir для каждого виртуального хоста
Ответы 2
Вы должны добавить директиву open_basedir в файл vhost каждого сайта. Директива open_basedir ограничивает каталоги, к которым сайт может получить доступ.
Вы можете узнать больше об open_basedir здесь.
Итак, если я правильно понимаю, я могу использовать что-то вроде: php_admin_value open_basedir /var/www/app1/ в относительном файле vhost.conf, и это предотвратит этот вид вредоносного кода?
Только вредоносный код, который вы разместили в качестве примера. Не, например, shell_exec ('/ bin / chmod 777 / far / www / app2')
На самом деле у меня есть: disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source в моем файле php.ini, так что это не такая уж большая проблема.
Итак, пока вы используете версию php без модификатора eval в pcre, не используете расширение IMAP, отключили sendmail_path и отключили переопределения с помощью htacess, тогда мне нужно было бы потратить немного времени на размышления о том, как сломать вашу систему ( например, загрузка пользовательского файла .so и вызов для него dl ()). Правильный способ ограничения доступа - разрешения.
@Jack_Hu, да, добавление этого ограничит доступ к коду Apache / PHP. Symcbean прав, что есть и другие возможности обойти ограничения, но вы уже отключили большинство (если не все) из них.
Хотя open_basedir может помочь, есть несколько способов обойти это ограничение. Хотя вы можете нарушить функциональность много в php, чтобы закрыть все бэкдоры, лучшим решением было бы прекратить выполнение php от имени пользователя, у которого есть доступ ко всем файлам. Для этого вам нужно использовать php-fpm с отдельным пулом процессов / uid / gid для каждого виртуального хоста.
У вас по-прежнему должен быть отдельный uid для выполнения php от uid, владеющего файлами с общей группой, позволяющей по умолчанию доступ только для чтения к файлам.
Вам также необходимо иметь отдельные каталоги для хранения данных сеанса.
Более сложным механизмом было бы использование чего-то вроде сервера трафика Apache перед контейнером для каждого владельца с каждым сайтом, работающим на собственном экземпляре Apache - гораздо лучшая изоляция, но технически сложная и несколько более ресурсоемкая.
Имейте в виду, если вы используете mariadb или аналогичный, что СУБД также может читать и записывать произвольные файлы (ВЫБРАТЬ В OUTFILE ... / ЗАГРУЗИТЬ ИНФАЙЛ ДАННЫХ)
ОБНОВИТЬ
Вместо того, чтобы поддерживать отдельные контейнеры, лучшей изоляции можно добиться с меньшими усилиями, установив домашний каталог php-fpm uid appX в базовый каталог vhost (который должен содержать, а не быть, document_root - см. Ниже) и используйте apparmor для ограничения доступа к общим файлам (например, .so libs) и @ {HOME}. Следовательно, каждый / var / www / appX может содержать:
.htaccess
.user.ini
data/ (writeable by fpm-appX)
html/ (the document root)
include/
sessions/ (writeable by fpm-appX)
Сейчас я использую php-fpm. Поэтому мне нужно создать отдельный пул для каждого rootDir (/var/www/app1) и пользователя (app1), добавить этот новый uid fpm-pool fpm-app1 в gid app1 с чем-то вроде directoryies = 0770 и files = 0640?
Это кролик (да), но 0750 для dirs
Я также использую MariaDB ... Есть идеи, как заткнуть эту дыру?
Я считаю (по крайней мере, для LOAD DATA) требуется разрешение file, которое есть только у root и MYSQL_ADMINISTRATOR (или того, что называется другим пользователем по умолчанию). У всех остальных пользователей его нет, и они также имеют доступ только к своей конкретной базе данных (каждый корневой каталог /var/www/app1 и т. д. Имеет свою собственную базу данных).
Пока пользователь mariadb не является членом какой-либо из групп appX, он не сможет читать файлы с разрешениями 0640 или записывать в каталоги с разрешениями 0750. Я просто выделяю это как соображение, если вы решите развить / уточнить мое предложение.
Вау. Никогда раньше не сталкивался с AppArmor. Похоже, это очень полезно. Мне нужно немного поучиться и попытаться немного с этим разобраться. Таким образом, существует общее мнение, что использование: - соответствующих разрешений для файлов / папок для каждой группы пользователей :. - ограничение доступных функций в php.ini. - ограничение прав доступа пользователей базы данных и разрешений uid / gid. - использование индивидуального fpm-pool / fpm-uid для каждого каталога (например, vHost). - хороший профиль AppArmor для ограничения запуска соответствующих программ / служб / демонов за пределами того места, где они необходимы (если я правильно понимаю AppArmor?) ....... Звучит хорошо?
Да, но вам не нужно отключать большую часть (какие-либо?) Функции в php.ini (кроме sendmail - и вместо этого вы можете предоставить интерфейс SMTP), если у вас есть права
Я обновил вопрос, чтобы прояснить проблему, которую пытаюсь описать. Согласно: php.net/manual/en/function.chmod.php - похоже, что компиляция php в safe_mode сделает то, что мне нужно, но я ищу простую реализацию, которая постоянно меняет мой собственный php.