ルートユーザーよりも高いアクセス許可を持つユーザーがいると有利だと考えていました。

ご覧のとおり、すべてのアクティビティと既存のほぼすべてのルートユーザー権限を現在の状態のままにしておきたいと思います。

ただし、非常に孤立したケースごとに、rootへの特権を拒否する機能が必要です。

この利点の1つは、更新中に特定の不要なファイルがインストールされるのを防ぐことです。これは、考えられる利点の一例です。

apt-getの更新はrootまたはsudo特権で実行されるため、apt-getには更新中に特定の不要なファイルを置き換える機能があります。

これらの個々の特定のファイルに対するこれらの特権を拒否できる場合は/dev/null、更新中にファイルの置き換えを拒否するアクセス許可を持つ可能性のある空白のプレースホルダーファイルへのsimlinkとして設定できます。

さらに、Ubuntuクリエイターの1人とのインタビューで、ユーザーが「私たち」（Ubuntu開発者を参照）をよりよく信頼する方法について彼が言ったときに言われた行について思い出せずにはいられませんこれは、システムの更新がルート権限で実行される方法への参照でした。

この問題を回避するためにインストール手順を変更するだけでは、私がここで興味を持っていることは絶対にありません。私の心はルートアクセスを拒否する力を持っているという考えを持っているので、それを行うためだけにこれを実現する方法を見つけたいと思います。

私はこれについて考えただけで、これまでこのアイデアに時間を費やしたことはありませんでしたが、これが理解できると確信しています。しかし、これが既に行われたかどうか、またはこれが新しいアイデアや概念ではないかどうかを知りたいです。

基本的に、システムの許可を1度しか超えない許可を持つスーパースーパーユーザーを確保する方法があるはずです。

注：受け入れられた回答は基準に最も適合すると感じていますが、@ CRの回答は本当に気に入っています。また。

ツリー（私）の上位に実際のユーザーを作成したいと思いますが、それを理解する時間ができたら、いつか座らなければならないと思います。

また、ここではUbuntuを選択しようとはしていません。私はそれについて否定的に感じた場合、私のメインのディストリビューションとしてそれを使用しません。

必要な「ユーザー」は、LSM：Linuxセキュリティモジュールと呼ばれます。最もよく知られているのはSELinuxとAppArmorです。

これにより、特定のバイナリ（およびその子プロセス）が特定の処理を実行するのを防ぐことができます（UIDがであってもroot）。ただし、これらの操作gettyとその子プロセスを許可して、手動で実行できるようにすることができます。

rootユーザーの概念を誤解しています。

平易な英語でrootは、「木のてっぺん」にあります。

ある日、「スーパースーパーユーザー」、そして来月、「スーパースーパースーパーユーザー」（！）を決めるとしたらどうでしょう。木はどこまで「行きます」か。それを機能させるために、すべての権限と階層をどのようにシャッフルしますか？常にトップにいるのは誰ですか？誰かがトップにいる必要がありrootます。話の終わり。

ここに記載されているソリューション（AppArmorやSELinuxなど）は、これを実際に変更するものではありません。root許可とプロセスをより細かく制御することができます。

あなたの更新プロセスは望ましい結果に適さないように思えます。しかし、それはrootユーザーのせいではありません。物事を過度に複雑にするのではrootなく、最高レベルの許可ユーザーと考え、それから他のすべてのものと考えて、下に向かって作業する必要があります。

一部の人々はこれを書き留めることを知っていますが、ユーザー階層のレベルは高くなく、他のすべてのソリューションは、rootアクセス許可がどのように機能するかをわずかに異なる制御を与えるだけです。ただし、より高い権限を持つ新しいユーザーは作成されません。

可能な限り最高レベルのアクセス許可を表すrootため、「より多くのアクセス許可」を持つユーザーを持つことはできませんroot。「ルートよりも制御しやすい」などのフレーズを使用することは矛盾です- root完全な制御とすべての可能な許可を持っているので、その上でできることは何もありません。

