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

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

Моя рекомендация состоит в том, чтобы переустановить. Сохраните резервное копирование существующей системы и восстановите список пакета и содержание файлов в /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
• При использовании Дуги Linux можно выполниться pacman -S $(pacman -Qq --dbpath /newarch/var/lib/pacman) --root /newarch --dbpath /newarch/var/lib/pacman, предположение, что Вы находитесь в Живом CD и Вашей установке Arch, смонтировано в /newarch.

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

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

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

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

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

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

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

Решение: я проверил это в CentOS

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

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

1) Чтобы сбросить UID и GID на файлах и каталогах:

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