Помимо закрытых ключей или паролей, зачем отключать другие = права доступа на чтение / выполнение / запись для «системы» (отдельно от пользователя / приложения) файлы?
Сводка
В системах Unix, Linux или BSD:
Кроме файлов с закрытым ключом или с паролем, , личным содержанием пользователя или любыми другими специфическими для конкретного приложения причинами. (например, обслуживание базы данных частной информации для пользователей или автоматизированных процессов, внутренних или внешних), зачем отключать другие права доступа к файлам (например: chmod -R o-rwx ]) для файлов, установленных системой ОС , соответствующее содержимое настроек конфигурации (часто находится в / lib и / etc ) nd дополнительные, общие / стандартные места ?
Пожалуйста, прочтите этот связанный вопрос («Почему у многих файлов Linux есть другие = доступ для чтения?») и ответы на него , прежде чем комментировать или отвечая.
Подробнее
Какие общие рассуждения или «лучшие практики» применимы к большинству любой системы, особенно к любой системе, предоставляющей услугу (популярные примеры включают, но не ограничиваются: DNS, SMTP, IMAP, HTTP и их безопасность варианты) в общедоступном Интернете?
Обратите внимание, что мы уделяем больше внимания системным файлам и меньше - информации для конкретного приложения или личной информации пользователя (например, многие файлы / каталоги, найденные в / home ).
Моя команда особенно заинтересована в общих парадигмах / лучших практиках для / etc , но вопрос относится к любой части любой файловой системы , созданной в Linux / Unix / BSD install.
В общем, мы бы предпочли оставить все, по умолчанию, для чтения другим (и / или исполняемым, и в редких случаях записать le) разрешения, которые обычно находятся в настройках по умолчанию для каждой ОС. Мы просто ищем лучшие практики, общие причины (они часто связаны с соображениями конфиденциальности и безопасности, но теперь всегда), по которым мы специально отключили бы любые разрешения для всего мира.
РЕДАКТИРОВАТЬ 2019-10- 23
Мы продолжаем исследование наших собственных систем. Мы запускаем варианты следующей команды в каталогах системных файлов (а именно / 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, иначе o-w, во многих системах.
чтение Удаления является также выбором, который можно сделать. Однако сделайте это в файлы, которые на самом деле не содержат секретную информацию, и Вы получите жалобы на "строгий umask". Просьба, чтобы кто-то вошел в Ваш веб-сервер и починил вещи, будет намного медленнее, если они не могут прочитать файл конфигурации. Если все пользователи с логинами поддерживают веб-сервер, почему отклоняют их обзор конфигурации?