LINUX.ORG.RU

Изоляция VirtualHost'ов

 , , , ,


1

1

Здравствуйте, много уважаемые магистры ВЕБа!

Задался интересным для себя вопросом, а как можно изолировать VirtualHost'ы веб сервера друг от друга, как это например делают разные хостинги, чтобы содержимое этих хостов не могло залезть в соседний? При этом, как можно предоставить этим виртуальным хостам доступ к какому-нибудь индивидуальному каталогу выше root'а для хранения конфиденциальных данных (логи, приватные файлы и тд)?

Заранее благодарю за ваши ответы и внимание к моему вопросу.

apache2-mpm-itk is an MPM module for the apache web server which allows you to run each of your virtual host under a separate uid and gid i.e. the scripts and configuration files for one virtual host are completely separated from that of others and therefore no longer have to be readable for all of them.

ktk ★★★★ ()

Не претендую на лучший ответ, но недавно меня попросили дать немного хостинга для WP одному сайтику. Я просто сделал:

  • отдельного пользователя
  • chroot ssh пользователю
  • php-fpm тоже сделал под этого пользователя и запер его в домашнем каталоге
  • логи, tmp и т.п. тоже все перенаправил в домашний каталог пользователя

Может что-то еще есть, пусть подскажут.

gruy ★★★ ()

Есть проекты, где setuid для каждого виртуального хоста делается сильно лучше, чем ITK. Для этого в ядро Linux грузится модуль помогающий пользователю www-data делать setuid на определенный диапазон UID (владельцев виртуальных хостов apache). Обратное переключение делается стандартно за счет savedUID. Система состоит из модуля апаче, который определяет на какого пользователя нужно переключиться для данного VirtualHost и модуля ядра, который позволяет это делать пользователю www-data. В хуке apache на запись в лог делается возврат на www-data. Таким образом, для каждого пользователя виртуального хостинга делается свой пользователь и группа и все права разруливаются на уровне пользователей OS. В худшем случае злоумышленник сможет переключиться на любого пользователя виртуального хостинга (но без setuid апача это изначально так).

Когда-то я видел статью про такую схему, кажется на habr'е, но сейчас найти не смог. Однако за несколько лет до этого сам делал такую схему (идея лежит на поверхности). В моем случае модуль ядра после проверки, что текущий пользователь www-data, просто подменял savedUID на требуемый, после чего стандартный seteuid позволял менять пользователя и тот же seteuid менял его обратно после обработки запроса. Итого 3 системных вызова (подготовка - переключение пользователя - возврат пользователя, вызовы очень легкие) позволяли для каждого запроса устанавливать пользователя и менять его обратно на www-data. Модуль ядра был тривиальный, при его закрузке ему передавали три числовых параметра: UID www-data, минимальный и максимальный UID пользователей виртуального хостинга и он при вызове проверял, что текущий пользователь www-data, а требуемый в разрешенном диапазоне и в таком случае всего-лишь менял saved UID текущего процесса на требуемый (однако было это до того, как в seteuid завезли capabilities). Модуль апаче конфигурировал target UID для виртуального хоста по явно заданному параметру в конфигурации хоста либо по владельцу корневой папки виртуального хоста.

В общем, при желании такое можно написать и отладить без знакомства с программированием под ядро Linux где-то за неделю. Или найти готовое решение.

anonymous ()

Ненужно, от словав вообще. Запиливается каждому пользователю своя виртуалка или свой контейнер, если у каждого юзера свой фиксированный IP - то он просто назначается виртуалке ли коннтейнеру, если адрес один или ощий пул - на вход вешается nginx или какой-нибудь haproxy.

Nastishka ★★★★ ()
Ответ на: комментарий от TuzelKO

Читайте по буквам: «каждому пользоателю своя виртуалка ИЛИ СВОЙ КОНТЕЙНЕР». Не хотите виртуалок - делайте контейнеры. Оверхеда там не особо много, а изоляция существенно лучше (и проще, потмоу что за вас уже всё сделали) чем луюбый шаманские пляски с виртуалхостами.

Nastishka ★★★★ ()
Последнее исправление: Nastishka (всего исправлений: 1)

https://redmine.lighttpd.net/projects/lighttpd/wiki/HowToSetupFastCgiIndividu...

Статья из официальной документации Лайти. Предлагается под каждый виртуальный хост запускать отдельный FastCGI соккет, что в купе с грамотной настройкой прав доступа к каталогам файловой системы позволит обеспечить достаточный уровень безопасности.

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

TuzelKO ()