Re: Closing the BPF map permission loophole

[Roberto Sassu <roberto.sassu@huaweicloud.com>]

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