Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> writes: > 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()). As someone pointed out during the discussing at LPC, this will effectively allow a user to create files owned by someone else, which is probably not a good idea either from a security PoV. (I.e., user A pins map owned by user B, so A creates a file owned by B). -Toke