ファイルまたはディレクトリの変更/削除を禁止したい場合は、それらに不変フラグを設定するだけです。

chattr +i <file>

フラグが削除されない限り、rootでさえも何もできません。また、コンテナ/ネームスペースシステムを使用してルートアクセスを防止することもできますが、必要なものが多すぎるようです。

• スーパースーパーユーザーを持つ代わりに、ルートを制限できます。gnu / linuxでファイル許可などを設定するさまざまな方法を参照してください

• AppArmorとSELinuxもあります。

• またsudo、configureを使用して、完全なルート権限を与えないようにします。ユーザーが事前に合意した引数を使用して事前に合意したコマンドのみを実行できるように設定できます。

• 仮想化を使用してルートを制限することもできます。

  • cgroups、名前空間、chrootなど（dockerはこれを行います）
  • Xen
  • Virtualbox

• 参照してくださいetckeeper：このツールの改訂は、コントロール/etcディレクトリを、そして傾向と同期します。デフォルトでは、安全ではないため、悪意のあるインストールによって妨害される可能性がありますが、ファイアウォールの付いたバックアップリポジトリに変更をプッシュすることもできます。

• ファイアウォールバックアップリポジトリを使用した、一般的なリビジョン管理の使用。これは、偶発的で意図的な破損やハードウェア障害の助けになります。

ファイアウォールバックアップリポジトリは、別のマシン、インターネット、または別の仮想マシン（または仮想マシンのホスト）に配置できます。

通常の操作ではほとんどすべてのシステムへのアクセスを必要とするAPTのようなソフトウェアの場合、制限は問題です。システムの特定の部分にアクセスできないようにしたとしても、悪意のあるディストリビューターが回避する可能性は十分すぎる可能性があります。たとえば、ライブラリまたは単にバイナリを置き換えるか、悪意のある構成変更を追加することにより、無制限のルートが最終的に使用されます。

制限をどの程度設定するかに応じて、一部のインストールスクリプトが破損することが予想されます。

アプリケーションとユーザーを制限する方法については、AppArmorまたはSELinuxポリシーを作成できます。よりサポートされるポリシーはディストリビューションに依存します：DebianベースはAppArmorをよりよくサポートしますが、Fedora / RHELベースのディストリビューションはデフォルトでSELinuxを有効にします。

AppArmorとSELinuxは両方とも、特定のアクションを許可（または拒否）するルールを含むホワイトリストポリシーで機能します。ポリシーはexecでプロセスに適用されます。同様に、ログイン時にポリシーがプロセスに適用されると、ユーザーを制限できます。よく考えられたポリシーは回避できません（カーネルのバグが考慮されていない場合）。ルート（uid 0）として実行されている制限されたプロセスは、設定されたポリシーによって制限され、ポリシーで明示的に許可されていない限り変更できません。

AppArmorポリシー言語は、ブラックリストポリシーを構築するために使用できる拒否ルールを定義します。AppArmorから始めるのに適した場所は、AppArmorのmanページ、wiki、およびのディストリビューションの既存の構成を調べることです。/etc/apparmor.d/

SELinux wikiには、SELinuxの管理および開発に関する資料が豊富に用意されています。SELinux 参照ポリシーはgithubでホストされています。

誰も適切なピン留めについて言及していないとは信じられません...

数年前、MicrosoftはWindows 10マシンが古いSamba NT4ドメインコントローラーと通信できないようにするパッチをリリースしました。問題が見つかったとき、Sambaパッケージを現在のバージョンのままにするように固定し、apt引き続き正常に機能しました。

完全なDebianウォークスルーはプロセスをうまく説明しています：

で/etc/apt/preferences（または新しいファイルの下で/etc/apt/preferences.d/）、どのパッケージとバージョンを指定するには、いくつかのテキストを追加します。

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

正確な構文についてはドキュメントを確認してください。ただし、これはパッケージバージョンを固定するための迅速で汚い方法です。ルートは常にできるので、ルートはそれをバイパスできますが、これはパッケージマネージャーがあなたのパッケージを自動的にアップグレードしようとする問題を解決します。

