rootユーザーを* nixシステムから削除して、特権の昇格を防ぐことはできますか？
* nixシステムが適切に構成および強化されたら、すべてのスーパーユーザー/ルートユーザーを削除することは考えられる戦略ですか？スーパーユーザー権限の昇格の悪用を完全に防ぐためにシステムからrootを完全に削除することには利点がありますか？
編集：要点：スーパーユーザー（root、uid = 0など）を完全に機能ベースのシステムで置き換えることはできますか？
あなたが望んでいたとしても、私はあなたがルートユーザーを削除することはできないと思います。 Wikipedia から：
たとえば、Unixのようなシステムでは、アカウントの名前に関係なく、ユーザー識別子（UID）がゼロのユーザーがスーパーユーザーになります。
脆弱性が悪用するカーネルコードの多くは、
// become root
uid = 0;
...
if (uid == 0)
// do some protected thing
したがって、スーパーユーザーは実際には「ユーザーアカウント」ではなく、文字通り数字の0です。uid = 0を設定するエクスプロイトを見つけたら、bam！ "root"という名前のユーザーアカウントがあるかどうかに関係なく、プロセスにはSudoがあります。
アドレス指定コメントの編集：Linuxのいくつかのフレーバーは「！」を付加します/etc/shadowパスワードファイル（パスワードハッシュ関数で生成できない文字）のルートのパスワードに変更すると、実際にルートとしてログインできなくなります。これにより、ルートパスワードのクラックに基づく一部のタイプのルート特権エスカレーション攻撃が阻止されますが、より危険な種類の特権エスカレーションは、プロセスのuid変数をuid=0に上書きするバッファオーバーフロー攻撃に基づいています、その時点でそのプロセスはrootです。
他の人が主張しているように、ルートUID（UNIXではUID 0として表されます）を「削除」しても意味がありません。さらに進んで、システムをフリーズして新しい特権を提供する手段がないようにしても意味がないと述べます。カバーするトピックが非常に大きいため、この回答は非常に古く、あいまいです。最初に、* NIXでrootであることの意味を見てみましょう。 Linuxは最も人気のある* NIXであり、特定のメソッドが付属しているので、コメントします。うまくいけば、他の人がBSDファミリーをカバーできるようになるでしょう。ルートの意味するところを区別してみましょう：
- 随意アクセス制御
- Linuxセキュリティモジュール
- UNIXの機能
- ユーザー名前空間
いずれの場合でも、現在rootとして実行されているすべてのバイナリに、システム全体に特権制限を盲目的に適用することはまったく意味がないことに注意してください。多くの場合、これらの特権は何らかの理由で存在します。したがって、以下の概要を読んで、権限のないユーザーに対してあなたが実行し、悪用から保護したい特定のサービスにどのように影響するかを説明する必要があります。
随意アクセス制御
* NIXシステム上のファイルにアクセスするためのほとんどの権限は、DACモデルによって義務付けられています。多くのカーネルインターフェースとIPCメカニズムはファイルとして抽象化されているため、これはかなり重要な考慮事項です。これは、所有者ID、グループID、および所有者の読み取り/書き込み/実行権限を持つモデルです。グループメンバーやその他のIDも含まれています。これには、suidビットとsgidビットも含まれていますが、ここではこれらをオフにしておきます。
デフォルトでは、UID 0は常にDACチェックをバイパスします。これは、UID 0にCAP_DAC_OVERRIDE UNIX機能があるためです（以下を参照）。この機能を自己削除するプロセスはDACに従う必要がありますが、ディストリビューションのほとんどのシステムファイルはrootによって所有され、書き込み可能です。この機能を削除すると、ユーザーファイルはある程度保護されますが、システム自体は保護されません。また、この機能のない（および他の機能を取得する直接の手段がない）rootユーザーが、システムを破損または引き継ぐために、login、カーネルイメージ、またはその他のキーファイルを変更できる可能性も高くなります。
Linuxセキュリティモジュール
DACチェックに加えて、Linuxのすべてのシステムコールは、 Linuxセキュリティモジュール インターフェイスを実装するプラグイン可能なカーネルモジュールを経由します。これらはrootへの特権を拒否するために使用できます。
たとえば、SELinuxはこの目的のために役割の概念を使用しています。私が知っているすべてのディストリビューションのデフォルトポリシーでは、ログインデーモンが制限された役割でルートセッションを開き、従来のルート操作を実行する前にsysadm_rという役割に明示的に切り替える必要があります。 rootが他の役割でrootのようになるのを防ぐために、ポリシーを作成する必要があります。それでも、LSMでは必須のアクセス制御ポリシーを記述できるため、この方法でroot権限を効果的に制限できます。ただし、ナイスな側面は、user：roleタプルを役割に効果的にトラップでき、ログイン方法に応じて役割を選択的に提供できることです。これにより、特定のrootアカウントのスコープをシステム全体に制限できます。
UNIXの機能
capabilitiesのmanページ と言い換えたくありませんが、本質的には、ユーザーIDがカーネルの特定のインターフェースと対話できるようにします。たとえば、CAP_CHOWNを使用すると、ファイルの所有者を変更できます。デフォルトでは、ルートでほとんどの機能が有効になっており（私が正しく思い出せば、CAP_MAC_ADMINまたはCAP_MAC_OVERRIDEはデフォルトで無効になっています）、他のIDには何もありません。
ただし、独自のセットから一部の機能を削除できるため、CAP_SET_FCAPおよびCAP_SET_PCAP機能を持っている限り、ルートプロセスとして自分を非特権プロセスに変換できます。他の多くの機能を使用して完全な特権を取り戻すことができると主張されていることに注意してください。現在、そのような機能のリストを見つけることはできませんが、ルートプロセスに残した機能をさらに妥協するためにどのように利用できるかについて真剣に考える必要があることに注意してください。
DACはファイルアクセスを制御しますが、機能はシステムコールのアクセスと動作を制御します（MAC LSMは両方を制御します）。各機能の機能を理解するには、多くの呼び出しのマニュアルを読む必要があります。
Linuxの機能の適合性に対する批判があります。 Kerriskは "CAP_SYS_ADMIN：the new root" で、一部の機能は非常に依存しているため、それらが完全な機能を持つことを意味すると主張しました。これは、スーパーユーザーの概念をすべて排除することはできないことを示唆しています。少なくともシステムを起動してセットアップし、特定のカーネル内サービスを提供するには、非常に特権が必要です。閉じ込めの強力な機会を提供するMACシステムでは、特権を再取得する必要があるという問題に遭遇することがよくあります（たとえば、SELinuxでは、メンテナンス操作を実行するために役割をsysadm_rに変更する必要がある場合があります）。同様に、これらの機能を削除した場合、新しい特権サービスを（再）開始できますか？それを行う能力は、完全に特権を与えられることと同等ではないでしょうか？
Linuxユーザー名前空間
名前空間を使用すると、非常に漠然と、システム内で実行されるプロセスにシステムの異なるビューを提供できます。マウント名前空間を使用して、プロセスとその子が表示および変更できるファイルを変更したり、ネットワーク名前空間を使用して、さまざまなネットワークインターフェイスやシステム構成を提供したりできます。これは、たとえばPaaSサービスを提供する人に役立ちます。ユーザー名前空間を使用すると、名前空間内のすべてのユーザーIDを外部の単一のユーザーIDにマップできます。これは、ネームスペース内で必要なことをすべて実行でき、ネームスペース外の非特権ユーザーにマップされるrootユーザーを持つサブシステムを持つことができることを意味します。
その正確な意味は何ですか？誰かがカーネルを悪用してrootにエスカレートできる場合、ユーザー名前空間の利点は疑わしいものです。ただし、この悪用がsuidバイナリをターゲットにしている場合、そのネームスペース内のルート権限にアクセスする非特権プロセスは、ホストOSに影響を与えることができません。名前空間などの制限ソリューションは、防御の境界を変えるだけです。すべての特権プロセスに欠陥がなく、悪用できないことを証明する代わりに、名前空間内の完全特権プロセスが、ホストOSと名前空間の間で開いたままにした通信チャネルを介してホストOSに影響を与えないことを証明する必要があります。最終的に、リソースにアクセスするためにネームスペース内の特権サービスが必要な場合、そのサービスを危険にさらすと、そのリソースへのアクセスが許可されます。
今何？完全に限定されたUNIXを提供できますか？
上記のこれらすべての方法により、サービスを特定の特権に制限することができます（特定の警告を組み合わせて（DAC + caps）または単独で（LSM、名前空間のいずれかで）。それらを組み合わせて詳細な防御を提供することもできます。ただし、すべてを制限することが有益であるかどうかは、権限を仲介し、完全な権限の概念（CAP_SYS_ADMIN、UID 0、名前空間のない特権ユーザー、LSMの特定の概念）を表す方法からは非常に独立しています。
オペレーティングシステムを作成して、ユーザーのニーズに対応できるようにしたい場合は、オペレーティングシステムを更新して再構成し、新しいサービスを実行する手段を提供する必要があります。システム保守に、セキュリティサービス、アクセス制御ポリシー、カーネルおよびハードウェアモジュールの更新などの操作が含まれる場合は、人間のユーザーが完全な特権を持つアクターとして機能する方法を提供するか、3番目のアクターを持っている必要があります。 OSを適合させ、ユーザーのデータの上に適合させたバージョンを展開できるパーティシステム。後者が望ましいかもしれない高度なセキュリティコンテキストがあります（非常に率直に言って、これは概念的にはVMを実行するのと同じくらい簡単です）。ただし、システムを自己管理するユーザー集団による汎用コンピューティングの場合、完全に特権のあるIDを削除することはできません。
Initプロセスは、最初にrootとして実行する必要があります。しかし根本的に、rootの定義はそれが0のIDを持つユーザーであるということではなく、カーネルルーチンにアクセスする能力を持つプロセス所有者です。 AAAの場合、サブミットされたジョブに関連するコマンドのみを実行するシステムを実施できますが、それ以外にはrootユーザーを削除する理由はありません。もう1つは、システムを魅力的にするのはルートアカウントではなく、マシン上で実行されているサービスがデータを持っているか、またはデータを転送できることが焦点となっているという事実です。
実際、すべての「ユーザー」を削除できます... 1つのタスクを実行する静的にリンクされたバイナリプログラムだけを含むカーネルは、/ etc/passwdファイルがなくても問題なく機能します。もちろん、uidとeuidの概念はまだ存在しています。
システムが1つの特定のタスクを実行する場合...すべてを削除します。ファイルシステム、ブートローダー、ライブラリ、その他の役に立たないがらくた。カーネルで直接タスクを実行するだけです。 （ROMからの起動はまた別の話になります;）もちろん、コードにリモートの脆弱性がある場合でも、引き続きアクセスできますが、シェルがないため、リモートで挿入できるコードに制限されます。
-言われていること--ほとんどの通常のシステム--ほとんどのハッキング-uid0へのハッキングは、パスワードの総当たりやトラフィックの傍受ではなく、それを回避するために構築されたすべてのがらくたを使用して行われます。具体的には、Sudo、tracerouteなどです。ユーザー「www」から「root」へのほとんどのエクスプロイト-suidバイナリが必要です... suとSudoが何であるかを推測します。
システムが完成したら...結局のところ、すべての「アクセス」を維持する明らかな理由はありません。結局のところ、問題を修正する理由がある場合は、イメージ全体を開発プラットフォームからデプロイメントインフラストラクチャのフラッシュに更新できます。エディター/コンパイラーをローカルで実行するために「アクセス」するのではなく、eepromストレージ。