Уточнение: разрешение и владение процессом apache корневого веб-сайта
Я прочитал много статей о правильном / безопасном (1) владении и (2) разрешениях на доступ к каталогам и файлам в веб-каталогах, обслуживаемых apache (например, / var / www / ). Либо меня легко сбить с толку, либо есть много запутанных / противоречивых советов.
Обычные CMS, такие как drupal, wordpress и т. Д., Обычно рекомендуют 755 для каталогов, 644 для файлов. Однако также дается рекомендация передать групповое владение процессу apache всем содержимым корневого веб-сайта (например, chown -R: www-data / var / www / ).
(1) Первый вопрос: допустим, групповое владение каталогами и файлами в / var / www / * принадлежит www-data и, как обычно, пользователю процесса apache www-data - единственный член этой группы. Между тем, права собственности на каталоги и файлы в / var / www / * принадлежат обычному пользователю в системе Linux, который принадлежит к группе sudo (например, somesudouser ). Это дает нам что-то вроде:
---------- 1 somesudouser www-data 3012 Jan 10 13:46 some-file.php
d--------- 16 somesudouser www-data 12288 Jan 10 13:25 some-directory/
Учитывая вышеупомянутую структуру владения, безусловно, разрешение доступа для «других» может быть установлено на 0 ; например 750 для каталогов, 740 для файлов, и это не помешало бы apache правильно обслуживать эти файлы в ответ на запрос браузера:
-rwxr----- 1 somesudouser www-data 3012 Jan 10 13:46 some-file.php
drwxr-x--- 16 somesudouser www-data 12288 Jan 10 13:25 some-directory/
Что с этим не так? Я не вижу смысла устанавливать "другое" разрешение для чего-либо, кроме 0 (вместо часто рекомендуемых 5 для каталогов и 4 для файлов), и Я не вижу причин, по которым права собственности на файлы не должны быть установлены на 7 (вместо часто рекомендуемых 6 ). Что мне не хватает?
(2) Второй вопрос: когда групповое владение каталогами и файлами в корневом веб-каталоге принадлежит группе, которая не включает процесс apache (например, somesudouser: somesudouser ), процесс apache может взаимодействовать с каталоги и файлы в корневом веб-каталоге, только если это разрешено "другим" разрешением доступа. С точки зрения безопасности, имеет ли одно из следующих преимуществ / недостатков:
-rwx---r-- 1 somesudouser somesudouser 3012 Jan 10 13:46 some-file.php
drwx---r-x 16 somesudouser somesudouser 12288 Jan 10 13:25 some-directory/
Или:
-rwxr----- 1 somesudouser www-data 3012 Jan 10 13:46 some-file.php
drwxr-x--- 16 somesudouser www-data 12288 Jan 10 13:25 some-directory/
Или даже:
-r-------- 1 www-data www-data 3012 Jan 10 13:46 some-file.php
dr-x------ 16 www-data www-data 12288 Jan 10 13:25 some-directory/
(3) И, наконец, вопрос о разрешениях w . Допустим, процесс apache имеет групповое владение файлом, и эта группа имеет разрешение доступа 7 :
----rwx--- 1 somesudouser www-data 3012 Jan 10 13:46 some-file.php
Почему это проблема? Может ли злоумышленник захватить пользователя apache, отредактировать some-file.php и, таким образом, запустить вредоносный php в системе Linux? Как это сделать?
А как насчет того, чтобы каталог имел такие же права:
d---rwx--- 16 somesudouser www-data 12288 Jan 10 13:25 some-directory/
Может ли злоумышленник заставить процесс apache записывать новые файлы в этот каталог? Опять же, как это сделать?
Спасибо.
(1) Первый вопрос: ... как обычно, пользователь процесса apache www-data является единственным членом этой группы... Что с этим не так? Я не вижу смысла устанавливать разрешение "other" на что-либо, кроме 0 (вместо часто рекомендуемых 5 для каталогов и 4 для файлов)
Во-первых, добавление себя как системного администратора/разработчика в качестве члена группы www-data является совершенно хорошей и правильной идеей, поскольку это позволит вам работать с файлами и папками, созданными веб-сервером.
Если бы права root документа вашего веб-сервера были настроены подобным образом, с setgid bit на каталогах вы могли бы работать с файлами и папками, созданными веб-сервером, и, поскольку у вас есть право общей собственности на группу (и предполагается, что umask равен 002), веб-сервер мог бы нормально функционировать с полным доступом к файлам и папкам, которые были созданы вами, ftp'ed, created и т.д.
В этом случае вы правы, установка бита others в 0 была бы разумной, поскольку другие учетные записи UNIX не должны иметь никакого доступа к корню документа.
Я подозреваю, что в документации по CMS предлагается разрешить other иметь хотя бы read, потому что большинство непрофессиональных администраторов не будут достаточно осведомлены, чтобы настроить setgid и т.д., и поэтому в случае с файлами, принадлежащими www-data, вы будете other - это позволит вам хотя бы читать файлы и наоборот, серверу иметь доступ к вашим файлам.
(2) Второй вопрос: когда групповое право собственности на каталоги и файлы в корне web принадлежит группе, которая не включает процесс apache
Это может зависеть от того, для чего используется каталог, и нужен ли веб-серверу доступ на запись в него для работы. Как правило, вы должны предоставлять веб-серверу только те разрешения, которые необходимы ему для работы, но если веб-серверу необходимы разрешения, в идеале они должны быть назначены через роли владельца или группы. Если вы дадите всему миру доступ на чтение/запись только для того, чтобы ваш веб-сервер мог читать/писать, вы предоставите такую же свободу другим учетным записям пользователей UNIX. Например, другим "соседям" в общей системе, которые не должны иметь доступ к вашим файлам, но иногда могут, когда сисадмины оплошают, и да, я видел, как это происходит.
(3) И, наконец, вопрос о разрешениях w. Допустим, процесс apache имеет групповое право собственности на файл, и эта группа имеет разрешение доступа 7:
ну да, это будет главным источником ваших проблем, у вас есть веб-сервер, подключенный к интернету - который будет постоянно подвергаться злоупотреблениям, плохие люди пытаются захватить веб-сервер, чтобы сделать то, что они хотят - что может включать манипуляции с файлами в корне документа и на сайте, например. например,
- индексирование/исследование каталогов
- запись/ удаление файлов - когда веб-серверу нужно только читать эти файлы, чтобы функционировать
Примечание, в качестве общего вопроса безопасности злоупотребление файловой системой через веб-сервер может распространиться на остальную часть операционной системы, например, чтение паролей и т.д. Поэтому дополнительно у вас есть проблемы с разрешениями на просмотр веб-сервером чувствительной системной информации, паролей, журналов и т.д. за пределами корня документа.
Что касается разрешений корня документа, как выглядят хорошо настроенные разрешения? Я бы рекомендовал
а также прочитать