web-dev-qa-db-ja.com

誤ってchmod / 777を設定してください。問題はありますか？

実行しようとしていたchmod -R 777 ./と入力しましたが、結局chmod -R 777 /およびセット777私のマシン全体。何がうまくいかないのですか？どうすれば修正できますか？

permissionschmod
33
Vinnycx

問題？はい、たくさんあります。修正できますか？承知しました。再インストールよりも高速ですか？おそらく違います。

再インストールすることをお勧めします。既存のシステムのバックアップを保存し、_/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を使用している場合は、Live CDでArchインストールが_/newarch_にマウントされていると仮定して、pacman -S $(pacman -Qq --dbpath /newarch/var/lib/pacman) --root /newarch --dbpath /newarch/var/lib/pacmanを実行できます。

_/etc_と_/var_の下のファイルの場合、それらはそのままになり、機能しません。機能しているインストールでアクセス許可を複製する必要があります。 _/srv_および_/home_の下のファイルの場合は、とにかくバックアップから復元する必要があります。ご覧のとおり、再インストールすることもできます。

48
Gilles 'SO- stop being evil'

最初は気付かないかもしれませんが、多くのことがうまくいかず、うまくいきません。主な問題は、システム全体のセキュリティモデル全体が壊れていることです。それは、皮膚のない身体、臓器がすべて空中にあるようなものです。それはそのように機能することを意図されていないので、それは感染するにちがいない。数分間機能するように見えても、これをクリーンアップする必要があります。

実際には最初から始めるのが最善の方法です。この方法により、リスクが大幅に軽減され、時間を短縮してよりクリーンな結果を得ることができます。適切なバックアップがあれば、これはあまり経験を積むべきではありません。 。

クリーンアップを試みる場合、主な方法は、ディストリビューションのパッケージマネージャーに、構成ファイルの上書きを含め、すべてをシステムに再インストールするように指示することです。次に、それらを調べなければならない検証システムを使用し、通常とは異なるアクセス権を持つファイルがあるとフラグが付けられていないことを確認します。次に、ユーザーのホームディレクトリなどを操作し、すべてをまともな権限にまとめてリセットしてから、特別な権限が必要ないくつかの操作（sshキーファイルなど）を実行します。最後に、777とマークされたすべてのシステムを完全に検索し、リストを確認し（他の手順を完全に実行している場合は小さいはずです）、1つずつ調べて、それらが正しい方法であることを確認します。

19
Caleb

ソリューション：私はこれを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
12
saul scv

特定のファイルの権限が「緩すぎる」と、セキュリティを意識したプログラムが起動しなくなります。 @cevingが言ったように、sshdはこれの最も典型的なものです。

うまくいかない可能性のある主なものは、現在、システム上で任意のユーザーが開いて読み取り、書き込みができる任意のファイルです。これが悪い2つの理由は次のとおりです。A）悪意のあるユーザーがエクスプロイトまたは設定ミスによってシステムを制御した場合、彼/彼女はシステム上のすべてを今すぐ変更できます。B）必要なものをすべて削除できますあなたはrootではないので、rootとして実行しないという保護のほとんどを無効にしています。

事前に権限をバックアップしなかった場合は、少し状況が異なります。新しくインストールされたシステムから権限のリストを「フェッチ」し、それをシステム上のすべてに「適用」するスクリプトを作成できる場合があります。でも、そのようなスクリプトは手元にありません。

5
LawrenceC