Я использую suexec, чтобы убедиться, что сценарии PHP (и другие приложения CGI / FastCGI) запускаются от имени владельца учетной записи, связанной с соответствующим виртуальным хостом. Это позволяет защитить скрипты каждого пользователя от чтения / записи другими пользователями.
Однако мне приходит в голову, что это открывает другую дыру в безопасности. Раньше веб-сервер работал как непривилегированный пользователь с доступом только для чтения к файлам пользователя (если только пользователь по какой-либо причине не изменил права доступа к файлам). Теперь веб-сервер также может писать в файлы пользователя.
Поэтому, хотя я не позволял различным пользователям использовать сценарии друг друга, я сделал это так, что в случае, если какое-либо приложение имеет уязвимость удаленного внедрения кода, оно теперь имеет не только доступ для чтения, но и доступ для записи ко всем этим пользователям. скрипты и сайт.
Как мне с этим справиться?
У меня была одна идея - создать вторую учетную запись для каждой учетной записи пользователя в системе, чтобы у каждого пользователя была собственная учетная запись, а все их сценарии запускались под другой учетной записью. Но это кажется громоздким.
Запуск PHP с разрешениями веб-сервера не обязательно лучше или хуже чем при использовании SuPHP. Это просто разные. Первая модель отделяет владельца от веб-сервера, а вторая модель отделяет владельца (и его код PHP) от всех остальных пользователей на машине.
Использование suPHP не обязательно увеличивает вашу общую безопасность, оно просто перенаправляет его. Вместо того, чтобы пытаться предотвратить взлом, вы изолируете сайты друг от друга. Оправданием является то, что, особенно в среде с общим хостингом, прежняя модель безопасности просто не работала: пользователи постоянно пробивали дыры в своей безопасности, устанавливая разрешения на всемирную запись для всего, чтобы веб-приложение работало, а затем Компрометация безопасности одной учетной записи быстро приведет к метастазированию всех остальных на сервере.
Таким образом, вместо этого теперь стало обычным использовать такие инструменты, как suPHP, в крупных средах с общим хостингом, чтобы устранить барьер между пользователем и его приложением PHP, и вместо этого воздвигнуть барьер между пользователем и его соседями.
Итак, в этом случае вы не предоставляете безопасность, Вы предоставляете разделение. К сожалению, suPHP требует, чтобы файлы были принадлежащий пользователем, от имени которого вы собираетесь работать, поэтому создание отдельного пользователя FTP будет ... беспорядком. Вам постоянно придется chown файлы между пользователем suPHP и пользователем FTP.
Вместо этого вам нужно выбрать роль: либо вы защищаете сайт, либо защищаете сервер. Если вы хотите защитить сайт, вам необходимо отделить веб-сервер от владельца контента. Это довольно сложные отношения, которые нужно правильно поддерживать, поэтому не рекомендуется для сред общего хостинга. Если вместо этого вы хотите защитить сервер от своих пользователей, затем используйте suPHP, чтобы отделить пользователя (и его код) от остальных на сервере. В этом случае пользователь несет ответственность за свою безопасность. Удачи, пользователь! Технически это является возможно иметь безопасное приложение PHP - по крайней мере теоретически.
Прежде всего, если владельцу файла не требуется права на запись, не давайте его ему. Вы можете сделать это, установив первое число разрешений UNIX. Это означает, что только root будет иметь доступ на запись к своим файлам. Это будет очень раздражать, когда им нужно будет обновить файлы, но вы сказали, что у них не должно быть доступа на запись ....
Во-вторых, они выполняют свой сценарий как конкретный пользователь. Если они заблокированы в файле с помощью open_basedir, не будет проблемой, если они смогут записывать свои файлы. Если есть взлом, он уничтожит только файлы этого пользователя. Даже без open_basedir они должны иметь возможность писать только в свои файлы, если у вас нет файлов с правами 777, что является другой проблемой.
В-третьих, многим веб-сайтам требуется доступ на запись, по крайней мере, к определенным файлам / папкам. Например, Wordpress должен писать в случае загрузки файла. Доступ для записи для веб-сайтов не обязательно является дырой в безопасности, если вы хорошо им управляете.
suexec - очень хорошее начало, и open_basedir гарантирует, что ваши пользователи с правом записи останутся в указанном каталоге.
suexec всегда казался мне кладжем для обхода того факта, что вы по своей сути находитесь в среде общего хостинга - разрешать ненадежным запросам вызывать скрипт в качестве владельца-владельца очень-очень плохо (и то, как установки WordPress получают root-права) - если бы вы были на выделенный хост, в конце концов, вы бы не установили все свои файлы в режим 0777. Простое удаление доступа на запись не поможет, потому что файлы все еще принадлежащий этим пользователем, и поэтому в конечном итоге может быть записан. Наличие двух отдельных пользователей тоже мало помогает по той же причине.
На мой взгляд, правильным решением было бы запускать скрипты от имени непривилегированного пользователя, но chroot их - возможно, FastCGI будет здесь хорошим решением ... где процесс fcgi привязан к корневому каталогу, но веб-сервер знает, где найти сокет, который он создает.
Я понимаю, что это не «ответ» как таковой, но я бы поставил деньги на кого-нибудь, кто придумал это раньше и, вероятно, реализовал его - возможно, даже в качестве патча для suexec сам (я бы предвидел ForceSUExecUID и ForceSUExecGID параметры, которые могут применяться для каждого виртуального хоста…)