ルート権限を取得する最も安全な方法は次のとおりです：sudo、su、またはlogin？

特権のないユーザーが危険にさらされた場合でも、rootアカウントを安全に保持したいと思います。

Ubuntuでは、デフォルトで「セキュリティ上の理由」のためにのみsudoを使用できます。ただし、テキストモードコンソールでログインを使用するよりも安全かどうかはわかりません。攻撃者が通常のユーザーとしてコードを実行できる場合、問題が発生する可能性があります。たとえば、エイリアスの追加、私のPATHへの追加、LD_PRELOADとX11キーロガーの設定などです。私が見ることができる唯一の利点はタイムアウトですので、ログアウトすることを決して忘れません。

私はsuについて同じ疑問を抱いていますが、時間制限さえありません。一部の操作（特にIOリダイレクション）はsuではより便利ですが、セキュリティ面ではこれはさらに悪いようです。

テキストモードコンソールへのログインが最も安全であるようです。攻撃者がPATHまたはLD_PRELOADを制御できる場合、initによって開始されるため、彼はすでにrootです。keypressイベントは、Xで実行されているプログラムによってインターセプトすることはできません。Xで実行されているプログラムが[ctrl] + [alt] + [f1]をインターセプトできるかわかりません（コンソールのようなフルスクリーンウィンドウを開く）またはWindowsの[ctrl] + [alt] + [del]のように安全です。それに加えて、私が見る唯一の問題はタイムアウトがないことです。

だから私は何かが欠けていますか？Ubuntuの連中がsudoのみを許可することにしたのはなぜですか？いずれかの方法のセキュリティを向上させるにはどうすればよいですか？

SSHはどうですか？従来、rootはSSH経由でログインできません。しかし、上記のロジックを使用すると、これは最も安全なことではありません。

• SSHを介してルートを許可する
• テキストモードに切り替える
• ルートとしてログイン
• 他のマシンへのssh
• ルートとしてログインしますか？

セキュリティは常にトレードオフを行うことです。ただ、安全であることわざのサーバーのように、アンプラグド、海の底に、rootだろうほとんどすべてでそれにアクセスする方法はありませんでした場合は、安全な。

説明したようなLD_PRELOADおよびPATH攻撃は、既にアカウントにアクセスしている攻撃者、または少なくともドットファイルにアクセスしている攻撃者がいることを前提としています。sudoはまったくそれを十分に保護しません。パスワードを持っている場合は、後であなたをだまして試す必要はありません... sudo 今すぐ使用できます。

Sudoが元々どのように設計されたのかを考慮することが重要です。特定のコマンド（プリンターを管理するコマンドなど）を「完全にルートを譲らずに「サブ管理者」（ラボの大学院生など）に委任します。sudoを使用してすべてを行うことは、私が今見ている最も一般的な使用法ですが、必ずしもプログラムが解決することを意図した問題ではありません（そのため、とんでもなく複雑な構成ファイル構文）。

ただし、sudo-for-unrestricted-root は別のセキュリティ問題に対処します。rootパスワードの管理性です。多くの組織では、これらはキャンディのように渡され、ホワイトボードに書き込まれ、同じものを永遠に残す傾向があります。アクセスを取り消すか変更することは大きな生産数になるため、これは大きな脆弱性を残します。どのマシンにどのパスワードが設定されているかを追跡することも、誰がどのパスワードを知っているかを追跡することはもちろんのことです。

ほとんどの「サイバー犯罪」は内部から発生することを忘れないでください。説明されているrootパスワードの状況では、誰が何をしたかを追跡するのは困難です。リモートロギングを使用するsudoは、かなりうまく処理できます。

自宅のシステムでは、2つのパスワードを覚えておく必要がないという利便性の方が重要だと思います。多くの人が単純にそれらを同じに設定している、またはさらに悪いことに、最初にそれらを同じに設定してから、それらを同期せずに、ルートパスワードを腐敗させた可能性があります。

SSHでパスワードを使用するのは危険です。これは、トロイの木馬でパスワードを盗聴するsshデーモンが、実際に見たシステムの侵害の90％のような場所に配置されているためです。SSHキーを使用する方がはるかに優れており、これはリモートルートアクセスにも有効なシステムになる可能性があります。

しかし、ここでの問題はパスワード管理からキー管理に移行したことであり、sshキーは実際にはあまり管理できません。コピーを制限する方法はありません。誰かがコピーを作成した場合、パスフレーズを総当たり攻撃しようとするすべての試みがあります。キーはリムーバブルデバイスに保存し、必要な場合にのみマウントする必要があるというポリシーを作成できますが、それを強制する方法はありません。これで、リムーバブルデバイスが紛失または盗難される可能性が導入されました。

