Re: [PATCH v2 bpf-next 00/18] BPF token
From: Djalal Harouni <hidden>
Date: 2023-06-12 14:32:55
Also in:
bpf
On Mon, Jun 12, 2023 at 2:02 PM Djalal Harouni [off-list ref] wrote:
On Sat, Jun 10, 2023 at 12:57 AM Andrii Nakryiko [off-list ref] wrote:quoted
...
quoted
I'm not sure I understand the question. Unix domain socket (specifically its SCM_RIGHTS ancillary message) allows to transfer files between processes, which is one way to pass BPF object (like prog/map/link, and now token). BPF FS is the other one. In practice it's usually BPF FS, but there is no presumption about how file reference is transferred.Got it. IIRC SCM_RIGHTS and SCM_CREDENTIALS are translated into the receiving userns, no ? I assume such which allows to set up things in a hierarchical way... If I set up the environment to lock things down the line, I find it strange if a received fd would allow me to do more things than what was planned when I created the environment: namespaces, mounts, etc I think you have to add the owning userns context to the fd or "token", and on the receiving part if the current userns is the same or a nested one of the current userns hierarchy then allow bpf operation, otherwise fail with -EACCESS or something similar...
Andrii to make it clear: the owning userns that is owner/creator of the bpffs mount (better this one since you prevent the inherit fd and do bad things with it cases...) lets call it userns A, and the receiving process is in userns B, so when transfering the fd if userns B == userns A or if A is an ancestor of B then allow to do things with fd token, otherwise just deny it... At least that's how I see things now, but maybe there are corner cases...