Поддержка suEXEC

Функция suEXEC предоставляет пользователям Apache HTTP Server возможность запускать программы CGI и SSI под идентификаторами пользователей, отличными от идентификатора пользователя веб-сервера. Обычно, когда программа CGI или SSI выполняется, она работает под тем же пользователем, что и веб-сервер.

При правильном использовании эта функция значительно снижает риски безопасности, связанные с предоставлением пользователям возможности разработки и запуска собственных программ CGI или SSI. Однако, если suEXEC неправильно настроено, это может привести к различным проблемам и, возможно, создать новые уязвимости в системе. Если вы не знакомы с управлением программами с setuid root и проблемами безопасности, связанными с ними, мы настоятельно рекомендуем не использовать suEXEC.

Перед началом

Прежде чем углубляться в этот документ, вы должны понимать, что делаются определенные предположения о вас и среде, в которой вы будете использовать suexec.

Во-первых, предполагается, что вы используете операционную систему, производную от UNIX, способную выполнять операции setuid и setgid. Все примеры команд представлены в этом контексте. Другие платформы, если они способны поддерживать suEXEC, могут отличаться в настройках.

Во-вторых, предполагается, что вы знакомы с некоторыми основными концепциями безопасности и администрирования вашей системы. Это включает в себя понимание операций setuid/setgid и их влияния на систему и уровень её безопасности.

В-третьих, предполагается, что вы используете немодифицированную версию кода suEXEC. Весь код suEXEC тщательно проверен и протестирован разработчиками, а также многочисленными бета-тестерами. Приняты все меры предосторожности для обеспечения простого и надёжного кода. Изменение этого кода может привести к непредвиденным проблемам и новым рискам безопасности. Настоятельно рекомендуется не изменять код suEXEC, если вы не являетесь экспертом в программировании безопасности и не готовы поделиться своей работой с командой разработчиков Apache HTTP Server для рассмотрения.

В-четвертых, и наконец, команда разработчиков Apache HTTP Server приняла решение НЕ включать suEXEC в стандартную установку Apache httpd. В связи с этим, настройка suEXEC требует от администратора внимательного отношения к деталям. После тщательного рассмотрения различных настроек suEXEC администратор может установить suEXEC стандартными методами. Значения этих настроек должны быть тщательно определены и указаны администратором для надёжной защиты системы при использовании функциональности suEXEC. Мы надеемся, что этот подробный процесс позволит ограничить установку suEXEC только тем, кто достаточно внимателен и решителен для её использования.

Всё ещё с нами? Хорошо. Перейдём дальше!

Модель безопасности suEXEC

Перед началом настройки и установки suEXEC мы обсудим модель безопасности, которую вы собираетесь реализовать. Это позволит лучше понять, что происходит внутри suEXEC и какие меры предосторожности принимаются для обеспечения безопасности вашей системы.

suEXEC основан на программе-обёртке setuid, которая вызывается основным Apache HTTP Server. Эта обёртка вызывается при поступлении HTTP-запроса на программу CGI или SSI, которую администратор назначил для выполнения под другим идентификатором пользователя, отличным от основного сервера. При получении такого запроса Apache httpd предоставляет обёртке suEXEC имя программы и идентификаторы пользователя и группы, под которыми программа должна выполняться.

Затем обёртка использует следующий процесс для определения успеха или неудачи — если любое из этих условий не выполняется, программа записывает ошибку и завершается с ошибкой, в противном случае продолжит выполнение:

1. Является ли пользователь, выполняющий эту обёртку, валидным пользователем данной системы?

   Это гарантирует, что пользователь, выполняющий обёртку, действительно является пользователем системы.

2. Была ли обёртка вызвана с правильным количеством аргументов?

   Обёртка будет выполнена только в случае передачи правильного количества аргументов. Правильный формат аргументов известен Apache HTTP Server. Если обёртка получает неверное количество аргументов, это либо взлом, либо проблема с частью suEXEC вашего бинарного файла Apache httpd.

