数秒前にこれを実行しました。何をし始めたのかに気づいたら、すぐにCtrl実行できました。C
これまでのところ、処理が開始されたディレクトリは のみです/bin
。
他のことをするのは怖いです。今のところ、su
通常のユーザーとして使用できないことに気づきました。
幸いなことに、別のルート ターミナルがまだ開いています。どうすればよいでしょうか?
答え1
/bin/ 内のほとんどすべてのファイルは root:root が所有しているはずなので、以下を実行するとそれらのファイルの所有権を修正できます。
chown root:root -R /bin/
また、/bin/su で setuid ビットが適切に設定されていることを確認する必要があります。これは、次のコマンドで修正できます。
chmod 4755 /bin/su
答え2
Redhat ユーザー:
chown 0:0 /bin/rpm && rpm -qa | xargs rpm --setugids
Debian/Ubuntu ユーザー:
chown 0:0 /bin/* /usr/bin/*
chown daemon:daemon /usr/bin/at
chown 0:utmp /usr/bin/screen
chmod 02755 /usr/bin/screen
chmod u+s /bin/fusermount /bin/mount /bin/su /bin/mount
chmod u+s /usr/bin/sudo /usr/bin/passwd
screen
画面の実行中に、これを少なくとも 2 回実行します。
dpkg --get-selections | awk '{ if ($2 == "install") print $1}' \
| xargs apt-get install --reinstall --
支払うとても出力に細心の注意を払ってください。何かの権限が間違っているというエラーが表示された場合は、別の画面ウィンドウで修正する必要があります。
画面でのクラッシュコース:
Control+A - command key
Control+A a - emit a control+A
Control+A n - next "screen"
Control+A c - create "screen"
Solaris ユーザー:
お前はクソだ。
pkgchk -R / -f -a
すべての権限をリセットしますが、setuid 状態は依然として維持されません。バックアップまたは別の Solaris マシンを使用して、setuid/setgid スクリプトとファイルを探し、手動で修正してください。
バックアップに関する重要なこと
それは、奪うのではなく、取り戻すことができるということです。
他の人がバックアップを取るようにアドバイスしていますが、テストをすべきだと付け加えておきます。Unix系のシステムを使用している場合は、理由は全くない定期的にファイルを別のマシンにダンプして、すべてが機能していることを確認できないということです。
答え3
影響を受けるバイナリの set-uid フラグも削除されている可能性があることに注意してください。これは chown のセキュリティ機能です。他のシステムでどのバイナリに set-uid または set-gid フラグがあるかを確認し、自分のバイナリにも必ず設定してください。
答え4
これが Debian システムであれば、すべてを aptitude で再インストールします。