Неправильно установлен chmod / 777. Проблемы?

33

Я пытался бежать, chmod -R 777 ./но в итоге набрал chmod -R 777 /и установил 777на всю мою машину. Что может пойти не так? Как я могу это исправить?

Vinnycx
источник
что может пойти не так в системе? это перестанет работать?
Vinnycx
6
Конечно, есть проблемы. SSH потерпит неудачу, например.
выступление
2
SSH завершается, если домашний каталог доступен для чтения всем пользователям. Установка всего на 777 - это все как root.
Празднование
3
См. Также serverfault.com/questions/364677/why-is-chmod-r-777-destructive, в котором более подробно рассказывается о том, что пойдет не так.
Жиль "ТАК - перестать быть злым"

Ответы:

46

Проблемы? Да много. Это можно исправить? Конечно. Быстрее, чем переустановка? Возможно нет.

Моя рекомендация - переустановить. Сохраните резервную копию существующей системы и восстановите список пакетов и содержимое файлов в /etcи /var. Для /usr/localвероятно, можно восстановить разрешения вручную. Для /homeи /srvвам придется восстановить разрешения из резервных копий.

Если это система с несколькими локальными пользователями, обратите внимание, что создание некоторых файлов для всеобщего чтения выявило некоторые вещи, которые должны были остаться конфиденциальными.

  • Ваш список паролей теперь скомпрометирован: локальные пользователи имеют доступ к хешированному списку паролей и могут попытаться их перебором. Сообщите своим пользователям об этом.
  • Все личные данные пользователя (ssh-ключи, сохраненные пароли, электронная почта, все, что пользователи могут считать конфиденциальными) были доступны всем локальным пользователям. Сообщите своим пользователям об этом.

Если вы действительно хотите попробовать восстановить (это скорее учебное упражнение, чем практический путь восстановления), сначала восстановите права доступа для нескольких файлов. Обратите внимание, что хотя большинство файлов теперь слишком открыты, в некоторых отсутствуют необходимые биты setuid . Вот шаги, которые вы должны предпринять прежде всего. Обратите внимание, что это не исчерпывающий список, а просто попытка сделать систему едва работоспособной.

