ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] apache php path restrictions security



On Wed, 14 Mar 2007 11:08:19 +0200
Sergej Kandyla <_paix@xxxxxxxxxx> wrote:


> >Вообще говоря, сервер должен быть настроен так, чтобы можно было
> >безопасно выполнять любые CGI скрипты. Используйте suexec. Апач
> >запускайте в чруте. В чрут лишнего не кладите. Ну и проверьте все
> >права доступа. Ведь помимо php можно и perl вызвать, и еще что-то.
> >
> >  
> >
> Спасибо! я упустил этот момент, слишком увлекшись безопасностью php.
> Все скрипты и так  запускаются через suexec, но...... как выяснилось
> без ограничений путей.
> 
> Не подскажите чем кроме jail/chroot  можно ли сделать cgi  patch 
> restriction ?

В целом ни как. Ни кто не мешает запускать свои
бинарники, и делать там что угодно, если не делать noexec на файловой
системе.
Вообще лучше всё-таки загнать всё в jail и по возможности убрать оттуда
всё лишнее, чтобы усложнить жизнь тем, кто захочет обойти ограничения.
Если на машине вообще кроме apache+CGI не живет и очень уж не хочется
делать jail, то можно конечно обойтись suexec+ipfw с использованием
лимитов по UID, но я бы не стал так делать. Тем более, что сложностей с
jail нет ни каких. А уж в RELENG_6 особенно.

> 
> >jail и chroot - это не радикальные меры. Ни куда от них не дется,
> >если хочется безопасный массовый хостинг. У вас клиент может
> >выполнять CGI ? А может он в качестве CGI положить бинарник и
> >выполнить его ? Если да (а скорее всего так и есть), то всё равно
> >что будет в настройках PHP. Тем более, что способы обхода защит в
> >PHP время от времени находят. В случае массового хостинга стоит
> >исходить из того, что все ограничения, которые наложены настройками
> >php можно обойти.
> >
> >Рекомендую еще глянуть в сторону suphp http://www.suphp.org/Home.html
> >  
> >
> так и буду делать, новые сервера на jail .
> suphp смотрел, интересный проект, но php будет исполняться как CGI. 
> Производительность на порядок ниже чем FastCGI. Имхо suphp можно 
> рассматривать только как небольшое дополнение к FastCGI, если
> последний по какимто причинам пользователям  на хостинге не подойдет.

Да, PHP будет выполняться как CGI. Но ведь если у вас тысячи сайтов, то
FastCGI будет довольно накладно делать для всех. А CGI не так уж и
сильно тормозит. 10-30% CPU это не много, процессоры сейчас не так уж и
много стоят. Я тестировал suexec vs. mod_php . Другое дело, что
придется проститься с вещами типа eaccelerator, но не всем оно надо.

-- 
Zherdev Anatoly.



 




Copyright © Lexa Software, 1996-2009.