スーパーユーザーはどのアクセス権に違反できませんか？

神父 Br。ジョージは、彼の講義の1つ（ロシア語）で、スーパーユーザーが違反できないアクセス権があると述べました。つまり、スーパーユーザーが何かをすることを禁止できるアクセス権があります。

私はインターネット上でこの情報を見つけることができなかったので、それらが何であるか興味があります。これはおそらくシステムのコア実行に関連するものではありませんか？たぶん彼はいくつかのシステムプロセスを停止できないのでしょうか？それとも、彼はリアルモードでプロセスを実行できないのでしょうか？

この質問はSELinuxとは関係ありません（Georgeは質問の直前にそれについて話していました）。

ルートへのアクセスが拒否されました：

root直接ネットワークアクセスを拒否できます。それはあなたがとしてログインする必要があり、これは、インターネット接続されたホスト上で有用ですsmith、その後、sudo。

rootができないこと：

これは特権の不足のためではありません。rootができないことは何もありませんが、技術的な問題が「禁止」として経験される場合があります。

私はルートですが、普通のユーザーはできますが、なぜこのファイルを作成/削除できないのですか？

NFS / samba共有上にあり、特定の（access=）許可を与えていません。通常のユーザーはコモンローに失敗します。（以下のローカルルートとリモートルートを参照）

私はルートです、なぜこのプロセスを殺せないのですか？

保留中のI / Oがあり、物理ドライブ/リモートLUNが切断されました。プロセスは再起動によってのみ強制終了できます。

私はルートですが、アーキマーのパスワードを取得するにはどうすればよいですか？

次のことができsu - archemar、すべての権利、または変更archemarのパスワードは、以前のものを知らなくても、しかし、パスワードは一方向ハッシュを使用して格納されているので、あなたは、（キーロガーの短い）、それを読み取ることができません。

ローカルとリモートのルート

• ステーション/ PCでrootになり、会社/大学/大学/プロバイダーのNFS共有を使用できます。
• 次に、NFSをエクスポートするコンピューターで非ルートログインのみを設定できます。

いま

cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

NFSサーバーにログオンして実行するだけで./bash、会社/大学サーバーのルートになります。

通常の場合、これは誤りです。スーパーユーザーは、システムが提供するすべての機能に対する特権/許可を持っています（1）。このルールが破綻するのは、SELinuxをミックスに投入するときです。SELinuxでは、特定のアクションを禁止するためにrootの権限さえ制限することが可能です。ただし、許可されない特定のアクションは、ローカルマシンのSELinux構成に大きく依存するため、SELinuxを使用しても、一般的な意味でこの質問に答えることはできません。

（1）-システムが特定の機能を提供しない場合、たとえばリアルタイムカーネル機能がない場合、「ルートはこの機能にアクセスできません」というステートメントはfalseであると考えています。誤った仮定（つまり、与えられた機能はそのシステム上の誰でも利用できるということ）

一方で、次のようなユーザーにはできないこともあります。

• ディレクトリのハードリンク（ファイルシステムの制限のため）
• すでに書き込まれたCD-ROMへの書き込み（物理学のため）

しかし、それらは特権ではありません。付与できないため、誰にとっても不可能です。

次に、システム全体またはその一部に制限を適用して、オンまたはオフにできます。
たとえば、OS Xには、Appleによって署名されている場合にのみコードの実行を許可するオプションがあります。

スーパーユーザーができない場合、ユーザーはそれを所有できないため、これも実際の特権とは見なしません。グローバルにのみ無効にできます。

編集：
実行可能ビットのないファイルのアイデアもこのカテゴリに該当します。文字通り誰もそれを行うことができず、誰もその許可を与えることができないからです。
また、別のユーザーまたはグループにそのファイルを実行する権限を与えても、ルートまたはユーザーグループのルートが存在しない場合でも、ルートはそのファイルを実行できます（OS X 10.10、10.11およびUbuntu 15.04サーバーでテスト済み）。

これらの場合とは別に、rootができないことはほとんどありません。
ただし、（ユーザーモードではなく）カーネルモードと呼ばれるものがあります。

私の知る限り、健全なシステムでは、カーネル、カーネル拡張機能、ドライバーのみがカーネルモードで実行され、他のすべて（ルートとしてログインするシェルを含む）はユーザーモードで実行されます。
したがって、「rootになるだけでは十分ではない」と主張できます。ただし、ほとんどのシステムでは、rootユーザーはカーネルモジュールをロードできます。これは、カーネルモードで実行され、カーネルモードでコードを実行する方法をルートに効果的に提供します。

ただし、（iOSのように）少なくともセキュリティ全体を活用しない限り、これが（任意に）不可能なシステムがあります。これは主に、コード署名の強制などのセキュリティの向上によるものです。
たとえば、iDevicesのプロセッサに組み込まれたAES暗号化キーがあり、カーネルモードからのみアクセスできます。カーネルモジュールはそれらにアクセスできますが、カーネルがそれらを受け入れるためには、それらのカーネルモジュール内のコードもAppleによって署名される必要があります。