注：この回答は、XYの問題があると仮定しています

実際には非常に簡単です。

ルートはあなたの「スーパースーパーユーザー」です

「admin」というアカウントを作成し、不要なルート以外のすべてのルート権限を彼に与えます。

次に、bobというユーザーを作成し、「管理者になる」ようにします。suまたはsudoを使用します。

これで、通常のユーザー（bob）に、管理スタッフ（admin）を実行できるスーパーユーザーとスーパースーパーユーザー（root）ができました。

「ルート」という名前を別の名前に変更したい場合は、それもできます。技術的には、ユーザーID（0）のみが重要です。

特定のファイルがインストールされないようにするだけの場合、ルート権限を制限することはこれを行う方法ではありません。APT（および他のほとんどのパッケージマネージャー）がファイルをインストールできない場合に救済されるため、特定のユースケースでは従来の回答（不変ファイルまたはLSM）が機能しないことにも注意してください。

あなたが聞きたい本当の質問は：

APTが特定のファイルをインストールするのを防ぐ方法はありますか？

それは、あなたが複数のレベルで求めているものとは全く異なるものです。

今、その質問に関して、私は100％確信していませんが、特定のファイルがインストールされないようにするオプションが他の多くのパッケージマネージャーにあることを知っています（たとえば、GentooのPortageシステムにはINSTALL_MASK=実際にシェルを受け入れるオプションがあります-インストールしないもののスタイルマッチングパターン）。私は、APT（またはdpkg自体）にそのようなオプションが存在することを賭けたいと思っています。

バックアップコピーを安全な場所に置きます。インストール/更新後、そのバックアップから特定のファイルをすぐに置き換えます。したがって、インストールを台無しにするエラーはありませんが、保持したいファイルを取り戻すことができます。

マウントされたドライブから作業する

これは主に概念的な答えですが、私はそれが機能し、あなたが達成したいものと精神的にならなければならないと思います。

システムXを稼働システムとし、システムYを制御する他のシステムとします

1. XのドライブとしてYからディレクトリをマウントします
2. いくつかの例外を除き、Xのrootユーザーがこのマウントされたドライブ内のすべてに対する権限を持つように権限を設定します

これで、ほぼすべてを実行できる「作業ルート」があり、システムYの実際のルートアカウントである「スーパールート」があります。

Xenハイパーバイザーのようなタイプ1ハイパーバイザーを実行し て、仮想ゲストとして通常のOSをホストさせることができます。ハイパーバイザーは、ゲストOSが実行される（仮想）ハードウェアを制御するため、ルートよりも「深い」レベルで仮想ゲストOSを制御します。

ハイパーバイザーをプログラムして、アクセス許可の変更、バックアップの作成と適用、ゲストOSでの特定の変更または指示のフック、追加機能、検証などの挿入を含む、さまざまな方法でゲストOSを操作できます。 「rootでさえできないことをする」ために、「ユーザー」（実際にはハイパーバイザーの機能）を持つUNIXタイプシステムを実装する

このアプローチはおそらくやり過ぎだという私の感覚

見てくださいのcgroupと、Linuxの名前空間のようにそれらに基づいて、この目標の種類だけでなく、ツールを達成するための別の方法として、ドッカーとLXDを。

これらのツールを使用すると、特に、「root」として実行されているプロセスがファイルシステムのどの部分を表示できるか、どのプロセスを表示できるか、「root」ユーザーに特定の機能のみを提供できます。

アンインストール sudo

へのアンインストールsudoとシンボリックリンク/bin/suは/bin/falseどうですか？それをroot経由sshしてログインできないことを確認し、システムをロックダウンします。

これがrootSuper * Superユーザーになり、他のすべてのユーザーはそれに従属します。

更新中に置換されたファイルについては、更新を行わないでください。より現実的にファイルのパーミッションを変更する440か、444彼らは書き込みができないようにします。または、それらをgitリポジトリに配置して、上書きされた場合に元に戻すことができるようにします。