On Mon, 2022-09-26 at 16:35 +0100, Lorenz Bauer wrote:
>
> On Fri, 23 Sep 2022, at 08:39, Roberto Sassu wrote:
> > > Yes please, I have also have a WIP patch that seems to work, but
> > > I'm
> > > curious what you came up with. Tests would also be great, mine
> > > are
> > > kinda janky.
> >
> > Ok.
>
> Hi Roberto,
>
> Did you get around to putting your patches somewhere?
>
> > If you have write access to /sys/fs/bpf/foo, it does not mean that
> > you
> > will have write access to the map, when you call OBJ_GET(). I don't
> > know if you could add more modes after getting a fd.
>
> Well, that's kind of how it works at the moment. Write on the file
> gives write on the FD, and BPF_F_RDONLY, etc. can be passed to
> OBJ_GET to change that. You're proposing to change that?
Could it be that file permissions and fd permissions from OBJ_GET() are
independent?
You could decide to ask for any permission with bpf_obj_get_opts(). By
default, it is read/write.
> > > Ok, you're saying that a user can prevent the escalation via
> > > SELinux?
> >
> > Not only with SELinux, but with an eBPF program too (BPF LSM). What
> > I
> > wanted to do is to deny write access to anyone except the eBPF
> > program
> > that declares the map.
>
> There is no "ownership" of a map as far as I can tell. How would you
> figure out which program declared the map?
At least in SELinux, the label of the map is the label of the process
creating it:
static int selinux_bpf_map_alloc(struct bpf_map *map)
{
[...]
bpfsec->sid = current_sid();
Accessing a map requires a rule allowing a subject to access maps with
that label.
> Maybe it's best not to focus on SELinux / LSM too much: this stuff
> should work correctly out of the box, without needing workarounds
> from the user.
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). DAC information should be rather added to the map object
itself.
> > I wrote an example here:
> >
> > https://lore.kernel.org/bpf/8d7a713e500b5e3fce93e4c5c7b8841eb6dd28e4.camel@xxxxxxxxxxxxxxx/
>
> That was very helpful. Yes, map iterators semantics are also broken,
> just like program fds and link fds. I started with maps since that
> seemed easier to tackle than everything all at once.
Great!
Roberto
