Решая, какие разрешения использовать, вы должны точно знать, кто ваши пользователи и что им нужно. Веб-сервер взаимодействует с двумя типами пользователей.
Прошедшие проверку пользователи имеют учетную запись на сервере, и им могут быть предоставлены определенные привилегии. Обычно это системные администраторы, разработчики и учетные записи служб. Они обычно вносят изменения в систему, используя SSH или SFTP.
Анонимные пользователи - это посетители вашего сайта. Хотя у них нет прав доступа к файлам напрямую, они могут запросить веб-страницу, и веб-сервер действует от их имени. Вы можете ограничить доступ анонимных пользователей, внимательно следя за тем, какие разрешения имеет процесс веб-сервера. Во многих дистрибутивах Linux Apache работает как www-dataпользователь, но может отличаться. Используйте ps aux | grep httpdили, ps aux | grep apacheчтобы увидеть, какой пользователь Apache использует в вашей системе.
Примечания о разрешениях Linux
Linux и другие POSIX-совместимые системы используют традиционные разрешения Unix. В Википедии есть отличная статья о разрешениях Файловой системы, поэтому я не буду здесь все повторять. Но есть несколько вещей, о которых вы должны знать.
Бит выполнения
Интерпретируемые сценарии (например, Ruby, PHP) работают нормально без разрешения на выполнение. Только исполняемые файлы и сценарии оболочки нуждаются в бите выполнения. Чтобы пройти (войти) в каталог, вам необходимо иметь разрешение на выполнение для этого каталога. Веб-серверу необходимо это разрешение для просмотра каталога или обслуживания любых файлов внутри него.
Права доступа к новому файлу по умолчанию
Когда файл создается, он обычно наследует идентификатор группы того, кто его создал. Но иногда вы хотите, чтобы новые файлы наследовали идентификатор группы папки, в которой они созданы, поэтому вы должны включить бит SGID в родительской папке.
Значения разрешений по умолчанию зависят от вашего umask. Umask вычитает разрешения из вновь созданных файлов, поэтому общее значение 022 приводит к созданию файлов с 755. При совместной работе с группой полезно изменить Umask на 002, чтобы создаваемые вами файлы могли быть изменены членами группы. И если вы хотите настроить права доступа для загружаемых файлов, вам нужно либо изменить umask для apache, либо запустить chmod после загрузки файла.
Проблема с 777
Когда вы chmod 777ваш сайт, у вас нет никакой безопасности вообще. Любой пользователь в системе может изменить или удалить любой файл на вашем сайте. Но если серьезно, помните, что веб-сервер действует от имени посетителей вашего сайта, и теперь веб-сервер может изменять те же файлы, которые он выполняет. Если на вашем веб-сайте есть какие-либо программные уязвимости, их можно использовать для порчи вашего веб-сайта, вставки фишинговых атак или кражи информации с вашего сервера, даже если вы об этом не узнаете.
Кроме того, если ваш сервер работает на общеизвестном порту (который должен препятствовать тому, чтобы пользователи без полномочий root создавали службы прослушивания, доступные во всем мире), это означает, что ваш сервер должен быть запущен пользователем root (хотя любой нормальный сервер будет немедленно отброшен). на менее привилегированную учетную запись, когда порт привязан). Другими словами, если вы запускаете веб-сервер, где основной исполняемый файл является частью системы управления версиями (например, приложение CGI), оставляя свои разрешения (или, в этом отношении, разрешения содержащего каталог, так как пользователь может переименовать (777) позволяет любому пользователю запускать любой исполняемый файл от имени пользователя root.
Определите требования
- Разработчикам необходим доступ на чтение и запись к файлам, чтобы они могли обновлять веб-сайт
- Разработчики должны читать / писать / выполнять каталоги, чтобы они могли просматривать
- Apache нужен доступ для чтения к файлам и интерпретируемым скриптам
- Apache нужен доступ на чтение / выполнение к обслуживаемым каталогам
- Apache нужен доступ для чтения / записи / выполнения к каталогам для загруженного контента
Поддерживается одним пользователем
Если за обслуживание сайта отвечает только один пользователь, установите его в качестве владельца пользователя в каталоге веб-сайта и предоставьте пользователю полные разрешения rwx. Apache все еще нуждается в доступе, чтобы он мог обслуживать файлы, поэтому установите www-data в качестве владельца группы и предоставьте группе разрешения rx.
В вашем случае, Eve, чье имя пользователя может быть eve, является единственным пользователем, который поддерживает contoso.com:
chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve www-data 4096 Feb 5 22:52 contoso.com
Если у вас есть папки, которые должны быть доступны для записи Apache, вы можете просто изменить значения разрешений для владельца группы, чтобы у www-данных был доступ для записи.
chmod g+w uploads
ls -l
drwxrws--- 2 eve www-data 4096 Feb 5 22:52 uploads
Преимущество этой конфигурации заключается в том, что другим пользователям в системе становится труднее (но не невозможно *) шпионить, поскольку только пользователи и владельцы групп могут просматривать каталог вашего веб-сайта. Это полезно, если у вас есть секретные данные в ваших файлах конфигурации. Будь осторожен с маской! Если вы создадите новый файл здесь, значения разрешений, вероятно, будут по умолчанию равны 755. Вы можете запустить, umask 027чтобы новые файлы по умолчанию равнялись 640 ( rw- r-- ---).
Поддерживается группой пользователей
Если за обслуживание сайта отвечают несколько пользователей, вам необходимо создать группу, которая будет использоваться для назначения разрешений. Рекомендуется создать отдельную группу для каждого веб-сайта и назвать группу в честь этого веб-сайта.
groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob
В предыдущем примере мы использовали владельца группы для предоставления прав Apache, но теперь это используется для группы разработчиков. Поскольку владелец пользователя нам больше не нужен, установка его в root - это простой способ убедиться, что никакие привилегии не пропущены. Apache все еще нуждается в доступе, поэтому мы предоставляем доступ для чтения остальному миру.
chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root dev-fabrikam 4096 Feb 5 22:52 fabrikam.com
Если у вас есть папки, которые должны быть доступны для записи Apache, вы можете сделать Apache владельцем или пользователем группы. В любом случае, у него будет все необходимое для доступа. Лично я предпочитаю сделать его владельцем, чтобы разработчики все еще могли просматривать и изменять содержимое папок загрузки.
chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data dev-fabrikam 4096 Feb 5 22:52 uploads
Хотя это общий подход, есть и обратная сторона. Поскольку любой другой пользователь в системе имеет те же права на ваш веб-сайт, что и Apache, другие пользователи могут легко просматривать ваш сайт и читать файлы, которые могут содержать секретные данные, такие как файлы конфигурации.
Вы можете съесть свой торт и съесть его тоже
Это может быть улучшено в дальнейшем. Для владельца совершенно законно иметь меньше привилегий, чем для группы, поэтому вместо того, чтобы тратить владельца пользователя, назначив его пользователю root, мы можем сделать Apache владельцем пользователя для каталогов и файлов на вашем веб-сайте. Это аннулирование сценария с одним сопровождающим, но он работает одинаково хорошо.
chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data dev-fabrikam 4096 Feb 5 22:52 fabrikam.com
Если у вас есть папки, которые должны быть доступны для записи Apache, вы можете просто изменить значения разрешений для владельца пользователя, чтобы у www-данных был доступ для записи.
chmod u+w uploads
ls -l
drwxrwx--- 2 www-data dev-fabrikam 4096 Feb 5 22:52 fabrikam.com
С этим решением следует быть осторожным: пользователь, которому принадлежат новые файлы, будет соответствовать создателю, а не устанавливать www-data. Поэтому любые новые файлы, которые вы создаете, не будут доступны для чтения Apache, пока вы не создадите их.
* Разделение привилегий Apache
Ранее я упоминал, что другие пользователи могут просматривать ваш сайт независимо от того, какие привилегии вы используете. По умолчанию все процессы Apache выполняются как один и тот же пользователь www-данных, поэтому любой процесс Apache может читать файлы со всех других веб-сайтов, настроенных на том же сервере, а иногда даже вносить изменения. Любой пользователь, который может заставить Apache запускать скрипт, может получить тот же доступ, что и сам Apache.
Для решения этой проблемы в Apache существуют различные подходы к разделению привилегий . Однако каждый подход имеет свои недостатки в производительности и безопасности. По моему мнению, любой сайт с более высокими требованиями безопасности должен быть запущен на выделенном сервере, а не на виртуальных хостах на общем сервере.
Дополнительные соображения
Я не упоминал об этом раньше, но обычно это плохая практика, когда разработчики редактируют сайт напрямую. Для более крупных сайтов вам лучше иметь какую-то систему выпуска, которая обновляет веб-сервер из содержимого системы контроля версий. Подход с одним сопровождающим, вероятно, идеален, но вместо человека у вас есть автоматизированное программное обеспечение.
Если ваш веб-сайт позволяет загружать файлы, которые не нужно обслуживать, эти загрузки должны храниться где-то за пределами корневого веб-каталога. В противном случае вы можете обнаружить, что люди скачивают файлы, которые должны были быть секретными. Например, если вы разрешите учащимся отправлять задания, они должны быть сохранены в каталоге, который не обслуживается Apache. Это также хороший подход для файлов конфигурации, которые содержат секреты.
Для веб-сайта с более сложными требованиями вы можете изучить использование списков контроля доступа . Это позволяет гораздо более сложный контроль над привилегиями.
Если ваш веб-сайт имеет сложные требования, вы можете написать сценарий, который устанавливает все разрешения. Проверьте это полностью, затем сохраните это в безопасности. Это может быть на вес золота, если вам по какой-то причине понадобится перестроить ваш сайт.