[PATCH bpf-next 0/8] New BPF map and BTF security LSM hooks

Casey Schaufler casey at schaufler-ca.com
Tue Apr 18 00:52:02 UTC 2023


On 4/17/2023 5:28 PM, Andrii Nakryiko wrote:
> On Mon, Apr 17, 2023 at 4:53 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>> ...
>>
>> The BPF developers are in complete control of what CAP_BPF controls.
>> You can easily address the granularity issue by adding addition restrictions
>> on processes that have CAP_BPF. That is the intended use of LSM.
>> The whole point of having multiple capabilities is so that you can
>> grant just those that are required by the system security policy, and
>> do so safely. That leads to differences of opinion regarding the definition
>> of the system security policy. BPF chose to set itself up as an element
>> of security policy (you need CAP_BPF) rather than define elements such that
>> existing capabilities (CAP_FOWNER, CAP_KILL, CAP_MAC_OVERRIDE, ...) would
>> control.
>>> Please see my reply to Paul, where I explain CAP_BPF's system-wide
>>> nature and problem with user namespaces. I don't think the problem is
>>> in the granularity of CAP_BPF, it's more of a "non-namespaceable"
>>> nature of the BPF subsystem in general.
>> Paul is approaching this from a different angle. Your response to Paul
>> does not address the issue I have raised.
> I see, I definitely missed this. Re-reading your reply, I still am not
> clear on what you are proposing, tbh. Can you please elaborate what
> you have in mind?

As requested, I've moved over to the "other" thread.



More information about the Linux-security-module-archive mailing list