Чтобы придать вес обсуждению, которое я веду, я попытаюсь найти конкретные примеры того, почему предоставление всем возможности читать каталог /root плохо с точки зрения безопасности.
Я нашёл в интернете множество примеров того, как люди повторяют мантру о том, что на самом деле нехорошо делать /root, скажем, 755 завивку, но никаких дополнительных доказательств этому нет.
Может ли кто-нибудь привести сценарий, при котором безопасность системы может быть скомпрометирована в этом случае? Чем менее надуманно, тем лучше - например, как может пострадать недавно установленная система Centos, если /root имеет 755 прав?
EDIT - Спасибо за ответы, но пока никаких конкретных примеров. Другими словами, как можно использовать тот факт, что /root виден, чтобы скомпрометировать систему? Есть ли примеры программ, которые устанавливаются и предполагают, что /root не доступен всем?
ПРАВКА 2 - Я думаю, что на данный момент все согласны с тем, что это не представляет большой угрозы безопасности, за исключением случаев, когда кто-то не проверяет права доступа и использует каталог так, как будто он предназначен только для пользователя root.
решение1
По сути, это ничем не отличается от рекомендации запретить другим пользователям читать домашний каталог любого другого пользователя.
Если по умолчанию доступно для чтения всем, то будет окно возможностей, когда вы сохраняете новый файл, который вы намерены сохранить в тайне. Всегда есть вероятность, что кто-то сможет скопировать его до того, как это сделаете вы chmod go-r.
решение2
По сути, я думаю, что это сводится к выбору, сделанному разработчиками ядра, и не более того. Почему? Потому что по умолчанию в . не должно быть почти ничего, что представляло бы какую-либо ценность для кого-либо /root. Никто не должен входить в систему как пользователь root для общих дел.
Например, на FreeBSD все могут читать /root. Некоторые файлы внутри /rootне могут быть прочитаны по соображениям безопасности, но вы все равно можете "увидеть", что эти файлы там есть ls(просто не можете их прочитать). Например, .historyустановлено, -rw-------но .loginесть -rw-r--r--.
FreeBSD имеет немного другой подход к безопасности, чем Linux. Исторически FreeBSD был для серверов, и хотя его можно запустить как Desktop, он действительно лучше (по умолчанию) в качестве сервера.
Лично я не вижу ничего плохого в этой схеме ( /rootможно прочитать).
В /rootFreeBSD на самом деле нет почти ничего, кроме конфигураций. Почта должна пересылаться реальному пользователю. Никто не должен входить в систему как пользователь root. Учетная запись должна использоваться только для установки и настройки программного обеспечения, а также для задач по обслуживанию. За исключением нескольких файлов, чувствительных к безопасности (вроде ) , на мой взгляд, в FreeBSD .historyнечего скрывать ./root
Для более подробной информации по этой теме попробуйтеРаздел руководства FreeBSD по безопасностиЯ не увидел ничего, что можно было бы сделать /rootчитаемым при быстром просмотре, но информации там много.
решение3
Возможно, нерадивый администратор ищет легко взламываемые пароли и оставляет вывод разбросанным (возможно, это некорректный вызов, но вы поняли идею):
# john-the-ripper /etc/shadow > ~/cracked-passwords.txt
решение4
Если бы ~rootони были доступны для записи, любой пользователь мог бы добавить свой ключ SSH в ~root/.ssh/authorized_keys, а затем получить root-доступ просто через ssh root@some-host.
Если ~root"просто" читаемо, у вас все еще есть доступ к файлу rootпользователя .bash_history, который может содержать пароли или другие учетные данные, введенные в командной строке. Или случайно введенные или вставленные в командную строку.
Конечно, вы не должны передавать защищенные данные в командной строке, но это предупреждение обычно рассматривается как малорискованное, потому что поймать его на лету — это рискованно, и другие пользователи в любом случае не должны иметь возможности прочитать ваши переменные среды. Если у вас есть доступ к rootфайлу .bash_history, у вас есть доступ к любым конфиденциальным данным, rootкоторые могли быть когда-либо введены таким образом, случайно или нет.
Конечно, есть способы смягчения этих проблем, например, запрет rootна вход в SSH, даже с ключевой аутентификацией. Или отключение истории оболочки. Или тщательная очистка. Но этосмягчения; это слои в луковице безопасности.
Быть ~root0700 — это еще один слой в этой луковице безопасности. Если вы не хотите плакать, не очищайте лук больше, чем нужно.