On Mon, Jun 12, 2023 at 2:02 PM Djalal Harouni <tixxdz@xxxxxxxxx> wrote: > > On Sat, Jun 10, 2023 at 12:57 AM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > ... > > 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...
