Вопрос: Почему «chmod -R 777 /» разрушительный?


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

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

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


244
2018-02-28 21:25


Источник


Я затаил дыхание, когда увидел этот вопрос. - Alireza Savand


Ответы:


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


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

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

  1. Вы только позволили всем читать / изменять каждый файл в вашей системе.
    • Поцелуй безопасности паролей на прощание (любой может прочитать теневой файл и взломать ваши пароли, но зачем беспокоиться? Просто ИЗМЕНИТЬ пароль! Это намного проще!).
    • Поцелуй безопасности для ваших двоичных файлов до свидания (кто-то может просто написать новый login программа, которая позволяет им в любое время).
    • Поцелуй свои файлы до свидания: один пользователь неверно направляет rm -r / и все кончено. ОС было сказано, чтобы они делали все, что хотели!
  2. Вы разозлили каждую программу, которая проверяет разрешения на файлы перед запуском.
    sudo, sendmail, и множество других просто не начнут больше. Они будут проверять права доступа к ключевым файлам, видеть, что они не такие, какими они должны быть, и отбросить сообщение об ошибке.
    по аналогии ssh (ключевые файлы должны иметь определенные разрешения, в противном случае они «небезопасны», и по умолчанию SSH откажется их использовать).
  3. Вы уничтожили биты setuid / setgid в программах, которые у них были.
    Режим 777 на самом деле 0777, Среди вещей в этой ведущей цифре setuid а также setgid биты.
    Большинство программ, которые являются setuid / setgid, имеют этот бит, потому что они должны запускаться с определенными привилегиями. Теперь они сломаны.
  4. Ты сломался /tmp а также /var/tmp Другое дело в том, что восьмая цифра, получившая нуль, - это 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, вы вернете свои уродливые головы.


335
2018-02-28 21:46



По крайней мере, на некоторых системах /tmp будет исправлено после перезагрузки. Хотя все много других вещей, кажется, сломано. По крайней мере, в виртуальной машине, которую я только что протестировал, появляется перезагрузка. /tmp разрешения. В скрипте запуска должно быть что-то. - Zoredache
@Zoredache Systems, которые используют tmpfs обычно фиксируют себя, те, которые имеют / tmp на диске май (зависит от их сценариев запуска) - voretaq7
+1, указав, что setuid и setgid будут устранены. Это очень разрушительный аспект. Попробуйте запустить find / -perms -4000 -type f а также find / -perms -2000 -type f чтобы увидеть различные двоичные файлы, которые полагаются на эти флаги. - Kyle Smith
Ввод чего-то типа «less foo.txt» не будет выполнять файл, называемый less.txt, независимо от установленного бита исполняемого файла. Вам понадобится, чтобы каталог less.txt находился на вашем пути, и вам нужно будет ввести «less.txt foo.txt» - на самом деле это не случайная вещь. Даже если вы используете завершение оболочки, это будет меньше, и вам все равно придется добавить .txt. Чтобы вызвать случайный текстовый файл с исполняемым битом, вам нужно будет ./nameoffile.txt. - The Real Bill
@Deji everyone определяется как объединение множества, включая пользователя, который владеет файлом, пользователей в группе, которая владеет файлом, и пользователей, которые не соответствуют ни одному из этих критериев (буквально три восьмеричные цифры разрешения: User, Group, а также Other). Другими словами любой пользователь с доступом к системе, («Доступ» в этом контексте может быть учетной записью оболочки, как я обычно обращаюсь к ней, но также включает доступ через веб-форму / CGI, который записывает данные на диск: www теперь пользователь может писать в любой файл в системе, что означает случайные посетители тоже.) - voretaq7


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

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

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


100
2018-02-28 21:33