Comments 22
А что скажете про mpm-itk?
Ну и неплохо было бы исходники на github выложить.
Ну и неплохо было бы исходники на github выложить.
Поддерживаю вопрос про небходимость велосипеда в свете существования MPM-ITK. А исходники обнаружить несложно:
https://ibuffed.com/pub/ugidctl/ugidctl-0.1.1-preview/
https://ibuffed.com/pub/ugidctl/mod_ugidctl-1.0.1-preview/
https://ibuffed.com/pub/ugidctl/ugidctl-0.1.1-preview/
https://ibuffed.com/pub/ugidctl/mod_ugidctl-1.0.1-preview/
Несложно, но github вроде как стандарт уже. За архивы на малоизвестных сайтах уже давно не чествуют.
Отправил зеркала на гитхаб:
https://github.com/004helix/ugidctl
https://github.com/004helix/mod_ugidctl
https://github.com/004helix/ugidctl
https://github.com/004helix/mod_ugidctl
Это такой же «стандарт» как винда или андроид. То есть, не стандарт вообще. Пользуются многие, конечно, но навязывать (не путать с принуждением) не очень этично. У гитхаба есть несомненный плюс — найти нужный проект проще, чем где-то ещё, но этот плюс является следствием монополизации рынка. А ведь это даже не инструмент, а, по сути, коммерческий сервис. А решение выложить дерево исходников как есть на HTTP-сервере действительно несколько странное, но автору, видимо, для себя достаточно. Извиняюсь за оффтоп, конечно.
Тоже не понимаю, почему гитхаб это уже «стандарт». Ссылки на дерево исходников на http, кстати, я даже не публиковал. В статье просто ссылки на архивы с исходниками.
Открытые проекты принято размещать на специализированных хостингах.
Преимущество таких спецхостингов в том, что человек может не только код просмотреть онлайн, но и завести issue или прочитать документацию к проекту онлайн, подправить код или попросить добавить какие-то фичи. Это очень удобно, социализация во все поля :)
Раньше это были SourceForge, Google Code и т.д.
SourceForge себя скомпрометировал, Google Code закрылся и сам предложил перекинуть все проекты на Github.
Еще как вариант есть Bitbucket.
Вот тут можно прочитать про opensource best practices: opensource.com/business/14/9/community-best-practices-new-era-open-source
Преимущество таких спецхостингов в том, что человек может не только код просмотреть онлайн, но и завести issue или прочитать документацию к проекту онлайн, подправить код или попросить добавить какие-то фичи. Это очень удобно, социализация во все поля :)
Раньше это были SourceForge, Google Code и т.д.
SourceForge себя скомпрометировал, Google Code закрылся и сам предложил перекинуть все проекты на Github.
Еще как вариант есть Bitbucket.
Вот тут можно прочитать про opensource best practices: opensource.com/business/14/9/community-best-practices-new-era-open-source
Обратите внимание на «Quirks and warnings» на их сайте:
Т.е. осноное — все дочерние процессы висят от рута. Второе — после обработки запроса процесс может только завершиться, т.к. не способен обрабытывать запросы к других хостам. Сильный удар по производительности, не говоря уже про keep-alive соединения, в котором последующие запросы просто невозможны, если идут на другой хост.
Since mpm-itk has to be able to setuid(), it runs as root (although restricted with POSIX capabilities and seccomp v2 where possible) until the request is parsed and the vhost determined. This means that any code execution hole before the request is parsed will be a potential root security hole. (The most likely place is probably in mod_ssl.) This is not likely to change in the near future, as socket passing, the most likely alternative solution, is very hard to get to work properly in a number of common use cases (e.g. SSL).
Т.е. осноное — все дочерние процессы висят от рута. Второе — после обработки запроса процесс может только завершиться, т.к. не способен обрабытывать запросы к других хостам. Сильный удар по производительности, не говоря уже про keep-alive соединения, в котором последующие запросы просто невозможны, если идут на другой хост.
Тоже поддержу вопрос. Уже лет пять точно юзаю mpm-itk. Чем принципиально ваше решение лучше?
Вот прямо над вами ответили :)
mpm-itk делает switch на юзера только после парсинга запроса (т.е. в случае какого-то эксплойта для обработки запроса можно получить root), а эта библиотека делает всю обработку от юзера изначально.
mpm-itk делает switch на юзера только после парсинга запроса (т.е. в случае какого-то эксплойта для обработки запроса можно получить root), а эта библиотека делает всю обработку от юзера изначально.
Есть же perser, оно и chroot умеет.
Полагаю вы имели ввиду peruser MPM. Проект скорее мертв чем жив. Да и большие проблемы с масшрабированием у него были.
во FreeBSD-порте апача (не только второго, но и первого) уже лет 10 изоляция реализована стартовым скриптом. всё остальное — это изобретения дырявых велосипедов.
Может кому-нибудь пригодится. Довольно давно (уже лет 10 как) решил похожую задачу (разрешить доступ через веб к репозиториям CVS только юзерам, имеющим туда доступ на уровне файловой системы) с помощью скрипта securecgi (http://sourceforge.net/projects/securecgi/). Сам скрипт суидный, но он запускается только для того, чтобы запустить заданный cgi-скрипт (в моему случае perl-скрипт) под id пользователя из переменной окружения REMOTE_USER. Так что даже, если cgi-скрипт окажется дырявым, система не окажется полностью скомпрометированной.
В то время пытался через список рассылки апача уговорить разработчиков реализовать такую функциональность к коре или через модуль, но поддержки у них моя инициатива не нашла. Аргументация была более чем странная (на мой взгляд): если взломают http-юзера, то смогут запустить любой suid- файл под этим юзером, а это — полшага до рута.
В то время пытался через список рассылки апача уговорить разработчиков реализовать такую функциональность к коре или через модуль, но поддержки у них моя инициатива не нашла. Аргументация была более чем странная (на мой взгляд): если взломают http-юзера, то смогут запустить любой suid- файл под этим юзером, а это — полшага до рута.
Для безопасного запуска cgi-скриптов в apache давно есть suexec
Хороший способ. Мы в нет.ру использовали похожую схему под freebsd 4 и apache 1, пока не перестали использовать эту платформу в 2011-м. Похожую вплоть до обмена куками (ключем) между ядром и апачем.
У вас даже лучше реализация тем, что сначала рутовый процесс передает в ядро список uid, на которые можно менять euid дочерних apache. В нашем случае использовался не список uid, а принадлежность диапазону выделенных для веб-пользователей uid.
У вас даже лучше реализация тем, что сначала рутовый процесс передает в ядро список uid, на которые можно менять euid дочерних apache. В нашем случае использовался не список uid, а принадлежность диапазону выделенных для веб-пользователей uid.
Но я бы хотел предостеречь от применения этой схемы при наличии стандартных, хоть и более сложных, альтернатив. Мы это делали только для работы mod_php с uid пользователя, так как не было выбора — во времена php3 и php4 не было ни php-fpm, ни других нормально работающих. Все остальные проблемы изоляции (запрет доступа к файлам других пользователей и запуск CGI/FCGI скриптов) решаются стандартными средствами unix и apache.
Для mod_perl и многих других интерпретаторов, встроенных в apache, изоляция через смену uid ничего не дает, так как пространство глобальных имен переменных является общим для всех пользователей. Соответственно, это обеспечивает и возможность доступа к чужим приложениям, и вероятность конфликта при использовании одинаковых имен.
Для mod_perl и многих других интерпретаторов, встроенных в apache, изоляция через смену uid ничего не дает, так как пространство глобальных имен переменных является общим для всех пользователей. Соответственно, это обеспечивает и возможность доступа к чужим приложениям, и вероятность конфликта при использовании одинаковых имен.
Согласен, в первую очередь моя реализация рассчитана для mod_php. В случае запуска приложений отдельно с помощью php-fpm, uwsgi и т.п. сильно возрастают накладные расходы на память, если виртуальных хостов много, а по одельности у них небольшая посещаемость. Плюс можно использовать общий opcache для php, например, что тоже хорошо экономит память.
Sign up to leave a comment.
Изоляция виртуальных серверов в apache2 — ugidctl