setuidファイル「+p」機能なしで、一般にPR_SET_NO_NEW_PRIVSを設定したときに無効になるものなしでシステムを使用できるようにしたい。
このアプローチ（initセットPR_SET_NO_NEW_PRIVSおよびファイルシステムベースの機能の昇格は不可能）では、機能を「補充」することはできず、機能を「飛び散らせ」ないように注意する必要があるだけです。
execve付与された機能を「飛び散らせる」ことなく（新しいプログラムのファイルがである場合など）、他のプロセスを実行するにはどうすればよいですsetcap =eiか？「私は自分自身を信頼するので、この新しいプロセスを信頼します」。たとえば、機能がユーザーに与えられます（そして、ユーザーは自分が開始する任意のプログラムでそれを実行したいと考えています）...
ファイルシステム全体を永続的に作成できます=eiか？ファイルシステムがスキームに干渉しないようにし、機能を付与または取り消すことができないようにしたい。親->子のものを通してすべてを制御します。
機能のマニュアルページを参照する場合、現在、これを行う簡単な方法はありません。
During an execve(2), the kernel calculates the new capabilities of the process
using the following algorithm:
P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & cap_bset)
P'(effective) = F(effective) ? P'(permitted) : 0
P'(inheritable) = P(inheritable) [i.e., unchanged]
where:
P denotes the value of a thread capability set before the execve(2)
P' denotes the value of a capability set after the execve(2)
F denotes a file capability set
cap_bset is the value of the capability bounding set
実行するファイルにfPビットが設定されていない場合、またはfIビットが設定されていない場合、プロセスには許可されていないため、有効な機能がありません。
ファイルシステム全体を許可して継承ビットを設定することは技術的には可能ですが、システムのセキュリティが大幅に低下するため、あまり意味がありません（編集：そしてあなたが言ったように、それは新しい実行可能ファイルでは機能しません）。
確かに、pam_capを使用してユーザーにいくつかの機能を提供することはできますが、それを使用してコンパイルしたばかりのファイルをユーザーに実行させることはできません。機能は、ユーザーではなくプログラムに電力を与えるように設計されたものであり、 Hallynの論文で読むことができます。
重要な洞察は、人ではなくプログラムが特権を行使するという観察です。つまり、コンピューターで行われることはすべてエージェント（プログラム）を介して行われ、これらのプログラムが特権をどう処理するかを知っている場合にのみ、特権を使用することを信頼できます。
POSIX機能を定義するPOSIXドラフト1003.1e、310ページも参照してください。
また、プロセスチェーン（単一のプロセス内の一連のプログラム）に対して、そのチェーンの存続期間を通じて固定され、アクティブなままである一連の機能を確立することも適切ではありません。[...]これは最小特権の原則の適用であり、ユーザーとプロセスに等しく適用されます。
最近（2012年12月）このLinuxカーネルメーリングリストの機能として何をしたいのかを紹介するように言われましたが、非常に興味深い回答がいくつかあります。一部の人々は、継承ルールにファイル機能をドロップするとexecセキュリティ上の問題が発生し、どのセキュリティ問題が発生するかについての説明がない場合でも、その機能はそのような機能用に設計されていないと主張します。
現在それを行う唯一の方法は、Linuxカーネルで機能が継承される方法を変更することです（変更する2つのファイル、3.7カーネルで正常にテストしました）が、上記のようにそれが保護されているかどうかは明らかではありません。
古いカーネル（2.6.33より前）では、ファイルの機能なしでコンパイルするオプションがありましたが（CONFIG_SECURITY_FILE_CAPABILITIES）、そのような古いカーネルで作業することはあなたにとってのオプションではないかと思います。
私はあなたがしていることにこれをお勧めすると言っているのではありませんが、ここにあります。
マニュアルから抜粋、いくつかの変更があります。それによると：fork機能を変更しません。そして今、Linuxカーネル4.3にアンビエントセットが追加されています。これはあなたがやろうとしていることのためのようです。
Ambient (since Linux 4.3):
This is a set of capabilities that are preserved across an execve(2) of a program that is not privileged. The ambient capability set obeys the invariant that no capability can ever
be ambient if it is not both permitted and inheritable.
The ambient capability set can be directly modified using
prctl(2). Ambient capabilities are automatically lowered if
either of the corresponding permitted or inheritable
capabilities is lowered.
Executing a program that changes UID or GID due to the set-
user-ID or set-group-ID bits or executing a program that has
any file capabilities set will clear the ambient set. Ambient
capabilities are added to the permitted set and assigned to
the effective set when execve(2) is called.
A child created via fork(2) inherits copies of its parent's
capability sets. See below for a discussion of the treatment of
capabilities during execve(2).
Transformation of capabilities during execve()
During an execve(2), the kernel calculates the new capabilities of
the process using the following algorithm:
P'(ambient) = (file is privileged) ? 0 : P(ambient)
P'(permitted) = (P(inheritable) & F(inheritable)) |
(F(permitted) & cap_bset) | P'(ambient)
P'(effective) = F(effective) ? P'(permitted) : P'(ambient)
P'(inheritable) = P(inheritable) [i.e., unchanged]
where:
P denotes the value of a thread capability set before the
execve(2)
P' denotes the value of a thread capability set after the
execve(2)
F denotes a file capability set
cap_bset is the value of the capability bounding set (described
below).
A privileged file is one that has capabilities or has the set-user-ID
or set-group-ID bit set.
私は（私の理解では）、機能を使用する最良の方法は次のとおりだと思います。
chmodset inherit CAP_FOWNERの場合、ユーザーがスーパーパワー（通常はrootによって保持されるもの）を必要とする場合は、使用する必要がありますsetpriv（または同等のもの、これはロールインできますsudo）。それ以外の場合は、非特権モードで動作します。アンビエントの使用：