В системах Unix, Linux или BSD:
Кроме закрытый ключ или пароль файлы, частный пользовательский контент или любые причины, связанные с конкретным приложением (например, обслуживание базы данных частной информации для пользователей или автоматические процессы, внутренние или внешние), зачем отключать Другой права доступа к файлам (например: chmod -R o-rwx <file/directory>) для файлов, установленных ОС, связанное содержимое настроек конфигурации (часто встречается в /lib и /etc) и дополнительные, общие / стандартные места?
Пожалуйста, прочтите и поймите этот связанный вопрос («Почему у многих файлов Linux есть другие = доступ для чтения?») и ответы на него перед тем, как комментировать или отвечать.
Какие общие доводы или «лучшие практики» применимы к большинству любой системы, особенно к любой системе, предоставляющей услугу (популярные примеры включают, но не ограничиваются: DNS, SMTP, IMAP, HTTP и их безопасные варианты) в общедоступном Интернете?
Обратите внимание, что мы уделяем больше внимания система файлы и меньше информации о приложении или личной информации пользователя (например, многие файлы / каталоги, найденные в /home).
Моя команда особенно интересуется общими парадигмами / лучшими практиками для /etc, но вопрос касается любой части любая файловая система создается при установке Linux / Unix / BSD.
В общем, мы предпочли бы сохранить все разрешения по умолчанию, доступные для чтения (и / или исполняемые и, в редких случаях, доступные для записи), как это обычно бывает в настройках по умолчанию для каждой ОС. Мы просто ищем лучшие практики, Общее причины (они часто основаны на конфиденциальности и безопасности, но теперь всегда), по которым мы специально отключили бы любые разрешения на доступ к миру.
Мы продолжаем исследования наших собственных систем. Мы запускаем варианты следующей команды в каталогах системных файлов (а именно /etc) на наших различных хост-системах (все Ubuntu) для дальнейшей оценки. (Предложения и рекомендации по этому подходу приветствуются.)
find . -name .git -prune -o ! -type l \( ! -perm /o=r -a ! -perm /o=w -a ! -perm /o=x \) -exec ls -ld {} \+
Вы, администратор, реализуете политику, определяющую пользователей, которые могут получить доступ к файлам.
Надеюсь, очевидный пример: учетные данные пользователя должны быть защищены, потому что в противном случае аутентификация будет нарушена, а система скомпрометирована. Таким образом, файл / etc / shadow должен быть недоступен для чтения, иначе злоумышленники могут захватить хешированные пароли и взломать их.
Для файлов с меньшими ограничениями отключение некоторые этих разрешений для других отличается от удаления все из них.
Обычно какой-нибудь случайный человек, не владеющий файлом, не может его редактировать. Нежелательные изменения могут быть внесены либо случайно (просмотр в редакторе и сохранение со случайными символами), либо намеренно (предоставить администратору приложение, которого у них не должно быть). Вот почему вы увидите umask 0002, aka o-w, на многих системах.
Удаление чтения - это тоже ваш выбор. Однако сделайте это с файлами, которые на самом деле не содержат конфиденциальной информации, и вы получите жалобы на "ограничительную маску". Попросить кого-нибудь войти на ваш веб-сервер и исправить ситуацию будет намного медленнее, если он не сможет прочитать файл конфигурации. Если все пользователи с логинами поддерживают веб-сервер, зачем отказывать им в просмотре конфигурации?