root権限を取得する最も安全な方法は、sudo、su、loginのどれですか？
権限のないユーザーが侵害された場合でも、rootアカウントを安全に保持したいと考えています。
Ubuntuでは、デフォルトで「セキュリティ上の理由」でのみSudoを使用できます。ただし、テキストモードのコンソールでログインを使用するよりも安全かどうかはわかりません。攻撃者が私の通常のユーザーとしてコードを実行できる場合、問題が発生する可能性が多すぎます。たとえば、エイリアスを追加したり、PATHに要素を追加したり、LD_PRELOADおよびX11キーロガーを設定したりします。私が見ることができる唯一の利点はタイムアウトですので、ログアウトすることを決して忘れません。
私はsuについて同じ疑問を持っていますが、時間制限さえありません。一部の操作（特にIOリダイレクション）はsuの方が便利ですが、セキュリティ面ではこれはさらに悪いようです。
テキストモードのコンソールでのログインが最も安全なようです。攻撃者がPATHまたはLD_PRELOADを制御できる場合、それはinitによって開始されるため、彼はすでにrootです。 Xで実行されているプログラムがキープレスイベントを傍受できないWindowsの[ctrl] + [alt] + [del]のように安全です。その上、私が目にする唯一の問題は、タイムアウトがないことです。
だから私は何かが足りないのですか？ Ubuntuの人たちはなぜsudoのみを許可することにしたのですか？メソッドのセキュリティを向上させるにはどうすればよいですか？
SSHはどうですか？従来、rootはSSH経由でログインできません。しかし、上記のロジックを使用するのは、これが最も安全なことではありません。
- sSH経由でrootを許可する
- テキストモードに切り替え
- rootとしてログイン
- 他のマシンにssh
- rootとしてログインしますか？
セキュリティは常にトレードオフを行うことです。安全で接続されていない、海の底にあることわざのサーバーのように、rootはmostが安全であればアクセスする方法はまったくありませんでした。
あなたが説明するようなLD_PRELOADとPATH攻撃は、あなたのアカウント、または少なくともあなたのドットファイルへのアクセス権を持つ攻撃者がいることを想定しています。 Sudoはそれに対しては十分に保護していません。もし彼らがあなたのパスワードを持っているなら、結局のところ、後であなたをだまして試す必要はありません...彼らはSudonow。
Sudoの本来の目的を検討することが重要です。specificコマンド（プリンターを管理するコマンドなど）の「サブ管理者」（おそらく大学生）への委任研究室で）完全に根を与えることなく。 Sudoを使用してeverythingを実行するのが最も一般的な使用方法ですが、必ずしもプログラムが解決することを意図した問題ではありません（そのため、途方もなく複雑な構成です）ファイル構文）。
ただし、Sudo-for-unrestricted-rootdoesは、別のセキュリティ問題、つまりrootパスワードの管理性に対処します。多くの組織では、これらはキャンディーのように流布され、ホワイトボードに書かれ、永久に同じままにされる傾向があります。アクセスを取り消したり変更したりすることは大きな生産数になるため、これには大きな脆弱性が残ります。どのマシンにどのパスワードが設定されているかを追跡することさえ困難です。誰が誰が知っているかを追跡することは言うまでもありません。
ほとんどの「サイバー犯罪」は内部からのものであることを忘れないでください。ルートパスワードの状況について説明したので、だれが何をしたかを追跡するのは困難です。リモートロギングを備えたSudoがかなりうまく対処しています。
あなたのホームシステムでは、2つのパスワードを覚える必要がないという利便性の問題のほうが本当に多いと思います。多くの人が単に同じように設定するか、またはさらに悪いことに、最初は同じに設定してから同期を外し、rootパスワードをそのままにしていた可能性があります。
SSHでパスワードを使用するのは危険です。なぜなら、パスワードを盗聴するトロイの木馬sshデーモンが、実際のシステムの侵害の90％などに配置されるためです。私は見た。 SSHキーを使用する方がはるかに優れており、これはリモートrootアクセスの実行可能なシステムにもなります。
しかし、パスワード管理からキー管理に移行したため、sshキーはあまり管理しにくいという問題があります。コピーを制限する方法はありません。誰かがコピーを作成した場合、パスフレーズをブルートフォースにしようとするあらゆる試みが行われます。キーはリムーバブルデバイスに保存し、必要な場合にのみマウントする必要があるというポリシーを設定できますが、それを強制する方法はありません。これで、リムーバブルデバイスの紛失または盗難の可能性が導入されました。
最高のセキュリティは、ワンタイムキーまたは時間/カウンタベースの暗号化トークンによってもたらされます。これらはソフトウェアで実行できますが、改ざん防止ハードウェアの方が優れています。オープンソースの世界では、 WiKiD 、 YubiKey 、または LinOTP 、もちろん、独自仕様のヘビー級 RSA SecurID もあります。中規模から大規模の組織、またはセキュリティを意識した小規模な組織の場合は、管理アクセスのためにこれらのアプローチの1つを検討することを強くお勧めします。
ただし、賢明なセキュリティ慣行に従っている限り、管理面倒を実際に抱えていない家庭にとってはおそらくやり過ぎです。
これは非常に複雑な質問です。 mattdmすでに多くのポイントをカバーしています 。
SuとSudoの間で、単一のユーザーを検討する場合、suは、パスワードを見つけた攻撃者がすぐにroot権限を取得できないという点で、もう少し安全です。しかし、攻撃者がローカルルートホール（比較的珍しい）を見つけるか、トロイの木馬をインストールして、suを実行するのを待つだけで済みます。
複数のユーザーがいる場合、sudoはコンソールログインよりも優れています。たとえば、システムがリモートの改ざん防止ログで構成されている場合、Sudoを最後に実行したユーザー（またはアカウントが侵害されたユーザー）はいつでも確認できますが、コンソールでrootパスワードを入力したユーザーはわかりません。
Ubuntuの決定は、部分的には単純さ（パスワードは1つだけ覚えておく）と、共有マシン（ビジネスまたは家族）でのセキュリティと資格情報の配布の容易さの両方に関心があると思います。
Linuxには、認証のための安全なアテンションキーやその他の安全なユーザーインターフェイスがありません。私の知る限り、OpenBSDにもありません。ルートアクセスについて懸念がある場合は、実行中のシステムからのルートアクセスを完全に無効にすることができます。ルートになりたい場合は、ブートローダープロンプトで何かを入力する必要があります。これは明らかにすべてのユースケースに適しているわけではありません。 （* BSDの securelevel は次のように機能します。高いセキュリティレベルでは、securelevelを低くしたり、マウントされたrawデバイスに直接アクセスしたりするなど、再起動なしでは実行できないことがあります。）
Rootになる方法を制限することは、常にセキュリティを向上させるとは限りません。 セキュリティトライアド の3番目のメンバーを思い出してください： confidentiality 、 integrity 、 availability 。システムからロックアウトすると、インシデントに対応できなくなる可能性があります。
安全なOpenWall GNU/*/Linuxディストリビューションの設計者は、su（rootになるため）およびSudoについても批判的な意見を表明しています。あなたはこのスレッドを読むことに興味があるかもしれません：
...残念ながらsuとSudoはどちらも微妙ですが根本的に欠陥があります。
suの欠点やその他のことを説明する以外に、Solar Designerはsuを使用する特定の1つの理由も対象としています。
はい、これは、rootとしてログインするのではなく、「su root」するための一般的なシステム管理者の知恵でした。尋ねられたときに実際にこの好みの正当な理由を思い付くことができた少数の人々は、このアプローチで達成されたより良い説明責任について言及するでしょう。はい、これは本当にこのアプローチを支持する正当な理由です。しかし、それだけです。 ...（続きを読む）
彼らのディストリビューションでは、彼らは "デフォルトのインストールでSUIDルートプログラムを完全に取り除いた" （つまり、suを含み、このための機能を使用していません）：
サーバーについては、ユーザーによるsuとSudoの呼び出しを再考し、ほとんどの場合は許可しないようにする必要があると思います。以前の「非rootとしてログインしてからsuまたはSudoからrootに」sysadminの「知恵」によるセキュリティの追加はありません。非rootとしてログインし、直接root（2つの別々のセッション）としてログインするのとは異なります。それどころか、セキュリティの観点から、後者のアプローチが唯一の正しいアプローチです。
http://www.openwall.com/lists/owl-users/2004/10/20/6
（複数のシステム管理者の説明責任のために、システムはOwlのように、複数のroot特権アカウントを持つことをサポートする必要があります。）
（Xを搭載したデスクトップの場合、これは扱いにくくなります。）
また、絶対に対処する必要があります...
ところで、彼らはsuloginを msulogin に置き換えて、複数のrootアカウントでセットアップできるようにしました：msuloginは、ユーザー名も入力できるようにしますシングルユーザーモードに入るとき（そして「説明責任」を維持するとき）（この情報は ロシア語でのこの議論 から得られます）。
Sudoを使用すると常に環境変数が保持されると想定しているようですが、常にそうであるとは限りません。これは、Sudoマンページからの抜粋です。
環境変数を処理する方法は2つあります。デフォルトでは、env_reset sudoersオプションは有効になっています。これにより、env_checkおよびenv_keep sudoersオプションで許可された呼び出しプロセスからの変数に加えて、TERM、PATH、HOME、Shell、LOGNAME、USER、USERNAMEを含む最小限の環境でコマンドが実行されます。実際には、環境変数のホワイトリストがあります。
ただし、sudoerでenv_resetオプションが無効になっている場合、env_checkおよびenv_deleteオプションによって明示的に拒否されていない変数は、呼び出しプロセスから継承されます。この場合、env_checkとenv_deleteはブラックリストのように動作します。潜在的に危険な環境変数をすべてブラックリストに登録することはできないため、デフォルトのenv_reset動作の使用が推奨されます。
すべての場合において、（）で始まる値を持つ環境変数は、bash関数として解釈される可能性があるため削除されます。 Sudoが許可または拒否する環境変数のリストは、ルートとして実行した場合の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 2要素認証でSSH展開を保護する 。
privacyIDEA を確認することもできます。これは、マシンへのログイン（またはsu/Sudoの実行）にOTPを使用する可能性を提供するだけでなく、OTPをオフラインで実行することもできます。
さらに、SSHキーを管理することもできます。つまり多くのマシンと複数のrootユーザーがいる場合、すべてのSSHキーは中央に保存されます。したがって、SSHキーが信頼できない場合、SSHキーを「取り消す」/削除するのは簡単です。
もちろん、システムを保護するための組織的なタスクとワークフローがあります。