Безопастность. Chroot для Apache

уточняю вопрос

Сервер Debian - Apache+mod_php

Мне нужно запретить чтение любых файлов вне док-рута конкретного виртуального хоста.

Сейчас для чтения доступны все файлы сервера.

просмотр содержимого - /etc/passwd

- disable_functions - system, shell_exec, exec... не влияют на чтение системных каталогов, т.к. оно производится с помощью функции opendir

- у меня не получилось задать open_basedir. в конфиге вирт-хоста апача

php_admin_value openbase_dir "/home/www/project1" - это значение не загружается в ПХП

Работает только если openbase_dir объявить в php.ini, но мне для каждого виртуального хоста нужно установить свою директорию

в понедельник попробую предложенные Вами варианты.

у вас опечатка: надо open_basedir

пожалуйста, смотрите документацию, если сомневаетесь в названии директивы.

open_basedir можно выставить в конфиге апача.

Ну собственно, я об этом и писал в первом ответе.

MIRhosting.com добавил 20.03.2010 в 13:21

Ну расскажите, какие права Вы поставите например на /etc/passwd чтобы у пользователя на было доступа на чтение к нему.

MIRhosting.com добавил 20.03.2010 в 13:24

open_basedir - отношусь к этому в большой долей сомнения, потому что не раз находили дыры в нем, обходящие это ограничение. + для не php скриптов это не будет ограничивать.

для "не php скриптов" есть другое решение с группой пользователей и запрете доступа к /home/Xuser

Вы тему читали? При чем тут запрет доступа к /home/Xuser?

Определенно, читали. Запрет доступа к файлам других сайтов - реализуется для "не mod_php" - достаточно стандартными средствами. Каждому сайту - свой пользователь для скриптов. В чужой хом он не суется.

Что касается системных файлов типа /etc/passwd - тут либо ограничения внутри интерпретатора (типа open_basedir, если mod_php используется) либо chroot. Нужно ли возиться с организацией chroot на типовом виртуальном хостинге - хороший вопрос. Ну узнал я, что там написано

uXXXXX:x:1011:1011:,,,:/var/www/uXXXXX:/bin/false

uYYYYY:x:1012:1012:,,,:/var/www/uYYYYY:/bin/false

Много мне это дало?

myhand, имена пользователей и вытекающую отсюда возможность перебирать пароли более быстро.

заранее напишу : я не утверждаю, что запрещать доступ к системным файлам нужно во что бы то ни стало.

пароли нужно стойкие ставить. технические средства для контроля этого - давно есть.

это во-первых. А во-вторых - обычно достаточно понаблюдать какую-нибудь ошибку php-скрипта, рапортуя о которой он радостно сообщит о системных путях. Так что и имя пользователя угадать - не сложно - название домашнего каталога с ним обычно связано однозначно.

в-третьих. если злоумышленник читает произвольный файл в системе - что помешает ему выяснить полный путь к файлам сайта? откуда опять-таки информация о имени пользователя.

myhand, так ведь оптом утечет все. несколько из сотни паролей окажут тривиальными и дальше уже на серче, как на могильной плите, напишут, что Xостер Х - говно.

Хранить учетки в ldap/mysql - не?