3. Разрешено ли этому валидному пользователю выполнять обёртку?

   Является ли этот пользователь пользователем, разрешённым для выполнения этой обёртки? Только один пользователь (пользователь Apache) имеет право выполнять эту программу.

4. Содержит ли целевая программа CGI или SSI небезопасную иерархическую ссылку?

   Содержит ли путь целевой программы CGI или SSI ведущий '/' или обратную ссылку '..'? Это не допускается; целевая программа CGI/SSI должна находиться в корневом каталоге suEXEC (см. --with-suexec-docroot=DIR ниже).

5. Является ли имя целевого пользователя валидным?

   Существует ли целевой пользователь?

6. Является ли имя целевой группы валидным?

   Существует ли целевая группа?

7. Целевой пользователь НЕ является суперпользователем?

   suEXEC не позволяет root запускать программы CGI/SSI.

8. Идентификатор целевого пользователя БОЛЬШЕ минимального значения?

   Минимальный номер идентификатора пользователя задаётся при настройке. Это позволяет установить наименьший возможный идентификатор пользователя, которому будет разрешено запускать программы CGI/SSI. Это полезно для блокировки «системных» учётных записей.

9. Целевая группа НЕ является группой суперпользователя?

   В настоящее время suEXEC не позволяет группе root запускать программы CGI/SSI.

10. Идентификатор целевой группы БОЛЬШЕ минимального значения?

    Минимальный номер идентификатора группы задаётся при настройке. Это позволяет установить наименьший возможный идентификатор группы, которому будет разрешено запускать программы CGI/SSI. Это полезно для блокировки «системных» групп.

11. Может ли обёртка успешно перейти к целевому пользователю и группе?

    Именно здесь программа становится целевым пользователем и группой посредством вызовов setuid и setgid. Список доступа к группе также инициализируется всеми группами, членами которых является пользователь.

12. Можем ли мы изменить каталог на тот, в котором находится целевая программа CGI/SSI?

    Если его нет, то в нём не может быть файлов. Если мы не можем перейти в этот каталог, то он, по сути, не существует.

13. Директория находится в пределах веб-пространства httpd?

    Если запрос относится к обычной части сервера, находится ли запрашиваемая директория в корневом каталоге suEXEC? Если запрос относится к UserDir, находится ли запрашиваемая директория в каталоге, настроенном как userdir suEXEC (см. Параметры конфигурации suEXEC)?

14. Директория НЕ доступна для записи другими пользователями?

    Мы не хотим открывать директорию для других пользователей; только владелец пользователя может изменять содержимое этой директории.

15. Существует ли целевая программа CGI/SSI?

    Если её нет, то её нельзя выполнить.

16. Целевая программа CGI/SSI НЕ доступна для записи другими пользователями?

    Мы не хотим предоставлять другим пользователям возможность изменять программу CGI/SSI.

17. Целевая программа CGI/SSI НЕ имеет setuid или setgid?

    Мы не хотим запускать программы, которые затем снова изменят наши UID/GID.

18. Целевой пользователь/группа совпадают с пользователем/группой программы?

    Является ли пользователь владельцем файла?

19. Можем ли мы успешно очистить среду процесса для обеспечения безопасной работы?

    suEXEC очищает среду процесса, устанавливая безопасный PATH (определённый во время конфигурации), а также передавая только те переменные, имена которых присутствуют в безопасном списке переменных (также созданном во время конфигурации).

20. Можем ли мы успешно стать целевой программой CGI/SSI и выполнить её?

    Здесь suEXEC заканчивается, и начинается целевая программа CGI/SSI.

Это стандартная работа модели безопасности обёртки suEXEC. Она довольно жёсткая и может накладывать новые ограничения и руководящие принципы для разработки CGI/SSI, но она была разработана тщательно, шаг за шагом, с учётом безопасности.

Для получения дополнительной информации о том, как эта модель безопасности может ограничивать ваши возможности в отношении конфигурации сервера, а также о том, какие риски безопасности можно избежать с правильной настройкой suEXEC, см. раздел "Осторожно: Джаббервокк" в этом документе.

