Каковы идеальные минимальные разрешения в восьмеричном формате для написанного веб-приложения?
Вот мои предложения и обоснования
Теперь меня интересуют две вещи:
Предполагая, что «веб-приложение» работает на сервере (например, apache, nginx и т. Д.) И написано на каком-то динамическом языке сценариев (например, PHP, Ruby и т. Д.), Вы не понимаете, кто такой «пользователь».
Пользователь - это не человек, который вошел в ваше приложение, и его роль в приложении (администратор и т. Д.) Совершенно не имеет отношения к сценарию. Пользователь - это пользователь системы Linux, в которой выполняется процесс. Код вашего веб-сайта запускается только одним пользователем - это может быть пользователь вашего веб-сервера (что на самом деле не очень хорошо), или это может быть пользователь, специфичный для вашего сайта (что намного лучше).
В Linux пользователи принадлежат группам - мы можем добавить пользователя в другую группу и назначить ей права.
При хорошей настройке ваш сервер будет работать как один пользователь (назовем этого пользователя «веб-сервер»), а ваш динамический язык сценариев будет работать (например, через FastCGI) как собственный пользователь (один пользователь на сайт - назовем нашего первого пользователя «site1») .
Для обслуживания ваших файлов веб-серверу необходим доступ к ним, а языку сценариев - доступ к ним. Это означает: «site1» и «веб-сервер» должны иметь возможность читать ваши файлы. Однако только один из них может «владеть» файлами. Владелец - «пользователь» (пользователь, группа, другие). Нам также нужен наш язык сценариев, чтобы иметь возможность писать в каталог (и читать файлы, которые он написал). Следовательно, пользователю site1 требуются разрешения на чтение и запись. Поскольку мы хотим, чтобы групповые и другие разрешения были максимально ограниченными, нашим «владельцем» будет «site1», а соответствующие разрешения пользователя будут доступны для чтения и записи.
Поскольку мы не можем указать разрешения для нашего веб-сервера в качестве другого «пользователя», мы добавим «веб-сервер» в группу «site1» (вы, конечно, можете создать другую группу, содержащую как «site1», так и «веб-сервер». Все членам этой группы будут предоставлены одинаковые разрешения. Самые слабые разрешения (пользователя, группы или другого набора) будут применяться к любому данному пользователю для определения их разрешений.
Стоит отметить, что хорошая установка не должна требовать, чтобы файлы имели права на выполнение для динамического языка. Файлы не запускаются напрямую, а скорее считываются интерпретатором - для запуска типичного сценария (который ничего не записывает) необходимы только разрешения на чтение.
Разрешение на выполнение для каталогов имеет другое значение - оно разрешает обход без возможности чтения содержимого. Чтобы иметь возможность читать файл в каталоге, пользователь должен иметь права на выполнение для КАЖДОГО каталога над ним.
Для веб-приложения каждый файл должен иметь разрешения на чтение от своего владельца - в противном случае это довольно бессмысленный файл. Независимо от того, загружает ли файлы (через ваше веб-приложение) пользователь или администратор, «владельцу» (т.е. динамическому языку) требуются права на запись. Эффективная установка будет пытаться обслуживать статические файлы напрямую через веб-сервер, поскольку динамические языки, как правило, медленны при чтении больших файлов и отображении содержимого. Поэтому веб-серверу требуется доступ для чтения к вашим статическим файлам.
Следовательно, минимальные права доступа к файлам могут быть:
Хотя минимальные права доступа к каталогу могут быть:
Еще раз - ваш веб-сервер должен иметь разрешения на выполнение для каждого каталога, выше того, к которому ему нужен доступ - поэтому, даже если веб-сервер не будет обслуживать файлы из данного каталога, мы должны предоставить ему разрешения на выполнение.
Довольно часто веб-серверу предоставляется доступ для чтения к большинству файлов (поэтому измените эти 500 на 550). По умолчанию «несколько безопасные» разрешения обычно составляют 755 для каталогов и 644 для файлов - нет разрешений на выполнение, каждый может читать, и только пользователь может писать - вы заметите, что подавляющее большинство файлов в системе Linux имеют эти разрешения.
Имейте в виду, что «прочие» разрешения относятся к любому пользователю системы, который не является владельцем или членом группы (то есть всем остальным пользователям системы). Сохранять ограничения для ваших «других» разрешений - это хорошо, потому что эти пользователи неизвестны - вы явно не дали им разрешение. Другие разрешения часто проще всего использовать в скомпрометированной системе (например, одна из причин, почему / tmp является общей целью).
В контексте вышеизложенного я не думаю, что ваши последние два вопроса актуальны. Установите права доступа к каталогу на 550 (и права доступа к файлам на 440), а затем предоставьте пользователю права на запись для любых каталогов, в которые ваше приложение будет писать (т.е. каталог: 750; файл: 640).
(Вам, очевидно, потребуются разрешения на запись для загрузки файлов, но, если вы хотите, вы можете удалить их позже - возможно, если кто-то пишет в каталог, в который может писать только владелец - ваша учетная запись была скомпрометирована - это один причин сохранения ограничительных разрешений).
Наличие минимального набора разрешений для выполнения работы - это нормально. Если у вас есть веб-сервер и пользователи используют общую группу, вы можете удалить необходимость предоставления доступа к o. Разрешения также связаны с пользователями. Вы, кажется, неправильно поняли восьмеричные разрешения.
r-xr-xr-x не rw-rw-rw. Поскольку это каталог, то для создания / удаления файлов вам необходимо иметь x установить так 750 rwxr-x--- было бы хорошим местом для начала. Это позволяет пользователю, которому принадлежит каталог, добавлять / удалять файлы, а всем участникам общей группы - получать к ним доступ. В общем случае для каталогов можно использовать режим 0755, 0775 или 2775 (бит SGID для каталогов, для BSD и для Linux, если файловая система смонтирована с семантикой BSD, приведет к тому, что групповая ассоциация новых файлов будет соответствовать настройкам родительского каталога, а не GID по умолчанию создателя файла). Это позволяет всем пользователям проходить (входить и проходить через chdir) и читать (запускать команду ls или выполнять системные вызовы readdir / read) рассматриваемые каталоги. Альтернативы добавляют параметры группировки / записи и, как уже отмечалось, бит SGID в каталогах может помочь сохранить все файлы и подкаталоги, связанные с подходящей группой.
Для файлов обычно используется 0644 или, возможно, 0664 (доступно для чтения всем и либо для группы, либо для записи). Очевидно, что для сценариев CGI и двоичных файлов необходимо добавить x-бит; а для некоторых особых ситуаций с очень хорошо протестированными двоичными файлами можно добавить биты SUID или SGID. Обычно UNIX и Linux игнорируют бит SUID / SGID в сценариях и учитывают его семантику только для скомпилированных исполняемых двоичных файлов в собственном коде. Однако вы можете запускать свой сайт под чем-то вроде Apache с каким-то модулем вроде "setuidhack", который можно использовать, чтобы заставить веб-сервер учитывать биты SUID / SGID даже в интерпретируемых скриптах. (Это делается с помощью HTTP-демона stat (), который загружает каждый файл и использует свой собственный код fork () / execve (), интерполируя правильную строку интерпретатора в вектор execve (), а не просто передавая имя исполняемого файла непосредственно в execve () системный вызов).
Это всего лишь самые общие рекомендации. Они не «идеальны» для всех ситуаций, и вам обязательно нужно проконсультироваться с документацией для вашего веб-сервера и любого веб-приложения или фреймворков, которые вы устанавливаете и настраиваете ... и вы, вероятно, захотите проконсультироваться со специалистом по безопасности UNIX, прежде чем вы размещать любые ваши файлы, код или серверы в общедоступном Интернете.