OS Xでは、バージョン10.11（El Capitan）以降、いわゆる「ルートレスモード」もあります（ルートがまだ存在するため、名前は誤解を招きますが）。AskDifferentのこの優れた答え
から引用：

ルートからであっても制限するものは次のとおりです。

• / System、/ bin、/ sbin、または/ usr（/ usr / localを除く）を変更することはできません。または組み込みのアプリとユーティリティのいずれか。これらの領域を変更できるのはインストーラーとソフトウェアの更新のみであり、Apple署名付きパッケージをインストールする場合にのみ変更できます。

あなたが言及している「システムコアの実行」は、root例えばロード可能なカーネルモジュールを介してなどの管理下にあります。もちろん、これはカーネルモジュールのロードがカーネルによってサポートされていることを前提としているため、実行不可能なアクションも実行できませんroot。

同じことがシステムプロセスにも当てはまります。rootは任意のプロセスを強制終了できますが、カーネルの整合性を損なうことなくカーネルモードで実行中のプロセスを停止することはできないため、そのような処理をすぐに停止することは不可能です。rootこれらのプロセスの強制終了は拒否されないことに注意してください。強制終了自体は効果がありません。

最後に、リアルモード：Linuxカーネルはそれをサポートしていないため、実行不可能なことはできませんroot。

@Siguzaは、x許可なしにファイルを実行することについて言及しましたroot。

/lib/ld-linux.so.2 /path/to/executable

1つの例としては、不変ファイルの変更があります。ファイル属性iを設定しchattrて、ルートに対してもファイルを不変にすることができます。例えば：

# whoami
root
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

ファイルは、ls -l出力では通常の書き込み可能ファイルとして表示されることに注意してください。

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

i属性を表示するには、次を使用する必要がありますlsattr。

# lsattr god
----i----------- god

chattrのマニュアルページには、i属性について次のように記載されています。

「i」属性を持つファイルは変更できません。削除または名前の変更はできません。このファイルへのリンクは作成できず、ファイルにデータを書き込むこともできません。この属性を設定またはクリアできるのは、スーパーユーザーまたはCAP_LINUX_IMMUTABLE機能を持つプロセスのみです。

ただし、rootは不変性を簡単に元に戻すことができます。

# chattr -i god
# rm -v god
removed ‘god’

FreeBSDでは、gmirrorルートとしても、既にマウントされているパーティションでは使用できません。

gmirror label -v -b prefer gm0s1 ad4s1
gmirror：ad4s1にメタデータを保存できません：操作は許可されていません。

それを行うには、sysctl（kern.geom.debugflags=16）を設定する必要があります。

rootは特権ユーザーですが、これらの権限はカーネルによって付与されます。そのため、カーネルには、より多くの特権がありrootます。

ルートユーザー自体からのコラボレーションを想定して、root（allow_otherまたはallow_rootオプションを使用して）FUSEマウントにアクセスできないようにすることができますが、これはFUSEがこのように動作するように設計されているためです。FUSEは仮想レイヤーに常駐するため、ロジックに基づいて好きなエラーを返すことができます。これは、可能な限り透明で薄くなるように努力し、別のレイヤーに権限を委任する一般的なブロックデバイスモジュールとは異なります。

これは、ファイルシステムを読み取り専用にしない限り、rootユーザーがオプションを無効にしたり、FUSEモジュールをオプションを静かに破棄するモジュールに置き換えたりすることを妨げません。ただし、これは「ウォッチメンを監視する」状況につながるだけです。システムが嘘をついていないことをどのように検証できますか？シェルは、正当なFUSEモジュールを表示するchrootに座っているかもしれませんが、カーネルは実際にその悪意のあるバージョンを実行しています。

非実行可能ファイルを実行できないことは、ファイルのアクセス許可に依存するため、些細な制限だと思います。（非実行ファイルの場合は/lib64/ld-linux-x86-64.so.2を使用してこれを回避できますが、非EXECマウントのファイルは使用できません）

また、必須ファイルロックの問題もあります。これは、ファイルが現在プロセスで使用されている場合、スーパーユーザーがプロセスを強制終了できる場合でも、ファイルの編集を妨げます。

ある時点で、スーパーユーザーはデバイスがビジー状態のときにデバイスをアンマウントできませんでしたが、これはレイジーアンマウントを使用して実行できるようになりました。

その他の制限は次のとおりです。

不変ファイルを変更することはできず、追加専用ファイルにのみ追加できます（Linuxでは、スーパーユーザーは任意の実行レベルで不変フラグと追加フラグのみを削除できますが、その目的を部分的に無効にします）

読み取り専用マウントに書き込むことも、no-execマウントで何かを実行することもできません

バインドできないマウントをバインドできません

ブロックデバイスが読み取り専用の場合、ファイルシステムを読み書き可能として再マウントできません

allow-otherまたはallow-rootがマウントされていない限り、別のユーザーが所有するヒューズマウントに何も追加できません。

SELinux設定に違反することはできません

ルートに影響するシステム自体に固有の意図的な制限：

ファイルのc-time（または実装されている場合は誕生時間）を直接設定することはできません

パスワードをプレーンテキストとして表示できません