Проблемы безопасности выполнения Сценариев PHP как владелец файла PHP с suexec
Необходимо или монтировать диск неправильно или копировать данные в неправильное местоположение. Нет никакой локальной копии. Данные никогда не помещались на внешний диск.
Необходимо посмотреть на файлы/etc/fstab и/etc/mtab с диском, включенным, чтобы смочь найти реальную точку монтирования внешнего диска.
Выполнение PHP в соответствии с полномочиями веб-сервера не, не обязательно лучше или хуже, чем использование SuPHP. Это просто отличается. Первая модель разделяет владельца от веб-сервера, в то время как вторая модель разделяет владельца (и его код PHP) от всех других пользователей на машине.
Используя suPHP не обязательно увеличивает Вашу полную безопасность, он просто перенаправляет его. Вместо того, чтобы пытаться предотвратить взломы, Вы изолируете сайты друг от друга. Выравнивание состоит в том, что, особенно в размещающей общим образом среде, бывшая модель обеспечения безопасности просто не удавалась: пользователи постоянно уносили дыры в своей безопасности путем установки полномочий мировой записи на всем так, чтобы веб-приложение работало, и затем компромисс безопасности на одной учетной записи быстро метастазировал бы во все другие на сервере.
Так, вместо этого, распространено теперь использовать инструменты как suPHP в больших размещающих общим образом средах, чтобы снять барьер между пользователем и его приложением PHP, и вместо этого установить барьер между пользователем и его соседями.
Так, в этом случае Вы не обеспечиваете безопасность, Вы обеспечиваете разделение. К сожалению, suPHP требует, чтобы файлы принадлежали пользователю, которого Вы намереваетесь выполнить, поскольку, так создавая отдельного пользователя FTP была бы... путаница. Вы постоянно имели бы к chown файлы назад и вперед между suPHP пользователем и пользователем FTP.
Вместо этого необходимо выбрать роль: или Вы защищаете сайт, или Вы защищаете сервер. Если Вы хотите защитить сайт, то необходимо разделить веб-сервер от владельца содержания. Это - несколько сложные отношения для поддержания правильно, таким образом, они не рекомендуются для общих сред хостинга. Если, вместо этого, Вы хотите защитить сервер от его пользователей, то используйте suPHP для разделения пользователя (и его код) от других на сервере. В этом случае пользователь ответственен за свою собственную безопасность. Удача, пользователь! Технически возможно иметь безопасное приложение PHP - в теории, по крайней мере.
-
1Что относительно того, чтобы использовать suexec для запущения скриптов с некоторыми непривилегированными имя пользователя , и имя группы пользователя? Например, запуская скрипты как < www-data2>:< username> где www-data2 не имеет в основном никаких полномочий записи так или иначе, и пользователь может сделать файл перезаписываемым путем установки записи группы на. Затем сценарии can' t пишут в себя, но can' t пишут в другой users' перезаписываемые файлы также. I' m предположение, однако, который, учитывая, что люди don' t, кажется, делают это, должна быть причина против него... – thomasrutter 11 May 2010 в 10:45
-
2Проблема состоит в том, что каждый раз пользователь загружает файл по FTP, это появляется под владением HIS. Таким образом, администратор будет иметь в показанные файлы пользователю PHP каждый раз, когда пользователь FTP делает что-либо с ним. Можно сойти с рук это на мелком масштабе, но it' s не устойчивый в крупном масштабе. – tylerl 12 May 2010 в 09:40
suexec всегда казавшийся мне клудж для работы вокруг того, что Вы находитесь в по сути общей среде хостинга — разрешение недоверяемых запросов вызвать сценарий, поскольку пользователь владения очень очень плох (и как установки WordPress базированы) —, если бы Вы были на выделенном узле, то Вы не установили бы все свои файлы к режиму 0777, в конце концов. Просто удаление доступа для записи не помогло бы, потому что файлы все еще принадлежат тому пользователю и так в конечном счете записываемые. Наличие двух отдельных пользователей не помогает многому, также, по той же причине.
Правильное решение, по моему мнению, состояло бы в том, чтобы запустить скрипты как непривилегированного пользователя, но chroot их — возможно, FastCGI был бы хорошим решением здесь … , где процесс fcgi является chrooted, но веб-сервер знает, где найти сокет, он создает.
Я понимаю, что это не “ответ” как таковой, но я поместил бы деньги в кого-то придумывавшего это прежде и вероятно реализовал их — возможно, как раз когда патч к suexec самостоятельно (я предусмотрел бы ForceSUExecUID и ForceSUExecGID опции, которые могли быть применены на per-virtual-host основе …),
-
1SuExec совершенно приемлем. Это почти походит на you' ре, путающее его с SUID, укусило. Возможно, еще более приемлемый, чем chroot. (См.: kerneltrap.org/Linux/Abusing_chroot ) – Warner 10 May 2010 в 16:11
-
2Нет, I’m, не путающий что-либо. SuExec эффективно, бит SUID для сценариев — веб-сервер выполняет сценарии как пользователя, который владеет сценарием. Все “abusing chroot” сценарии полагаются на Вас являющийся суперпользователем: если you’re непривилегированный пользователь, который не является ни один владельцем файлов ни сценария суперпользователь и chrooted, you’re столь изолированный, как можно быть и от доступа для записи до user’s файлов и от доступа для чтения к другому people’s. – Mo. 10 May 2010 в 16:54
В первую очередь, если у владельца файла не должно быть доступа для записи, не давайте его им. Можно сделать это путем определения первого номера полномочий UNIX. Это означает, что только корень будет иметь доступ для записи к их файлам. Это будет очень раздражающим, когда они должны будут обновить файлы, но Вы сказали, что у них не должно быть доступа для записи....
Во-вторых, они выполняют свой сценарий как определенный пользователь. Если они будут заблокированы в файле с помощью open_basedir, то это не будет проблема, если они могут записать свои файлы. Если будет взлом, то он уничтожит только что файлы пользователя. Даже без open_basedir, они должны только смочь записать в их файлах, если у Вас нет файлов с 777 правами, который является другой проблемой.
В-третьих, многим веб-сайтам нужен доступ для записи к, по крайней мере, certains файлы/папки. На пример должен записать Wordpress в случае, если существует загрузка файла. Доступ для записи для веб-сайтов является не обязательно дырой в системе безопасности при управлении им хорошо.
suexec является очень хорошим началом, и open_basedir удостоверится, что Ваши пользователи с доступом для записи остаются в определенном каталоге.