On Wed, 2022-09-28 at 09:52 +0100, Lorenz Bauer wrote: > On Mon, 26 Sep 2022, at 17:18, Roberto Sassu wrote: > > Uhm, if I get what you mean, you would like to add DAC controls to > > the > > pinned map to decide if you can get a fd and with which modes. > > > > The problem I see is that a map exists regardless of the pinned > > path > > (just by ID). > > Can you spell this out for me? I imagine you're talking about > MAP_GET_FD_BY_ID, but that is CAP_SYS_ADMIN only, right? Not great > maybe, but no gaping hole IMO. +linux-security-module ML (they could be interested in this topic as well) Good to know! I didn't realize it before. I figured out better what you mean by escalating privileges. Pin a read-only fd, get a read-write fd from the pinned path. What you want to do is, if I pin a read-only fd, I should get read-only fds too, right? I think here there could be different views. From my perspective, pinning is just creating a new link to an existing object. Accessing the link does not imply being able to access the object itself (the same happens for files). I understand what you want to achieve. If I have to choose a solution, that would be doing something similar to files, i.e. add owner and mode information to the bpf_map structure (m_uid, m_gid, m_mode). We could add the MAP_CHMOD and MAP_CHOWN operations to the bpf() system call to modify the new fields. When you pin the map, the inode will get the owner and mode from bpf_map. bpf_obj_get() will then do DAC-style verification similar to MAC-style verification (with security_bpf_map()). Roberto
