Почему âchmod -R 777 /â € деструктивный?

  

Это Канонический вопрос о разрешении файла и Почему 777 является «разрушительным».

Я не спрашиваю, как исправить эту проблему, поскольку есть много ссылок на это уже на Server Fault (переустановить ОС). Почему он вообще делает что-то разрушительное?

Если вы когда-либо запускали эту команду, вы почти сразу же уничтожаете свою операционную систему. Я не понимаю, почему удаление ограничений влияет на существующие процессы. Например, если у меня нет доступа для чтения к чему-либо, и после быстрого тупика в терминале я вдруг получаю доступ ... почему это приводит к тому, что Linux ломается?

243 голоса | спросил samwise 29 FebruaryEurope/MoscowbWed, 29 Feb 2012 01:25:40 +0400000000amWed, 29 Feb 2012 01:25:40 +040012 2012, 01:25:40

2 ответа


332

Прежде всего, небольшая терминология nitpick: chmod не позволяет удалить разрешения. Это ИЗМЕНЕНИЯ .


Теперь мясо проблемы - режим 777 означает «Любой может читать, записывать или исполнять этот файл» - у вас есть предоставленное разрешение для кого-либо ( эффективно), какими бы они ни хотели.

Теперь, почему это плохо?

  1. Вы только что позволили всем читать /изменять каждый файл в вашей системе.
    • Почистите безопасность паролей до свидания (любой может прочитать теневой файл и взломать ваши пароли, но зачем беспокоиться? Просто измените пароль! Это намного проще!).
    • Поцелуй безопасности для ваших двоичных файлов до свидания (кто-то может просто написать новую программу login, которая позволяет им в любое время).
    • Поцелуй ваши файлы на прощание: один пользователь неверно перенаправляет rm -r /, и все кончено. OS было сказано позволить им делать все, что они хотели!
  2. Вы разозлили каждую программу, которая проверяет разрешения на файлы перед запуском.
    sudo, sendmail, а множество других просто будет не начинайте больше. Они будут проверять права доступа к ключевым файлам, видят, что они не те, кем они должны быть, и отбрасывают сообщение об ошибке.
    Точно так же ssh будет прерываться ужасно (файлы ключей должны иметь определенные разрешения, иначе они «небезопасны», и по умолчанию SSH откажется их использовать.)
  3. Вы уничтожили биты setuid /setgid в программах, которые у них были.
    Режим 777 на самом деле 0 777. Среди вещей в этой ведущей цифре находятся биты setuid и setgid.
    Большинство программ, которые являются setuid /setgid, имеют этот бит, потому что они должны запускаться с определенными привилегиями. Теперь они сломаны.
  4. Вы нарушили /tmp и /var/tmp Другая вещь в этой восьмеричной цифре, которая получила zero'd, - это sticky bit - то, что защищает файлы в /tmp/var/tmp) от удаления людьми, которые их не владеют.
    Есть (к сожалению) множество сценариев с плохой вежливостью, которые «очищают», выполняя rm -r /tmp/* и без липкого бита, установленного в /tmp вы можете поцеловать все файлы в этом каталоге на прощание.
    При исчезновении файлов с царапинами действительно могут нарушить некоторые плохо написанные программы ...
  5. Вы вызвали хаос в /dev /proc и подобных файловых системах
    Это скорее проблема старых систем Unix, где /dev - настоящая файловая система, а материал, который он содержит, - это специальные файлы, созданные с помощью mknod, поскольку изменение разрешений будет сохраняются при перезагрузках, но в любой системе с изменением разрешений вашего устройства могут возникнуть существенные проблемы, от очевидных рисков безопасности (каждый может прочитать каждый TTY) до менее очевидных потенциальных причин паники ядра.
    Credit to @Tonny for pointing out this possibility
  6. Сокеты и трубки могут сломаться или иметь другие проблемы Розетки и трубы могут полностью сломаться или быть подвергнуты вредному введению в результате того, что они сделаны в мире.
    Credit to @Tonny for pointing out this possibility
  7. Вы сделали каждый файл в своей исполняемой системе
    Многие люди имеют . в своей переменной окружения PATH (вы не должны!). Это может вызвать неприятный сюрприз, так как теперь любой может удалить файл, который удобно назвать как (скажем make или ls), и у вас есть шанс запустить ваш вредоносный код.
    Credit to @RichHomolka for pointing out this possibility
  8. В некоторых системах chmod сбрасывает списки контроля доступа (ACL)
    Это означает, что вы можете снова создать все свои списки управления доступом помимо исправления разрешений во всем мире (и является фактическим примером разрушающей команды).
    Credit to @JamesYoungman for pointing out this possibility

Будут ли работать все части системы, которые уже запущены? Наверное, на какое-то время.
Но в следующий раз, когда вам нужно запустить программу или перезапустить службу, или не дай бог REBOOT, ящик, в котором вы находитесь, в мире обид, как № 2 и № 3 выше, выведет их уродливые головы.

ответил voretaq7 29 FebruaryEurope/MoscowbWed, 29 Feb 2012 01:46:46 +0400000000amWed, 29 Feb 2012 01:46:46 +040012 2012, 01:46:46
99

Главное, что есть много инструментов, таких как ssh /sudo, которые проверяют права файловой системы для файлов ключей ключей. Если разрешения неверны, эти инструменты предназначены для отказа, так как это указывает на серьезную проблему безопасности. В моей тестовой системе Debian и, возможно, на других, возможность входа в систему завершается с ошибкой, вероятно, потому, что двоичный файл входа или что-то в PAM имеет проверки на наличие.

Таким образом, на самом деле это не так, что система уничтожена - многие инструменты предназначены для немедленного сбоя, когда права доступа неверны.

Если вы перезагрузите систему после выполнения chmod 777 -R /, она будет загружаться, и вы можете запускать процессы, которые не имеют явных проверок разрешения. Таким образом, система не совсем мертва, просто несколько непригодна для по дизайну .

ответил Zoredache 29 FebruaryEurope/MoscowbWed, 29 Feb 2012 01:33:13 +0400000000amWed, 29 Feb 2012 01:33:13 +040012 2012, 01:33:13

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132