最高のセキュリティは、ワンタイムキーまたはタイム/カウンターベースの暗号化トークンによって実現されます。これらはソフトウェアで実行できますが、改ざん防止ハードウェアはさらに優れています。オープンソースの世界には、WiKiD、YubiKey、またはLinOTPがあり、もちろん独自のヘビー級RSA SecurIDもあります。中規模から大規模の組織、またはセキュリティを重視する小規模な組織の場合は、管理アクセスのためのこれらのアプローチのいずれかを検討することを強くお勧めします。

ただし、賢明なセキュリティ対策を講じている限り、管理の面倒をあまり抱えていない家庭では、おそらくやり過ぎです。

これは非常に複雑な質問です。mattdm はすでに多くのポイントをカバーしています。

suとsudoの間で、単一のユーザーを考えると、suはパスワードを見つけた攻撃者がすぐにroot権限を取得できないという点で、もう少し安全です。しかし、必要なのは、攻撃者がローカルのルートホールを見つける（比較的一般的ではない）か、トロイの木馬をインストールしてsuの実行を待つことだけです。

sudoには、複数のユーザーがいるコンソールログインよりも利点があります。たとえば、システムがリモートの改ざん防止ログで構成されている場合、sudoを最後に実行した人（またはアカウントが侵害された人）をいつでも見つけることができますが、コンソールでrootパスワードを入力した人はわかりません。

Ubuntuの決定は、単純さ（覚えておくべき1つのパスワードのみ）と共有マシン（ビジネスまたは家族）での資格情報の配布の容易さの一部にあると思われます。

Linuxには、認証用の安全なアテンションキーまたはその他の安全なユーザーインターフェイスがありません。私の知る限り、OpenBSDにもありません。ルートアクセスが心配な場合は、実行中のシステムからルートアクセスを完全に無効にすることができます。ルートになりたい場合は、ブートローダープロンプトで何かを入力する必要があります。これは明らかにすべてのユースケースに適しているわけではありません。（* BSDのsecurelevelは次のように動作します。securelevelが高い場合、securelevelを下げる、マウントされたrawデバイスに直接アクセスするなど、再起動せずにはできないことがあります。）

ルートになる方法を制限することは、必ずしもセキュリティの向上とは限りません。第三のメンバーを覚えておいてくださいセキュリティトライアド：機密性、完全性、可用性を。システムからロックアウトすると、インシデントに対応できなくなる可能性があります。

セキュリティで保護されたOpenWall GNU / * / Linuxディストリビューションの設計者は、su（ルートになるための）およびについても批判的な意見を表明していsudoます。このスレッドを読むことに興味があるかもしれません：

...残念ながら、suとsudoはどちらも微妙ですが、根本的に欠陥があります。

suSolar Designer の欠点やその他の問題を議論することとは別に、使用する特定の理由を1つ挙げていますsu。

はい、以前はrootとしてログインするのではなく、「su root」という一般的なシステム管理者の知恵でした。尋ねられたときに、この選好の正当な理由を実際に思いつくことができた少数の人々は、このアプローチで達成されたより良い説明責任について言及するでしょう。はい、これは本当にこのアプローチを支持する正当な理由です。しかし、それも唯一のものです。...（続きを読む）

ディストリビューションでは、「デフォルトのインストールでSUIDルートプログラムを完全に削除しました」（つまり、su;を含み、この機能を使用しません）：

サーバーについては、ユーザーが再検討する必要があり、ほとんどの場合、ユーザーによるsuおよびsudoの呼び出しを禁止する必要があると思います。非ルートおよび直接ルート（2つの個別のセッション）としてログインする場合と比較して、古い「非ルートとしてログインし、次にルートまたはルートにsuまたはsudo」sysadminから追加のセキュリティはありません。それどころか、セキュリティの観点から、後者のアプローチが唯一の正しいアプローチです。

http://www.openwall.com/lists/owl-users/2004/10/20/6

（複数のシステム管理者の説明責任のために、システムはOwlのように複数のルート特権アカウントを持つことをサポートする必要があります。）

（Xを備えたデスクトップの場合、これはより複雑になります。）

また、絶対に対処する必要があります...

ところで、彼らは複数のルートアカウントでセットアップを可能にするために置き換えsuloginられmsuloginました：msuloginシングルユーザーモードに入るときにもユーザー名を入力することができます（そして「説明責任」を保持します）（この情報はロシア語のこの議論から来ています） 。

を使用するとsudo常に環境変数が保存されると仮定しているように見えますが、常にそうであるとは限りません。sudoマンページからの抜粋を次に示します。

