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? >> 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? 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. > 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.