chmod -R go-w /
chmod 440 /etc/sudoers
chmod 640 /etc/shadow /etc/gshadow
chmod 600 /etc/ssh/*_key /etc/ssh*key   # whichever matches
chmod 710 /etc/ssl/private /etc/cups/ssl
chmod 1777 /tmp /var/tmp /var/lock
chmod 4755 /bin/su /usr/bin/passwd /usr/bin/sudo /usr/bin/sudoedit
chmod 2755 /var/mail /var/spool/mail

Тогда вам нужно будет восстановить все разрешения везде. Для файлов в разделе /usrвы можете переустановить пакеты с помощью одной из следующих команд, в зависимости от вашего дистрибутива:

  • Если вы используете Debian, Ubuntu или другой дистрибутив на основе APT, вы можете выполнить apt-get --reinstall install
  • Если вы используете Arch Linux, вы можете выполнить его pacman -S $(pacman -Qq --dbpath /newarch/var/lib/pacman) --root /newarch --dbpath /newarch/var/lib/pacman, предполагая, что вы находитесь на Live CD и ваша установка Arch смонтирована на /newarch.

Для файлов под /etcи /var, это не сработает, их останется столько, сколько они есть: вам придется реплицировать разрешения для работающей установки. Для файлов в /srvи /home, вам придется все равно восстановить из резервных копий. Как видите, вы можете переустановить.

Жиль "ТАК - перестань быть злым"
источник
6
Согласитесь, если вы не являетесь экспертом, у вас практически нет шансов исправить эту ситуацию без полной переустановки или восстановления из резервных копий. Слишком опасно оставлять систему работающей как есть.
Arrowmaster
3
Если в системе есть пользователи, мне их жаль.
Юрген А. Эрхард
19

Поначалу вы можете этого не заметить, но многое может пойти и пойдет не так. Основная проблема заключается в том, что вся модель безопасности для всей системы нарушена. Это как тело без кожи, все органы в воздухе. Он обязательно заразится, потому что не предназначен для такой работы. Даже если кажется, что это работает в течение нескольких минут, вам нужно это почистить.

На самом деле лучшим способом было бы начать с нуля. Этот способ значительно снизит ваш риск и даст вам более чистый результат за меньшее время. Если у вас есть правильные резервные копии, это не должно быть слишком большим опытом.

Если вы попытаетесь его очистить, основным способом будет сказать менеджеру пакетов вашего дистрибутива переустановить ВСЕ в системе, включая перезапись файлов конфигурации. Затем воспользуйтесь любой проверяющей системой, которую она просматривает, и убедитесь, что ни одна из них не помечена как имеющая файлы с разрешениями, выходящими за рамки обычного. Затем работайте с такими вещами, как домашние каталоги пользователей, и массово восстанавливайте все до нормальных разрешений, затем работайте с несколькими вещами, которые должны иметь специальные разрешения (например, файлы ключей ssh). Наконец, сделайте полный поиск системы для всего, помеченного как 777, и просмотрите список (он должен быть небольшим, если вы тщательно выполнили другие шаги) и проработайте их один за другим, убедившись, что они должны быть такими, какие они есть.

Калеб
источник
Но, кроме безопасности, что может пойти не так с точки зрения приложений? Перестанут ли они работать? Или безопасность - самая большая проблема здесь?
Vinnycx
Безопасность - самая большая проблема, но многие программы, особенно за кулисами, такие как регистрация демонов, cron и т. Д., Потерпят неудачу по разным причинам, а не окажутся в опасной ситуации, которую они видят.
Калеб
cron перестанет работать только из-за 777?
Vinnycx
1
Существует несколько различных систем cron, но ни один уважающий себя cron не должен выполнять задания в cron root, когда файл crontab доступен для записи всем пользователям! Также почтовый демон, который обрабатывает уведомления cron, должен жаловаться по другим причинам.
Калеб
10

РЕШЕНИЕ: Я ПРОВЕРИЛ ЭТО В СЕНТОСЕ

Этот парень спас мою работу! (Вам нужно получить доступ как-то)

http://www.adminlinux.org/2009/07/how-to-restore-default-system.html

1) Чтобы сбросить uids и gids для файлов и каталогов:

for u in $(rpm -qa); do rpm --setugids $u; done

2) К разрешениям на файлы и каталоги

for p in $(rpm -qa); do rpm --setperms $p; done

затем вручную измените разрешения на эти файлы:

# ll /etc/ssh/
# chmod 600 /etc/ssh/ssh_host_rsa_key
# chmod 600 /etc/ssh/ssh_host_dsa_key
# service sshd restart
Сол скв
источник
5

Некоторые программы, обеспечивающие безопасность, не будут запускаться, если определенные файлы имеют слишком «свободные» разрешения. Как сказал @ceving, sshdэто наиболее типично для этого.

Главное, что может пойти не так, теперь любой пользователь может открывать, читать и писать любые файлы в вашей системе. Вот две причины, по которым это плохо: A) если злоумышленник получает контроль над вашей системой либо с помощью эксплойта, либо из-за неправильной конфигурации, он / она может изменить в вашей системе все, что угодно, и B) вы можете удалить все, что захотите, даже если вы не root, поэтому вы просто отменили большинство средств защиты от несанкционированного доступа от имени root.

Если вы не сделали резервную копию разрешений заранее, вы попали в небольшую ситуацию. Возможно, вам удастся создать сценарий, который «извлекает» список разрешений из только что установленной системы, а затем «применяет» их ко всему в вашей системе. У меня нет такого сценария под рукой, хотя.

LawrenceC
источник
Но, кроме безопасности, что может пойти не так с точки зрения приложений? Перестанут ли они работать? Или безопасность - самая большая проблема здесь?
Vinnycx
Просто пара приложений, которые отказываются запускаться, если права слишком слабые. Безопасность - самая большая проблема. Но это также стабильность системы. Если вы сделаете это rm -rf /как обычный пользователь, теперь вы остановите свою систему.
LawrenceC
Какие приложения могут перестать работать?
Vinnycx
Помимо SSH? Что еще может потерпеть неудачу? Мне нужно сейчас, если я могу оставить систему на некоторое время.
Vinnycx
5
@Vinnycx: Нет, ты не можешь. Это сломано. Вы должны сделать это приоритетом, чтобы исправить это. В противном случае ожидайте, что ваши сервисы по ошибке вас подведут, и хакеры съедят ваши данные. Оставить / * @ 777 не вариант.
Калеб