環境変数を扱うには、2つの異なる方法があります。デフォルトでは、env_reset sudoersオプションが有効になっています。これにより、env_checkおよびenv_keep sudoersオプションで許可された呼び出しプロセスからの変数に加えて、TERM、PATH、HOME、SHELL、LOGNAME、USERおよびUSERNAMEを含む最小限の環境でコマンドが実行されます。事実上、環境変数のホワイトリストがあります。

ただし、sudoersでenv_resetオプションが無効になっている場合、env_checkおよびenv_deleteオプションで明示的に拒否されていない変数は、呼び出しプロセスから継承されます。この場合、env_checkとenv_deleteはブラックリストのように動作します。潜在的に危険なすべての環境変数をブラックリストに載せることはできないため、デフォルトのenv_reset動作の使用が推奨されます。

すべての場合において、（）で始まる値を持つ環境変数は、bash関数として解釈される可能性があるため削除されます。sudoが許可または拒否する環境変数のリストは、rootとして実行した場合のsudo -Vの出力に含まれています。

env_resetが有効になっている場合（デフォルト）、攻撃者はユーザーPATHまたは他の環境変数を上書きできません（保存する必要がある変数のホワイトリストに明示的に追加しない限り）。

最も安全なアプローチは、物理デバイスを使用して（少なくとも）2048の長いキーを使用して（パスワードログインを無効にして）sshログインすることです。

ちょっとしたトピックを追加したいだけです。（トピックについては、「/ bin / su-」をチェックしてください）

上記の「セキュリティ」は、セキュリティで保護する実際のデータにもリンクする必要があると思います。

保護する場合は、my_data、my_company_data、my_company_networkのように異なる必要があります。

通常、セキュリティについて話す場合、「データセキュリティ」とバックアップについても話します。フォールトトレラントシステムなどを追加することもできます。

これを考えると、セキュリティは全体として、ユーザビリティ、「データセキュリティ」、および安全なシステムを実装するために必要な努力の間の均衡であると思います。

Ubuntuのターゲットは最終ユーザーであり、現在もほとんどが最終ユーザーです。Sudoがデフォルトです。

FedoraはRedHatの無料バージョンであり、これはよりサーバー指向です。Sudoは以前は無効でした。

他のディストリビューションについては、直接的な情報はありません。

現在、主にfedoraを使用しています。古いスタイルのユーザーとして、「su」と入力したことはありません。しかし、タイピストでなくても、非常に短い時間で「/ bin / su-」と入力できます。PATH変数は問題になりません（パスを入力します）。また、原則として「-」（マイナス）はユーザー環境変数を削除し、ルート環境変数のみをロードする必要があります。つまり、余分なトラブルを回避します。おそらくLS_PRELOADも。

残りについては、@ mattdmはかなり正確だったと思います。

しかし、正しいボックスに入れましょう。スクリプティングスマートキットがデータにアクセスすると仮定します。彼は一体何をしていると思いますか？-写真を公開しますか？僕の？-ガールフレンドの名前を見つけて、ポルノサイトにアクセスしたことを伝えようとしていますか？

シングルユーザーの写真では、2つの最悪の状況は次のとおりです。または同様のターゲット。

最初のケースでは、ネットワークセキュリティよりもバックアップに労力をかける方が上で述べました。はい、あなたは救われています。ハードウェアのクラッシュはそれほど違いはありません。

2番目のケースはより微妙です。しかし、これらの活動に関するシグナルがあります。いずれにせよ、あなたは可能なことをすることができますが、私はテロ攻撃から保護されるように私のPCを設定しません！

他のシナリオはスキップします。

乾杯F

懸念されるのは、侵害されたユーザーアカウントを使用してsudoまたはsuに使用されるパスワードを盗聴できることである場合は、sudoおよびにワンタイムパスコードを使用しsuます。

リモートユーザーに対してキーの使用を強制することはできますが、コンプライアンスの目的でマスターをパスしない場合があります。2要素認証を必要とするSSHゲートウェイボックスをセットアップし、そこからキーの使用を許可する方がより効果的な場合があります。このようなセットアップに関するドキュメントは次のとおりです。WiKID two-factor authenticationを使用してSSH展開を保護します。

また、privacyIDEAを見ることができます。これは、マシンへのログイン（またはsu / sudoの実行）にOTPを使用する可能性を提供するだけでなく、OTPをオフラインで実行することもできます。

さらに、SSHキーを管理できます。つまり、多数のマシンと複数のルートユーザーがいる場合、すべてのSSHキーは一元的に保存されます。したがって、SSHキーを信頼できない場合は、SSHキーを「失効」/削除するのは簡単です。

もちろん、システムを保護するための組織的なタスクとワークフローがあります。