69 回の賛成票の後、大幅に更新されました。元の回答については、回答履歴を参照してください。議論をしてくれた @JimmyJames に感謝します。
まず、脅威モデルについて話しましょう。潜在的な攻撃者が何をするのを阻止しようとしていますか?
脅威モデル:個人情報の盗難 / シングルユーザー システムでのランサムウェア
一般に、エンド ユーザー システムの場合、デファクト 脅威モデルはなりすまし/ランサムウェアです。攻撃者があなたのドキュメントにアクセスしたり、シェル コマンドを実行できる場合、ゲーム オーバーです。その観点からすると、root アクセスは攻撃者に何の利益ももたらしません。彼らはそれなしで欲しいものを手に入れることができます.
個人情報の盗難やマルウェアだけが心配である場合、ユーザーが sudo を持っているかどうかはあまり重要ではないようです 権限、またはブラウザがルートとして実行されているかどうか。
(ログイン スクリプトや cron ジョブのスケジュール設定には root が必要ないため、マルウェアやボットネットへの接続は root アクセスなしで発生する可能性があることも指摘しておく必要があります)。
XKCD の Randall Munroe 氏は、この見解に同意しているようです:
最後に、この免責事項を追加します。はい、これが「セキュリティが高いほど常に優れている」という一般世論に反することを認識しています。それは真実ではありません。過度に複雑なパスワード ポリシーが最終的にユーザーにパスワードを書き留めることを強いるなど、セキュリティを強化すると悪化する場合があります。常にリスクを検討し、実際にどの程度のセキュリティが適切かを判断する必要があります。この場合、root アクセスをロックダウンしても害はありませんが、あなたの生活をより複雑にしており、それから何かを得ているかどうかは明らかではありません.
脅威モデル:root アクセスまたはマルチユーザー システム
攻撃者がルートのみがアクセスできるものを望んでいる脅威モデルがある場合、またはマシンに複数のユーザー アカウントがある場合、答えは実際にはどの *nix について話しているかによって異なります。これは急速にパーソナル コンピュータのケースからサーバーのケースへと移行しつつありますが、とにかく説明します。 Linux の場合、Xorg ウィンドウ システムのバグ (*ahem 機能*) のため、日常のアカウントにはおそらく sudo がないはずです。 力。 X を使用しないオペレーティング システムの場合は、おそらく問題ありません。
Linux (X.org ウィンドウ システムを実行)
これは、単純なユーザーランド (非ルート) シェルコマンドを使用して、GUI Linux マシンですべてのキーストロークをログに記録する方法を示す素晴らしい記事です。要約:
$ xinput list 接続されているすべてのヒューマン入力デバイスを表示します
$ xinput test <id> 選択したデバイスですべてのキーストロークのエコーを開始します。
テストしたところ、sudo に入力したパスワードのログが取得されました 別の端末ウィンドウで。コンピューターをロックすると、再度ログインすると、ロック画面に入力したパスワードのログが表示されます。どうやらこれは X のバグではなく、機能です。よし、ベッドの下に隠れるぞ。
ええ、これは、GUI でログインするユーザーは sudo を持つべきではないという考えをサポートしています パスワードをログに記録してから root になるのは簡単だからです。 sudo専用のアカウントが必要だと思います ing して TTY 端末に切り替えます (ctrl+alt+# ) sudo を使いたい場合 .これを心配する価値があるかどうかは、あなた次第です。個人的には、気になるデータはすべて自分のユーザー アカウントに既に存在していますが、セキュリティ オタクなので、おそらくラップトップの設定を変更するでしょう。
私のテストでは、ユーザー間でキーログを記録できなかったことに注意してください。 GUI、または startx で「アカウントの切り替え」を行う 新しい tty 端末では、X の分離されたインスタンスを起動するようです。
この観察について @MichaelKjörling に感謝します:
<ブロック引用>これは、Wayland [X を置き換えるように設計されたウィンドウ システム] が実際に修正しようとしているものの 1 つです (セキュリティに関する箇条書きを参照)。 X11 は、脅威モデルが現在のものとは大きく異なっていた時代に生まれたことを思い出してください。
システム管理者向け :これにより、ssh 経由でのみ Linux ボックスと対話する習慣が強化され、決して GUI は使用されません。
Mac OSX
私は OSX の専門家ではありませんが、Xorg サーバーを使用していないことはわかっているので、Apple の GUI がこれを適切に処理していると思いますが、私よりも専門家に意見を求めたいと思います.
窓
私も Windows の専門家ではありませんが、Windows 7 で導入されたユーザー アカウント制御 (UAC) 機能は、入力バスが通常のデスクトップから分離された安全なデスクトップで管理者プロンプトをレンダリングすることで、この問題に対処したと思います。
ほとんどの場合、sudo でパスワードを要求するだけで十分な保護になります。
su の主な違い 別のアカウントと sudo への ing 特権を得るためには、sudo を使用して、ログインに使用したのと同じパスワードを入力する必要があります。脅威モデルが、攻撃者がアカウントのパスワードを知っていると想定している場合、root アカウントの別のパスワードよりも、すでにかなり深刻な問題に直面しています。からあなたを守ります。
次の理由から、私の UNIX システムで 2 つのアカウントを持つことが不可欠であることがわかりました:
.bashrc やその他のログイン / ターミナル設定ファイルを台無しにすると、ログインすらできない状況に陥る可能性があります。ログインできなければ何もできないので、これは想像できる最悪の状況です。
いくつかのコンピューターでこれを修正できた唯一の方法は、別のログインを使用してログインし、sudo を使用して、プライマリ アカウントのスタートアップ ファイルを修正することでした。次に、アカウント「2」からログアウトし、通常のアカウントに戻ります。
時々私はそうする USBオプションからの起動を使用できますが、正直に言うと、別のアカウントにログインし、sudoを使用して.bashrcを修正し、ログアウトして他のアカウントに戻ることができます.2回目のログインで数秒ですべて実行できます.私にとっては、USBブートから修正オプションよりもはるかに怖く/なじみがありません。もちろんYMMV（Your Mileage May Very）