The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Установка PHP как CGI работающий под suEXEC (apache suexec php cgi security limit)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: apache, suexec, php, cgi, security, limit,  (найти похожие документы)
From: Малик Абдугалыев <[email protected]> Date: Mon, 24 Jul 2004 18:21:07 +0000 (UTC) Subject: Установка PHP как CGI работающий под suEXEC Оригинал: http://malik.elcat.kg/apache-suexec-php.shtml Установка Apache, suEXEC и PHP как CGI Версии софта: - apache_1.3.27rusPL30.16 - php-4.2.3 Проблема -------- Апач запускается от имени www:www, также запускаются и скрипты клиентов. Это приводит к тому, что скрипт клиента не имеет прав создавать и изменять файлы в своей же домашней папке. Поэтому приходилось создавать папки/файлы с правами записи для всех или с владельцем www. Такая же проблема и с PHP скритами, т.к. mod_perl4, вкомпилённый в апач работает от его же владельца. Другая проблема - доступность системных файлов и файлов других клиентов из CGI и PHP скриптов. Многие системные файлы можно прочитать простейшим скриптом, т.к. они доступны для чтения всем. Все файлы клиентов доступны для чтения другим клиентам, но кроме этого для изменения доступны те файлы/папки, которым мы сами и назначили соответствующие права, чтобы клиент мог работать с ними из своих скриптов. Решение ------- suEXEC позволяет запускать скрипты от имени владельца сайта и соответственно создавать/менять файлы, принадлежащие ему. Поэтому нет необходимости назначать право записи группе и тем более всем. К сожалению проблема с чтением чужих файлов остаётся. Насколько я понял её можно решить только с помощью виртуальных машин jail для каждого виртуального хоста (сайта) причём с индивидуальными IP-адресами, деревом необходимых файлов и библиотек и фиг его знает ещё чем. Запуск PHP как CGI, а не как модуль Апача решает проблему и с PHP, т.к. он запускается через suEXEC, такой метод немного усложняет настройку для нас, но для клиентов проблем не добавляет. Включение safe_mode для PHP-интерпретатора позволяет исключить чтение/изменение файлов, не принадлежащих клиенту. Установка и настройка 1. в папке с исходниками php сделал: ./configure \ --with-gd=/usr/local \ --with-ttf=yes \ --with-gettext \ --with-zlib=/usr --enable-force-cgi-redirect make make install 2. в папке с апачем сделал: ./configure \ --enable-suexec \ --suexec-docroot=/usr/local/apache/htdocs \ --suexec-userdir=/usr/local/apache/htdocs \ --suexec-logfile=/usr/local/apache/logs/suexec.log \ --suexec-caller=www make make install В конфиге Апача надо, по меньшей мере, поменять параметры: User www Group www Пример настройки виртуального хоста: User pupkin Group webusers ServerAdmin [email protected] DocumentRoot /usr/local/apache/htdocs/pupkin ServerName pupkin.elcat.kg ScriptAlias /cgi-bin/ "/usr/local/apache/htdocs/pupkin/cgi-bin/" AddType application/x-httpd-php .php .php3 Action application/x-httpd-php /cgi-bin/php DirectoryIndex index.php index.shtml Содержимое cgi-bin: /usr/local/apache/htdocs/pupkin/cgi-bin > ls -l total 3437 -rwxr-xr-x 1 pupkin webusers 3468792 27 апр 15:56 php -rw-r--r-- 1 pupkin webusers 37862 27 апр 15:57 php.ini Обязательные условия при заведении новых клиентов ------------------------------------------------- Общие Пользователей для веба заводить только в соответствующую группу, например webusers. Эта группа указана в файле /etc/ftpchroot, чтобы по фтп не могли подняться выше своей домашней папки. Кому надо, выставлять квоты командой: edquota -u username Домашние папки клиентов должны принадлежать им и группе webusers, права на запись должны быть только у владельца, но не у группы и тем более не у всех. Для suEXEC Домашние папки пользователей должны быть только в каталоге '/usr/local/apache/htdocs'. Т.к. только для скриптов из этой папки (рекурсивно) действует suEXEC. И скрипты, и папка cgi-bin должны принадлежать клиенту. При настройке виртуального хоста в Апаче, кроме обычных, указать параметры: User user_name Group webusers Например: User pupkin Group webusers DocumentRoot /usr/local/apache/htdocs/pupkin ServerName pupkin.elcat.kg ... Логи, касающиеся suEXEC, пишутся в файл '/usr/local/apache/logs/suexec.log'. Для PHP Для каждого клиента, которому нужен PHP, в конфиге виртуального хоста указать следующие строки: ScriptAlias /cgi-bin/ "/usr/local/apache/htdocs/pupkin/cgi-bin/" AddType application/x-httpd-php .php .php3 Action application/x-httpd-php /cgi-bin/php Эти строчки указывают Апачу при обращении к файлам с расширением .php или .php3 отдавать их интерпретатору /cgi-bin/php. Вызов же интерпретатора напрямую из строки URL запрещён при компиляции PHP параметром "--enable-force-cgi-redirect". В папку cgi-bin положить интерпретатор PHP и конфиг для него php.ini, причём и папка и интерпретатор должны принадлежать самому клиенту, а иметь возможность редактировать конфиг он не должен, т.е. конфиг должен принадлежать root-у. В файле php.ini нужно по меньшей мере включить безопасный режим - "safe_mode = On". Ко всему прочему мы можем включать безопасный режим не для всех сайтов сразу, как было при mod_php, например можно выключить безопасный режим для некоторых служебных сайтов. Заключение ---------- Осталась только проблема с доступом к чужим файлам из CGI-скриптов клиентов. Вроде всё, надеюсь возникшие проблемы можно будет решить. _________________________________________________________________ Дополнение Проблему с чтением файлов других пользователей при помощи CGI-скриптов можно решить при помощи правильно выставленных прав. Схема простая - каждый пользователь входит в свою группу (например pupkin:pupkin и vasya:vasya), пользователь, от имени которого запускается Апач, также имеет свою группу (например www:www), все файлы доступны для редактирования только владельцам, а для чтения - только группе, остальным - ничего (640). Для того, чтобы Апач смог прочитать файлы пользователей он должен входить в каждую группу, вот пример из /etc/group: pupkin:*:1001:www vasya:*:1002:www Чтобы при создании файла права сразу присваивались какие нам надо в данном случае, можно поменять значение параметра umask в файле /etc/login.conf. По-умолчанию umask=022 и значит созданные файлы будут доступны для чтения всем, а если это папка, то ещё и будет право на запуск для всех. Мы можем поменять это значение на 027 и никто кроме владельца и группы не будут иметь прав на чтение созданного файла. Только не забудьте запустить команду "cap_mkdb /etc/login.conf". Маска применяется к правам с помощью операции логического умножения с отрицанием. Малик /20040112/

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Малик (?), 15:09, 23/01/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лучше почитать статью на оригинальном ресурсе, т.к. я дописал несколько достаточно важных дополнений.
     
  • 1.2, tankistua (?), 00:49, 13/03/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    вооьще-то существует модуль для апача. suphp называется
     
  • 1.4, Дмитрий (??), 16:45, 24/01/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если апач включен в обе группы, значит один у другого пользователя сможет прочитать файлы. Я правильно понимаю?
    Это не есть гуд. Совсем не гуд.
     
  • 1.5, resu (??), 18:32, 14/03/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    по моему надо ставить в chroot все.
    т.е. сам  апач плюс ОБЯЗАТЕЛьНО КАЖДЫЙ виртуальный хост. т.е. внутри апачя надо делать chroot для всех и каждого + su_uid + su_gid.


    to  tankistua:
    suPHP - может делать (если я парвильно понял конфиг) только один chroot для всего модуля (по крайней мере я не нашел возможности указать / передать chroot - dir через httpd.conf для каждого виртуального хоста). (поправьте если ошибаюсь)

     
     
  • 2.8, stellar (??), 11:45, 15/09/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > моему надо ставить в chroot все.

    Бред какой. Оставьте свое мнение при себе - умнее будете выглядеть.

    Статья идиотская, не читайте ее.

     
     
  • 3.9, resu (??), 16:26, 15/09/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > Бред какой. Оставьте свое ...

    не аргументиревано

     
  • 2.14, Михаил (??), 13:06, 10/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    угу, плюс если делать chroot то скрипт лежаший (к примеру) в /home/user/site , при chroot'е (/home/user) должен еще лежать и в /home/user/home/usr/site, т.е. приходиться делать символическую ссылку.

    в SUPHP есть единственная возможность установить различия между сайтами в создании конфига PHP для каждого сайта в отдельности. suPHP_config (точно непомню) в Virtual Host'е кокраз это  и делает.

     

  • 1.6, dodger (??), 12:08, 04/07/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ложить бинарник php в cgi-bin - безумие.

    http://php.benscom.com/manual/ru/security.cgi-bin.php

     
     
  • 2.7, Zed (??), 12:13, 11/09/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Ну там же и читаем:
    В PHP, указывая во время компиляции опцию --enable-force-cgi-redirect, а таке опции doc_root и user_dir во время выполнения скрипта, можно предотвратить подобные атаки для директорий с ограниченным доступом.


    Опция --enable-force-cgi-redirect в статье указана.

     

  • 1.10, justhost (?), 20:44, 01/03/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да в статье полный гимор)
    Все делается намного проще и нет необходимости копировать php в каждую cgi-bin директорию для каждого юзверя.

    Нужно сделать лишь следующее:
    1-перекинуть php исполняемый файл или создать линк на него в директорию /var/www/cgi-bin

    2-в httpd.conf добавть 3 строчки
    AddType application/x-httpd-php php
    ScriptAliase /php/ /var/www/cgi-bin/
    Action application/x-httpd-php /php/php

     
  • 1.11, justhost (?), 20:45, 01/03/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    или /usr/local/apache/cgi-bin
    у кого как...
     
  • 1.12, Android (??), 13:59, 17/05/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А кто-нибуть юзал Apache dkLab?
     
  • 1.13, x_o_x (ok), 08:17, 31/05/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кстати. Что скажите по поводу безопасности сего пача для suexec?

    if (strstr(cmd, ".php")) {
            execl("/usr/local/bin/php","php",cmd,NULL);
        } else {
        execv(cmd, &argv[3]);
        }
    , где /usr/local/bin/php - php-cgi

     
  • 1.15, VArtem (ok), 20:27, 02/01/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Статья хорошая. Смог для себя подчеркнуть некоторые вещи. Спасибо
     
  • 1.16, w3site.org (?), 16:02, 24/11/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Пользователей для веба заводить только в соответствующую группу,
    например webusers."

    Лутше сделать группу и пользователя идентичными
    а группу сделать для апачиотдельно, по группе сможет читать апачи а по имени пользователя - пользователь и в соответствии выставляь chmod и chown

     

    игнорирование участников | лог модерирования

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру