Запрет на inlcude файлов других пользователей

[Exillon]

Здравствуйте.
Есть вопрос. Как запретить в php include файлов чужих пользователей?
Сейчас при стандартном шаблоне apache hosting.tpl я могу заинклудить в php любой другой файл остальных пользователей веста панели, например с конфигом БД и прочитать все данные коннетакта к базе.
Бейсдир в шаблоне выставлены правильно, а инклуды все равно работают, хоть другие php функции типа scandir и fopen уже не работают...
Считаю это серьезной проблемой безопасности... Так можно получить конфиг любого сайта и запулучить полный доступ к БД.

Буду рад ответу и подсказкам с возможными решениями.

[skurudo]

open_basedir

/usr/local/vesta/data/templates/web/ apache2 / http

Code: Select all

php_admin_value open_basedir %docroot%:%home%/%user%/tmp
php_admin_value upload_tmp_dir %home%/%user%/tmp
php_admin_value session.save_path %home%/%user%/tmp

можно и так добавить - /home/user/conf/web/apache2.conf

Code: Select all

php_admin_value open_basedir /home/user/web/domain.ru/public_html:/home/user/tmp
php_admin_value upload_tmp_dir /home/user/tmp
php_admin_value session.save_path /home/user/tmp

[Exillon]

open_basedir

/usr/local/vesta/data/templates/web/ apache2 / http

Code: Select all

php_admin_value open_basedir %docroot%:%home%/%user%/tmp
php_admin_value upload_tmp_dir %home%/%user%/tmp
php_admin_value session.save_path %home%/%user%/tmp

Ну в том то и дело в hosting.tpl такой бейсдир по умолчанию прописан, именно пользователи на этом шаблоне могут выходить инклудом на других пользователей. А вот другие функции типа scandir и fopen не работают.
OS: Debian

[skurudo]

Баг имеет место - не включается он корректно на текущих темплейтах, требуется ручное вмешательство.
Проблема как я ее вижу в том, что путь указан не совсем корректно.

viewtopic.php?f=11&t=6747&p=20079&hilit ... dir#p20079
viewtopic.php?f=10&t=6980&hilit=open_basedir

На форуме встречаются упоминания. Пару ссылок привел.

Поправьте и будет как надо.

[Exillon]

Ну вообщем разобрался в чем дело было.
У меня было раньше так в шаблоне hosting.tpl:

Code: Select all

    <Directory %sdocroot%>
        AllowOverride All
        SSLRequireSSL
        Options +Includes -Indexes +ExecCGI
        php_admin_value upload_tmp_dir %home%/%user%/tmp
        php_admin_value upload_max_filesize 10M
        php_admin_value max_execution_time 20
        php_admin_value post_max_size  8M
        php_admin_value memory_limit 32M
        php_admin_flag mysql.allow_persistent  off
        php_admin_flag safe_mode off
        php_admin_value session.save_path %home%/%user%/tmp
    </Directory>
    <Directory %home%/%user%/web/%domain%/stats>
        AllowOverride All
    </Directory>
    php_admin_value open_basedir %home%/%user%/web:%home%/%user%/tmp

То есть установка бейсдира была за тегом директории.
Я перенес все внутрь вот так:

Code: Select all

    <Directory %docroot%>
        AllowOverride All
        Options +Includes -Indexes +ExecCGI
        php_admin_value open_basedir %docroot%:%home%/%user%/tmp
        php_admin_value upload_tmp_dir %home%/%user%/tmp
        php_admin_value upload_max_filesize 10M
        php_admin_value max_execution_time 20
        php_admin_value post_max_size  8M
        php_admin_value memory_limit 32M
        php_admin_flag mysql.allow_persistent  off
        php_admin_flag safe_mode off
        php_admin_value session.save_path %home%/%user%/tmp
        php_admin_value sendmail_path '/usr/sbin/sendmail -t -i -f %email%'
    </Directory>

И теперь все стало нормально работать. И инклуды уже не могут вылезти за пределы директории.

[skurudo]

Ну да, досадный баг, как я и говорил :(

[Deeryo]

Привет, друзья! Думаю open_basedir не достаточно хорош. Предлагаю правильно менять права. Допустим используется mod_ruid2 и nginx запущен под юзером nginx, это обычно для Vesta (Для debian/ubuntu везде надо указать группу www-data, а не nginx).
1) Сначала поменяем права на index.php файл командой "chmod 600 index.php" и попробуем открыть его в php скрипте под другим юзером. Success, файл больше не открылся! Но менять права на файлы муторно, вернем права назад на 644.
2) Поменяем права на папку сайта:

Code: Select all

chgrp nginx /home/admin/web/default.domain
chmod o= /home/admin/web/default.domain

И снова удача, php скрипт не открывается в скрипте под другим юзером, а nginx по прежнему показывает все статические файлы нашего сайта.
3) Но как автоматизировать процесс смены прав? Создадим скрипт
/usr/local/vesta/data/templates/web/httpd/default.sh или /usr/local/vesta/data/templates/web/httpd/basedir.sh c таким содержимым

Code: Select all

#!/bin/bash
# Change access rights
user="$1"
domain="$2"
ip="$3"
home_dir="$4"
docroot="$5"
folder="$home_dir/$user/web/$domain"
test -d "$folder" || exit
chgrp nginx "$folder"
chmod o= "$folder"
exit 0

Теперь при создании сайта или смене шаблона права поменяются и данные будут в безопасности..
Как бы не так! Хакер создаст симлинк на наш php файл и назовет его wp-config.txt. Тут nginxу начнет казаться, что это текстовой файл и он радостно его отдаст в браузер хакера. Можете проверить. Некоторые этой проблемы не увидят, потому что установили в панели шаблон nginx "hosting", который отличается дополнительной строкой "disable_symlinks if_not_owner from=%docroot%;". После смены шаблона можно немного расслабиться.