Безопасность веб-сервера: запретить сайту вылезти из своей папки
Добрый вечер!
Собственно сей вопрос: необходимо определённому сайту apache запретить вылезти дальше своей папки DocumentRoot
Имеем: сервер с debian, apache2-mpm-itk
Пользователь testuser
сделан chroot, через ssh в /home пользователь видит только себя. testuser@debian:~$ ls /home
testuser
физически пользователь лежит в /home/jail/home/testuser
папка DocumentRoot для Apache — /home/jail/home/testuser/www
в конфиге apache виртуального хоста testuser прописано AssignUserId testuser testuser,
что по-идее должно былол сделать, чтобы апач для сайта testuser запускался от его имени.
Однако, допустим, выполнивс сайта testuser скрипт #!/usr/bin/perl
print "Content-type: text/html\n\n";
open FILE, "/etc/apache2/apache2.conf" or die $!;
print <"FILE">;
прекрасно видно содержимое конфига апача.
Как этого избежать? Как же всё-таки сделать, чтобы скрипты, запускаемые на сайте testuser не могли выйти дальше окружения testyuser?
Вы путаете кислое с горячим :) Без разницы где и что лежит, главное какие и у кого права на «это» :)
Если у вас есть права для всех пользователей на чтение файла /etc/apache2/apache2.conf, то он и будет читаться любым пользователем :) и причем тут вообще сайт?
Не хотите чтобы testuser читал /etc/apache2/apache2.conf снимите права и все :)
Запретить читать это одно,
но нужно сделать, чтобы testuser не мог вылезти дальше своего сайта,
т.е. о существовании /etc/apache2/apache2.conf он бы даже не подозревал.
Как я понимаю, chroot для этого и нужен.
однако такое нужно сделать только для одного сайта apache.
когда пользователь testuser заходит по ssh он не видит системных конфигов, других пользователей, кроме себя в /home и т.д. он видит только своё chroot окружение.
Но в случае, если апач работает от этого пользователя, то простым скриптом можно просмотреть содержимое всей системы. такого быть не должно. сайт должен работать в том же chroot окружении.
Да каким же образом?
о существовании того же /etc/apache2/apache2.conf пользователь testuser будет знать. Пускай и не сможет его открыть.
а мне нужно, чтобы он не догадывался о наличии в системе чего-либо, кроме своего окружения.
о существовании того же /etc/apache2/apache2.conf пользователь testuser будет знать.
а вы как думали? конечно будет знать, если не идиот.
или он зайдя по SSH должен думать «ой, какая магическая система, апача в моих папках нет, а контент раздается!»
любой юзер понимает что кроме той папки в которой он ютится есть еще некоторое кол-во соседних юзеров и операционная система.
если он не совсем зеленый новичек, то он знает о их существовании, и единственное что вы можете сделать — запретить ему писать и читать то, что ему не положено.
хотите изолировать полностью — виртуализация вам в помошь.
Все это надо настраивать через apparmor/selinux. Гемор еще тот, но оно того стоит.
Апач в чрут ложить себе дороже. Надо всю локальную структуру бинарников и конфигов воссоздавать для каждого сайта. Проще уж сайты по контейнерам openvz раскидать.
Для запуска программы в безопасной зоне. То есть все изменения которые она может сделать не повлияют на работу операционки. chroot не переключает пользователя (это делает mpm-itk) и соответственно не ограничивает права, он просто переносит "/" в другое место. Следствие, ты можешь под рутом запускать в chroot-е любую программу, она чета творит с операционкой, далее ты возвращаешься из chroot-а и у тебя все работает и ничего не проломлено, что бы не натворила программа.
Так же chroot удобно для того что бы переключаться на другую операционку, допустим которая находится на другом диске, и в ней работать. (ЗАМТИТЬ!!! все изменения будут происходить именно на другом диске, а не на изначальной из которой мы сделали chroot)
ну как-то так, надеюсь помог в меру своего понимания.
Тогда, по-моему, средствами апача задачу не решить — запустившись от testuser он должен получить доступ к /etc/apache2/apache2.conf, значит получит и любой скрипт, выполняющийся под ним. Хотя не знаю точно, у меня стояла задача, чтобы все хосты не видели ничего лишнего.
Простой
Средний
Средний
