rootへのアクセスを拒否できるユーザーを実際に持つことができるように、* super *スーパーユーザーを作成できますか？
Rootユーザーよりも高い権限を持つユーザーがいる方が有利だと考えていました。
ご覧のとおり、すべてのアクティビティとalmostすべての既存のrootユーザー権限を現在とまったく同じように保持したいと思います。
ただし、非常に隔離されたケースバイケースでroot権限を拒否する機能が必要です。
これの利点の1つは、更新中に特定の不要なファイルがインストールされないようにすることです。これは、考えられる利点の1つの例にすぎません。
Apt-get更新はrootまたはSudo権限で実行されるため、apt-getは更新中に特定の不要なファイルを置き換えることができます。
これらの特定のファイルに対するこれらの権限を拒否できる場合は、それらを/dev/nullへのsimlinkとして設定するか、更新中にファイルの置き換えを拒否する権限を持つ空白のプレースホルダーファイルを設定することができます。
さらに、私は仕方がないのですが、Ubuntuクリエイターの1人とのインタビューで、ユーザーが「私たち」（Ubuntu開発者を指します）をどのように信頼するかについて何かを言ったときに「私たちがルートを持っている"これは、システム権限がroot権限で実行される方法への参照でした。
この問題を回避するためにインストール手順を変更するだけでは、ここではまったく興味がありません。 rootのアクセスを拒否する力があるという考えが頭に浮かんだので、これを行うためだけにこれを実現する方法を考えたいと思います。
私はこれについて考えただけで、今のところそのアイデアに時間を費やしていないので、これが理解できると確信しています。しかし、これが既に行われたのか、これが新しいアイデアやコンセプトではないのか知りたいです。
基本的には、システムの権限を1度だけ超えた権限を持つスーパースーパーユーザーを作成する方法があるはずです。
注：承認された回答は基準に最も一致すると思いますが、@ CRの回答が本当に気に入っています。また。
ツリー（私）の上の方に実際のユーザーを作成したいのですが、それを理解する時間があるときは、1日座るだけで済むと思います。
さらに、私はここでUbuntuを選ぶつもりはありません。私はそれについて否定的に感じたなら、それを私の主要なディストリビューションとして使用しません。
必要な「ユーザー」は、LSM：Linuxセキュリティモジュールと呼ばれます。最もよく知られているのは、SELinuxとAppArmorです。
これにより、特定のバイナリ（およびその子プロセス）が特定のことを実行するのを防ぐことができます（UIDがrootであっても）。ただし、これらの操作をgettyおよびその子プロセスに許可して、手動で実行できるようにすることもできます。
rootユーザーの概念を誤解しています。
わかりやすい英語では、rootは「ツリーの最上部」にあります。
ある日「スーパースーパーユーザー」を作成し、次の月に「スーパースーパースーパーユーザー」（！）を作成するとしたらどうでしょう。どれくらいツリーを「上」に行きたいですか？それを機能させるために、すべての権限と階層をどのように入れ替えますか？誰が常に一番上にいますか？誰かがトップにいる必要があり、それはrootです。話の終わり。
ここで説明するソリューション（AppArmorやSELinuxを含む）は、これを実際に変更するものではありません。それらは単にrootの権限とプロセスをより細かく制御できるようにします。
あなたの更新プロセスは望ましい結果には適していないように思えます。しかし、それはrootユーザーの責任ではありません。物事を複雑にするのではなく、rootを最高レベルの権限を持つユーザーと考え、それから他のすべてのものは、下に向かって取り組む必要があります。
一部の人がこれをマークダウンすることを知っていますが、ユーザー階層の上位レベルはありません。他のすべてのソリューションは、root権限の動作にわずかに異なる制御を与えるだけです。ただし、より高い権限を持つcreate新しいユーザーは対象外です。
rootは可能な最高レベルの権限を表すため、rootよりも「より多くの権限」を持つユーザーを持つことはできません。 「ルートよりも多くのコントロール」のようなフレーズを使用することは矛盾します-rootはフルコントロールとすべての可能な権限を持っているため、それ以上に実行できることはありません。
ファイルやディレクトリが変更/削除されないようにしたい場合は、それらに不変フラグを設定します。
chattr +i <file>
フラグが削除されない限り、rootでさえ何もすることができません。コンテナー/名前空間システムを使用してrootアクセスを防止することも可能ですが、それはあなたが必要とするものに対してはやり過ぎのようです。
スーパースーパーユーザーの代わりに、ルートを制限できます。参照 gnu/linuxでファイルのアクセス権などを設定するさまざまな方法は何ですか
AppArmorとSELinuxもあります。
または
Sudoを設定して、完全なroot権限を与えないようにします。ユーザーが事前に合意された引数を使用して事前に合意されたコマンドのみを実行できるように設定できます。仮想化を使用してrootを制限することもできます：
- cgroups、名前空間、chrootなど（dockerがこれを行います）
- Xen
- Virtualbox
etckeeperも参照してください。このツールリビジョンは/etcディレクトリを制御し、aptと同期します。デフォルトでは安全ではありません。悪意のあるインストールによって妨害される可能性がありますが、ファイアウォールのバックアップリポジトリに変更をプッシュすることもできます。ファイアウォールのバックアップリポジトリを使用した、一般的なリビジョン管理の使用。これは、偶発的で意図的な破損とハードウェア障害に役立ちます。
ファイアウォールで保護されたバックアップリポジトリは、別のマシン、インターネット、または別の仮想マシン（または仮想マシンのホスト）に配置できます。
[〜＃〜] apt [〜＃〜]のようなソフトウェアの場合、通常の操作ではほとんどすべてのシステムにアクセスする必要があるため、制限が問題になります。システムの特定の部分にアクセスできないようにしたとしても、悪意のあるディストリビューターが回避する可能性は十分にあるでしょう。たとえば、ライブラリまたはバイナリのみを置き換えるか、悪意のある構成変更を追加すると、無制限のルートが最終的に使用されます。
制限の程度によっては、一部のインストールスクリプトが機能しなくなる可能性があります。
アプリケーションとユーザーを制限する方法については、AppArmorまたはSELinuxポリシーを記述できます。そのようなポリシーはどちらがよりサポートされるかはディストリビューションに依存します：DebianベースのAppArmorに対するサポートはより優れていますが、Fedora/RHELベースのディストリビューションはデフォルトでSELinuxを有効にします。
AppArmorとSELinuxはどちらも、特定のアクションを許可（または拒否）するルールを含むホワイトリストポリシーで機能します。ポリシーはexecでプロセスに適用されます。同様に、ログイン時にポリシーがプロセスに適用されると、ユーザーを制限できます。よく考えられたポリシーは回避できません（カーネルのバグが考慮されていない場合）。 root（uid 0）として実行されている制限されたプロセスは、構成されたポリシーによって制限され、ポリシーで明示的に許可されていない限り変更できません。
AppArmorポリシー言語は denyルール を定義し、ブラックリストの作成に使用できますポリシー。 AppArmorで始めるのに適した場所は、AppArmor man pages 、 wiki で、ディストリビューションの既存の構成を/etc/apparmor.d/で確認します。
たくさんのSELinux管理および開発資料が SELinux wiki で提供されています。 SELinux 参照ポリシー はgithubでホストされています。
誰もが適切なピン留めについて言及していないとは信じられません...
数年前、マイクロソフトは、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
正確な構文についてはドキュメントを確認してください。ただし、これはパッケージバージョンをすばやく簡単に固定する方法です。 root could rootは常にできるので、これをバイパスしますが、これにより、パッケージマネージャーがパッケージを自動的にアップグレードしようとする問題が解決されます。
注：この回答は XY問題 があることを前提としています
それは実際には非常に簡単です。
ルートは「スーパースーパーユーザー」です
「admin」という名前のアカウントを作成し、不要なものを除くすべてのroot権限を彼に付与します。
次に、bobというユーザーを作成し、「管理者になる」ようにします。 suまたはSudoを使用する。
これで、通常のユーザー（bob）と、管理作業（admin）を実行できるスーパーユーザーと、スーパースーパーユーザー（root）ができました。
「ルート」という名前を別の名前に変更したい場合は、それを行うこともできます。技術的にはユーザーID（0）のみが重要です。
特定のファイルがインストールされないようにするだけの場合は、rootのアクセス許可を制限するだけではこれを実行できません。 APT（および他のほとんどのパッケージマネージャー））ができる場合は救済されるため、従来の回答（不変ファイルまたはLSM）は特定のユースケースでは機能しないことにも注意する必要があります。 tファイルをインストールします。
あなたが聞きたい本当の質問は：
APTが特定のファイルをインストールするのを防ぐ方法はありますか？
それは、あなたが複数のレベルで求めているものとは完全に異なるものです。
さて、その質問に関して、私は100％確信していませんが、他の多くのパッケージマネージャーには特定のファイルがインストールされないようにするオプションがあることを知っています（たとえば、GentooのPortageシステムにはオプションINSTALL_MASK=、実際にはインストールしないもののシェルスタイルの一致パターンを受け入れます）。そのようなオプションがAPT（またはおそらくdpkg自体）に存在することは間違いありません。
Xen hypervisor のようなタイプ1ハイパーバイザーを実行し、仮想ゲストとして通常のOSをホストすることができます。ハイパーバイザーは、ゲストOSが実行される（仮想）ハードウェアを制御するため、仮想ゲストOSをrootより「深い」レベルで制御します。
ハイパーバイザーをプログラムして、権限の変更、バックアップの作成と適用、ゲストOSでの特定の変更や指示のフック、追加機能の挿入、検証など、さまざまな方法でゲストOSを操作できます。これは、有効で、潜在的に有用な方法です。 「ルート」でも実行できないことを実行するための「ユーザー」（実際にはハイパーバイザーの機能）を使用してUNIXタイプシステムを実装する
このアプローチはおそらくやり過ぎだという私の感覚
バックアップコピーを安全な場所に置きます。インストール/更新後、すぐにそのバックアップから特定のファイルを置き換えます。したがって、インストールを台無しにするエラーはありませんが、保持したいファイルを取り戻すことができます。
マウントされたドライブから作業する
これは主に概念的な答えですが、私はそれが機能し、あなたが達成したいことに霊的であるはずだと思います。
システムXを作業システム、システムYをユーザーが制御する他のシステムとします。
- XのドライブとしてYからディレクトリをマウントする
- Xのrootユーザーがこのマウントされたドライブのすべてに対する権限を持つように権限を設定します。いくつかの例外があります。
これで、ほぼすべてを実行できる「作業ルート」ができました。また、システムYの実際のルートアカウントである「スーパールート」があります。
このタイプの目標を達成するための代替方法として cgroups と Linux名前空間 をご覧ください。また、これらに基づくツール Docker および lxd 。
これらのツールを使用すると、「ルート」として実行されているプロセスが参照できるファイルシステムの部分を制限し、どのプロセスが可視であるかを制限し、特定の capabilities のみを「 root」ユーザー。
アンインストールSudo
Sudoと/bin/suから/bin/falseへのシンボリックリンクをアンインストールしてみませんか？ rootがssh経由でログインできず、システムがロックダウンされていることを確認してください。
これにより、rootがスーパー*スーパーユーザーになり、他のすべてのユーザーがその従属になります。
更新中に置き換えられるファイルについては、更新を行わないでください。より現実的には、ファイルの権限を440または444に変更して、書き込みできないようにします。または、それらをgitリポジトリに配置して、上書きされても元に戻すことができるようにします。