Настройка и установка suEXEC

Вот где начинается самое интересное.

Параметры конфигурации suEXEC

--enable-suexec

Этот параметр включает функцию suEXEC, которая никогда не устанавливается или не активируется по умолчанию. По крайней мере, один параметр --with-suexec-xxxxx должен быть предоставлен вместе с параметром --enable-suexec, чтобы APACI принял ваш запрос на использование функции suEXEC.

--with-suexec-bin=PATH

Путь к двоичному файлу suexec должен быть жестко закодирован в сервере по соображениям безопасности. Используйте этот параметр для переопределения стандартного пути. Например --with-suexec-bin=/usr/sbin/suexec

--with-suexec-caller=UID

Имя пользователя, под которым обычно работает httpd. Это единственный пользователь, которому разрешено выполнять оболочку suEXEC.

--with-suexec-userdir=DIR

Определите подкаталог в домашнем каталоге пользователей, где должен быть разрешен доступ suEXEC. Все исполняемые файлы в этом каталоге будут исполняемыми для suEXEC как пользователем, поэтому они должны быть «безопасными» программами. Если вы используете директиву UserDir (т.е. без «*» в ней), это значение должно быть установлено одинаково. suEXEC не будет работать должным образом, если директива UserDir указывает на местоположение, которое не совпадает с домашним каталогом пользователя, как указано в файле passwd. Значение по умолчанию — "public_html".
Если у вас есть виртуальные хосты с разными UserDir для каждого, вам нужно определить, чтобы они все находились в одном родительском каталоге; затем укажите имя этого родительского каталога здесь. Если это не настроено должным образом, запросы CGI «~userdir» не будут работать!

--with-suexec-docroot=DIR

Определите это как DocumentRoot, заданный для httpd. Это будет единственная иерархия (кроме UserDir), которая может использоваться для поведения suEXEC. Каталог по умолчанию — значение --datadir с суффиксом "/htdocs", например, если вы настраиваете с "--datadir=/home/apache", каталог "/home/apache/htdocs" используется как корень документа для оболочки suEXEC.

--with-suexec-uidmin=UID

Определите это как наименьший UID, разрешенный в качестве целевого пользователя для suEXEC. Для большинства систем обычно используются значения 500 или 100. Значение по умолчанию — 100.

--with-suexec-gidmin=GID

Определите это как наименьший GID, разрешенный в качестве целевой группы для suEXEC. Для большинства систем обычно используется значение 100, и поэтому оно используется в качестве значения по умолчанию.

--with-suexec-logfile=FILE

Это определяет имя файла, в который записываются все транзакции и ошибки suEXEC (полезно для аудита и отладки). По умолчанию имя файла журнала — "suexec_log", и он находится в вашем стандартном каталоге журналов (--logfiledir).

--with-suexec-safepath=PATH

Определите безопасную переменную среды PATH для передачи исполняемым файлам CGI. Значение по умолчанию — "/usr/local/bin:/usr/bin:/bin".

Компиляция и установка оболочки suEXEC

Если вы включили функцию suEXEC с параметром --enable-suexec, двоичный файл suexec (вместе с самим httpd) автоматически скомпилируется, если вы выполните команду make.

После компиляции всех компонентов вы можете выполнить команду make install для их установки. Двоичный образ suexec устанавливается в каталог, определенный параметром --sbindir. По умолчанию это расположение — "/usr/local/apache2/bin/suexec".

Обратите внимание, что для этапа установки вам потребуются права root. Для корректного установки идентификатора пользователя оболочка должна устанавливаться как владелец root и должна иметь установленный бит выполнения setuserid для режимов файлов.

Настройка строгих разрешений

Хотя оболочка suEXEC проверит, чтобы вызывающий ее пользователь соответствовал указанному с параметром --with-suexec-caller configure пользователю, всегда существует возможность того, что вызов системы или библиотечной функции, используемой suEXEC до этой проверки, может быть уязвим в вашей системе. Для противодействия этому и в качестве лучшей практики в целом, вы должны использовать разрешения файловой системы, чтобы гарантировать, что только группа httpd может выполнять suEXEC.

