Redhat ユーザー:

Redhat ユーザー:

数秒前にこれを実行しました。何をし始めたのかに気づいたら、すぐに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 で再インストールします。

関連情報