Linuxでrootから秘密を守る
Linuxシステムを強化して、正当な手段または非正当な手段で完全なルートアクセスを取得した場合でも、一部のシークレットにアクセスできないようにする方法を探しています。しかし、最初に少し背景。
さまざまなLinuxセキュリティモデル（SELinux、TOMOYOなど）の多くは、ポリシーによってプロセスが実行できることを制限し、プロセスが完全なrootアクセスを必要としないことを確認することに集中しています。システムの他の部分が侵害されないように、エクスプロイトを封じ込めておくことを目的としています。ただし、これらは、完全なrootがすでに取得されている場合、または有効なrootユーザーからの秘密を保持している場合に直接対処するものではないようです。通常、これらは実行時に実際のルートによってオフにできるだけのようです。
別のアプローチは、完全に無制限のrootを取得する方法を制限することです。たとえば、リモートで接続されたrootユーザーにすべてのアクセスを許可するのではなく、物理コンソールからのログインを要求します。ただし、これも私の目標ではありません。そのような保護は既に克服されており、根本はできる限り合法であることが前提です。
マシンに物理的にアクセスできる人なら誰でも、ハードドライブに保存されているすべてのもの、さらにはメモリに保存されているすべてのものを取得できることは明らかです。 rootユーザーがバイナリまたはカーネルイメージを変更する権限を持っている場合、再起動後にセキュリティを保証できないことも明らかです。システムを再起動せずに実行できる攻撃のみに関心があります。
また、起動プロセス中に、シークレットは多くの場所から送信される可能性が高く、多くのセキュリティクリティカルな機能が必要です。起動プロセス中にもシークレットを保護できるのはもちろん素晴らしいことですが、私にとって十分なのは、起動時に昇格された特権を削除し、その後にそれらを回復する方法がないステップです。
では、これらの制限付きで、Linuxで完全なrootユーザーがいくつかのシークレットにアクセスできないようにする方法は何ですか？
どうしても完全なルートにはアクセスできないが、一部のプロセスにはアクセスできるファイルがファイルシステム上にある可能性はありますか？現在実行中のプロセス、または現在アクセスしているプロセスによって開始された新しいプロセス
プロセスを実行してシークレットをメモリに保持し、完全なルートでも何らかの方法でそれらにアクセスできないようにすることはできますか？これらの秘密は、ルートが影響を及ぼさない何らかの方法で新しいプロセスに送信できますか？
これは、自分に関連する回答を得るために書くのが難しい質問です。必要に応じて、質問をより具体的になるように編集してみます。
制限する必要がある明らかなことは次のとおりです。
/ proc/memへのアクセスを無効にする
/ proc/<pid>/memへのアクセスを無効にする
/ proc/<pid>/fd/*へのアクセスを無効にする
モジュールのロードを無効にする（一部のモジュールがロードされた後でのみ可能）
プロセスへのptraceアクセスを無効にする
実際、ルートを制限することは可能ですif基本的にオペレーティングシステムを信頼するような制限を定義する準備ができている場合これは（私が知っている）SELinuxとおそらく他のそのようなシステムを使用して行うことができます。そのような方法で使用されたSELinuxで私が見たそのような最良の例は、Russell Cokerの Play SELinux Machine です。
それがどのように機能するかの簡単な概要として、「ルート」という名前はUnixでは特別ではありません。 UID 0です。 UID 0は、「私が言うすべてを信頼する」という意味です。これは、Unices、Unixen、または複数形の「Unix」で使用される標準アクセスモデルに特に当てはまります。
LSM（Linux Security Modules）を使用すると、ほぼすべてにフックして、必要に応じてアクションを監査/拒否できます。 SELinuxの場合、SELinux権限はUnix権限の後にチェックされるため、フローは次のようになります。
Event ----> Has Unix Permissions? ---> Has SELinux Permissions? ---> Let it happen
理解する次の段階は、SELinuxポリシーのバージョンが異なる、または歴史的に存在しているということです。その前に、SELinuxで次のことを理解してください。
- iノードにはタイプがあり、サフィックス
_tが付いています。これはドメインとも呼ばれます。そして - ユーザーにはロールがあり、サフィックス
_rが付いています。
これらを組み合わせて、特定のロールのユーザーが実行できるアクションと、特定のドメインのプロセスが実行できるアクションを制御します。
現在、3つの主要なSELinuxポリシーがあります。
- targeted。これはFedoraのようなデスクトップのデフォルトポリシーです。ターゲットのアイデアは、重要なシステムサービスとデーモンはドメインで実行されますが、エンドユーザーが行うことの多くは
unconfined_u:unconfined_r:unconfined_tで実行されるということです。それが何を意味するかを推測するための賞品はありません-Unixの許可が機能する場合、SELinuxは事実上パススルーです。 - strict。このポリシーには、
unconfined_uの完全な削除が含まれます。これは、特にLinuxデスクトップ（つまり、init 5）では、簡単なプロセスではありません。具体的には、X11セキュリティモデルは優れておらず、一部のアプリケーションではunconfined_tが必要になることがよくあります。あなた これを行うことができます ですが、特にrootを必要とするGUIアプリケーションを実行するときは、X11での作業は（不可能ではありませんが）より困難になると予想します。 XACE（X Access Control Extensions） と呼ばれる、XのSELinuxのような機能のサポートを提供するプロジェクトが進行中です。 - MLS。MLSはマルチレベルのセキュリティを表し、許可文字列の終わりを意味します：
user_u:system_r:httpd_content_t.s0-s2:c5-c7、つまりそれらのsそしてcの数字は実際には何かを意味します。具体的には、プロセスが特定のレベルで実行されていない限り、表示できる情報が制限されるように、 読み取りなし、書き込みなし セットアップを形成します。このレベルの情報は、機密資産を保護するためのものです。SELinuxは、おそらくこの目的のためにNSAによって開発されました。
それがあなたの背景です。今、ウェブページによれば（ [〜＃〜] faq [〜＃〜] を参照）ルートはUID 0プレイマシン上では、rootはuser_rとして実行されるように設定されており、sysadm_rではなくstrictポリシーこれは、ユーザーがシェルから管理機能を実行することを許可されないことを意味します。
興味深いのは、rootを必要とする他のプロセスのステータスです。おそらく、そのようなプロセスには適切なラベルが付けられ、必要なアクセスを許可するポリシーが設定されています。次に問題は、システムをどのように管理し、これらのプロセスのいずれかがそのユーザーのコンテキストでシェルを起動できるようになることです。それが発生する可能性がある場合でも、エクスプロイトを管理できます。
プレイマシンは現在（執筆時）ダウンしているので、ここでは前提に取り組んでいます。ただし、本質的には、sysadm_rで実行され、エクスプロイトのターゲットとしてUID 0を使用するプロセスが必要になります。そのようなプロセスが存在し、悪用可能であると仮定すると、まだrootになる可能性があります。 rootを介して引き続き管理できることに関しては、私が考えることができる2つのオプションがあります。
- Rootが
sysadm_r（安全性が低い）に移行できることを意味する、ある種の信頼できる移行があるまたは - 異なるランレベルでは、異なるポリシーが適用されるため、マシンを管理するには、ランレベルを1に設定し、ポリシーはルートを制限しません。ここだと思います。
概要
「今すぐ簡単かつ安全にこれを行うことができますか？」という質問の場合答えはノーだ。あなたの質問が「SELinuxについて学ぶ準備ができており、私のディストリビューションに慣れて、多くのことがうまくいかないことに我慢している」なら、答えはあなたの平均的なインストールよりはるかに多くのルートを制約することが可能であるということです。とは言っても、これは決して悪用に対して無防備になるわけではありません。ユーザーがこの追加のアクセス制御をソフトウェアまたは物理的に回避することを不可能にすることはありません。
つまり、ルートから見えないようにすることができます。ただし、余計な技術的負担はさておき、通常のユーザーのアクセス制御設定に関して同じ警告が適用されます。特効薬はありません。
ああ、露骨な自己宣伝： ソフトウェアに秘密を保存する に関する私のブログ投稿が好きかもしれません。それはセキュリティstackexchangeブログにあるので、それを宣伝することにそれほど気を悪くしません。基本的に、ご覧のとおり、攻撃者（およびあなた）の生活をより困難にするメカニズムがありますが、結局のところ、それは「カメがずっと下にある」、つまり根本的に不可能であるケースです。
Webサイト上のユーザー間で「プライベートメッセージ」を安全に保持したいクライアントからアプローチを受けたとき、私は以前にこの問題に取り組む必要がありました。状況によっては一部のデータを保護することは可能ですが、これにはかなりの制限があります。
私のアプローチは、暗号化されたバージョンのメモをサーバーに保存し、それを（もちろん認証されたら）送信して、クライアント側で完全に復号化することでした。つまり、サーバーのセキュリティ（ルートアクセスなど）が完全に侵害された場合でも、メモは安全なままでした。ただし、これには次の制限があります。
- 保護されたデータは、妥協点までしか安全ではなく、それ以降は安全ではありません。情報の暗号化に使用される方法によっては、ルート化されたサーバーがユーザーをだまして、解読キー（JavaScriptインジェクション、またはネイティブGUIクライアントの場合は、侵害されたクライアントの更新を発行）、または解読キーをインターセプト（キーがベースの場合）パスワードなど、ユーザーを認証するのと同じ方法では、サーバー側の認証プロセス中にそれらが傍受される可能性があります。
- 送信には完全転送秘密が必要です。そうでない場合、暗号化されたデータが傍受され、保存され、上記のように妥協後に解読される可能性があります。
- クライアントも危険にさらされている場合、これは何も保護しません。暗号化されたデータを完全に自分の頭で処理しない限り（そして、可能であれば、トロフィーか何かに値する）、機密データをsomethingに渡して、何も- 完全に妥協できません。
- 解読可能な/プレーンテキストのメタデータが一緒に保存されていない限り、このデータをサーバー側で（つまり、インデックス作成の目的で）使用する方法はありません。
基本的に、これはこのシナリオの潜在的な用途を制限し、まだ弱点がありますが、状況によっては機能する可能性があります。パスワードハッシュは、「ルート侵害保護」の（合理的に）成功した例です。物理的なアクセスでさえ、ユーザーのパスワードを明らかにしません（もちろん、そのパスワードが妥協後に送信された場合は除きます）。
このスレッドには他にも調べる価値のある他の例がありますが、サーバーを単に安全なストレージサービスとして使用して、クライアント側の処理シナリオを検討してください。
TC
どうしても完全なルートにはアクセスできないが、一部のプロセスにはアクセスできるファイルがファイルシステム上にある可能性はありますか？現在実行中のプロセス、または現在アクセスしているプロセスによって開始された新しいプロセス
いいえ。プロセスがそれらにアクセスできる場合、ルートも可能です。このようなことをしたい場合は、システム全体を大幅に変更する必要があります。おそらく、読み取り専用デバイスから不変のカーネルを起動し、特定のファイルやメモリへのアクセスを拒否する一方で、rootが実行できる他のユーザーにはそれらを許可するシステムです。偽装。
プロセスを実行してシークレットをメモリに保持し、完全なルートでも何らかの方法でそれらにアクセスできないようにすることはできますか？これらの秘密は、ルートが影響を及ぼさない何らかの方法で新しいプロセスに送信できますか？
いいえ。上記の回答を参照してください。
当然、rootのアクセスを制限することはできません。 rootのアクセスを制限すると、rootユーザーではなくなります。
シークレットへのルートアクセスを拒否する場合は、シークレットを非表示にしようとします。暗号化コンテナー。おそらくスワップメモリまたは他の場所に隠されており、パスワードまたは他のある種のステガノグラフィーでのみアクセスできます。不可能ではないにしても、干し草の山から針を見つけるのは大変です。
Rootが任意のコードを実行してしまう間接的な方法がいくつかあります。それらを無効にすることができます。実際に一部のセキュリティフレームワークはそれらを無効にする場合がありますが、rootが管理タスクを実行する機能を無効にします。
たとえば、rootはディスクへの読み書きを直接行うことができ、あらゆる方法のファイルシステムのアクセス許可をバイパスします。この機能を取り除くことはできますが、緊急時にはrootはファイルシステム全体を新しいディスクに移動できません。
ルートはカーネルモジュールをロードできるため、カーネルが実行できるすべてのことを実行できます。この機能を削除することはできますが、ホットプラグ可能なメディアのドライバーをロードすることはできません。 （これはUNIXインストールの.001％では望ましいかもしれませんが、一般的なケースではありません。）
Rootは、loginやsshdなどのユーザーがログインできる実行可能ファイルを更新できます。これらのデーモンはユーザー認証を処理するため、ユーザーがコードを制御している場合は、バックドアを挿入できます。この機能は削除できますが、rootはセキュリティアップグレードを実行できなくなります。
Rootはユーザーを作成および削除し、認証資格情報を変更できます。/etc/passwdを編集してアカウントを追加できる場合は、それを編集してアカウントを一時的にパスワードなしにすることもできます。 rootでも一部のファイルを読み取り専用にすることでこの機能を削除できますが、システムが再起動せずにユーザーアカウントを作成または削除できないことになります。
セキュリティフレームワークは、システムのサブセットでのみrootである制限されたrootユーザーを効果的に作成します— rootは「実際の」システムではなく、仮想マシンでのみrootです。この制限されたルートは、実際のシステムで管理タスクを実行する可能性を失います。仮想化はあなたが求めているものだと思います。
これは、「2つのキー」のselinuxシステムを使用することで比較的簡単に実行できます。rootには何もする権限がなく、root権限のない他のユーザーdoesなので、変更するには、最初に非root他のユーザーの場合、変更を行うためにrootに "su"します。
どちらのユーザーも、孤立して何もすることも見ることもできません。
これを使っています。それは本当にうまくいきます。
実際のニーズは質問では明確に定義されていませんが、言及されていないことが示唆されている2つの潜在的なソリューション：
- コンテナ
- HSM
コンテナー-もちろん、jailやSELinuxのようなツールを使用して断片的に行われていたことに対して、よりアーキテクチャ的に賢明なアプローチです-質問の再構成のコンテキストに関連する可能性があります-UNIXのような論理的な方法がありますシステムは攻撃者にさらされる可能性があり、rootが危険にさらされる可能性がありますが、物理システムのシークレットは保護されます。コンテナーを使用すると、この目標に近づきます。セキュリティグループNCCによる最近の論文は一読に値します： https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf
HSMはハードウェア暗号化デバイスであり、物理的または論理的な方法による復号化キーの取得を防止します。そのため、安全に復号化する必要がある秘密があるため、キーを使用して何をすべきかを再構成した質問への回答になる場合があります。
ファルコンが言ったように、ルートユーザーは定義によりそれらすべてのものにアクセスできるか、もはやルートユーザーではありません。
カーネルはすべてのハードウェアを制御するため、rootになると同じアクセス権が与えられます。本当に仮想化が必要なので、rootユーザーはそれが実行されている仮想化されたOSのrootのみであり、一部のハイパーバイザーはそのrootの外側にあります。 （ハイパーバイザーが悪用可能ではないことは言うまでもありませんが、実行しようとしていることはこれと同等です）。
Grsecurityを試しましたか？あらゆる可能な方法でrootユーザーを効果的に制限できます。 https://grsecurity.net/
GrsecurityとPaXを組み合わせることで、ボックスを難攻不落の要塞にします。