Например, если ваш веб-сервер настроен на работу от имени:

User www
Group webgroup

и suexec установлен по пути "/usr/local/apache2/bin/suexec", вы должны выполнить:

chgrp webgroup /usr/local/apache2/bin/suexec
chmod 4750 /usr/local/apache2/bin/suexec

Это гарантирует, что только группа httpd может запускать оболочку suEXEC.

Включение и отключение suEXEC

При запуске httpd он ищет файл suexec в каталоге, определенном параметром --sbindir (по умолчанию — "/usr/local/apache/sbin/suexec"). Если httpd находит правильно настроенную оболочку suEXEC, он выведет следующее сообщение в журнал ошибок:

[notice] suEXEC mechanism enabled (wrapper: /path/to/suexec)

Если вы не видите этого сообщения при запуске сервера, сервер, скорее всего, не находит программу оболочки в ожидаемом месте или исполняемый файл не установлен с setuid root.

Если вы хотите впервые включить механизм suEXEC, а сервер Apache HTTP уже запущен, вам необходимо остановить и перезапустить httpd. Перезапуск с помощью простого сигнала HUP или USR1 будет недостаточно.

Если вы хотите отключить suEXEC, вы должны остановить и перезапустить httpd после удаления файла suexec.

Использование suEXEC

Запросы к программам CGI вызовут оболочку suEXEC только если они предназначены для виртуального хоста, содержащего директиву SuexecUserGroup или если они обрабатываются mod_userdir.

Виртуальные хосты:
Один из способов использования оболочки suEXEC — через директиву SuexecUserGroup в определениях VirtualHost. Установив эту директиву на значения, отличные от идентификатора пользователя основного сервера, все запросы к ресурсам CGI будут выполняться от имени пользователя и группы, определенных для этого <VirtualHost>. Если эта директива не указана для <VirtualHost>, предполагается идентификатор пользователя основного сервера.

Каталоги пользователей:
Запросы, обрабатываемые mod_userdir будут вызывать оболочку suEXEC для выполнения программ CGI от имени пользователя запрашиваемого каталога пользователя. Единственное требование для работы этой функции — разрешение выполнения CGI для пользователя, и сценарий должен пройти проверку безопасности, описанную выше. См. также --with-suexec-userdir параметр времени компиляции.

Отладка suEXEC

Оболочка suEXEC будет записывать информацию журнала в файл, определенный параметром --with-suexec-logfile, как указано выше. Если вы считаете, что оболочка на настроена и установлена правильно, проверьте этот журнал и журнал ошибок сервера, чтобы понять, где вы допустили ошибку.

Осторожно: предупреждения и примеры

ПРИМЕЧАНИЕ! Этот раздел может быть неполным.

Существуют некоторые моменты, связанные с оболочкой, которые могут ограничить настройку сервера. Проверьте их, прежде чем сообщать о «багах» в suEXEC.

Важные моменты suEXEC

• Ограничения иерархии

  По соображениям безопасности и эффективности, все запросы suEXEC должны оставаться либо в корневом каталоге верхнего уровня для запросов виртуальных хостов, либо в корневом каталоге верхнего уровня личного каталога для запросов userdir. Например, если у вас четыре настроенных VirtualHost, вам необходимо структурировать все каталоги документов ваших VHost из одной основной иерархии каталогов httpd, чтобы использовать suEXEC для VirtualHost. (Пример будет предоставлен.)

• Переменная среды PATH suEXEC

  Это может быть опасно для изменения. Убедитесь, что каждый путь, который вы включаете в это определение, является доверенным каталогом. Вы не хотите открыть людям доступ к тому, чтобы кто-то из другой страны запустил у них троянского коня.

• Изменение кода suEXEC

  Опять же, это может привести к серьезным проблемам, если вы это сделаете, не понимая, что делаете. Старайтесь избегать этого, если это возможно.