On Thu, 22 Sep 2022, at 16:39, Roberto Sassu wrote:
>
> Yes, true. Not sure if it makes sense to backport it to stable versions
> (probably not). Or alternatively, for older versions we could ensure
> that the fd is for read/write, even if as you said, there is a risk of
> breakage of existing applications. It seems unlikely that this could
> happen, as libbpf still does not support requesting a read-only fd,
> although one could create an ad-hoc function to set the appropriate
> parameters for the bpf() system call.
You can create a r-o fd via bpf_map_create if you pass map_flags=BPF_F_RDONLY unfortunately. Were you thinking of OBJ_GET when you refer to libbpf?
> Actually, if it may help, I could send my version of the fix I
> developed to validate the idea. I also wrote the tests.
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.
> The ability to access the path of a pinned map does not give you the
> ability to access the map itself.
I think there is a subtlety here I don't get. BPF_OBJ_GET(/sys/fs/bpf/foo) gives me an fd I can modify via syscall, no? Are you making a distinction between the inode and the bpf_map itself?
> You still need to pass
> security_bpf_map(). With SELinux, you would need a rule like:
>
> allow <ctx of subject accessing the pinned map> <ctx of the map
> creator>: bpf { map_read map_write };
>
> The inode is not passed to security_bpf_map(), so likely it is not
> taken into account for the security decision.
Ok, you're saying that a user can prevent the escalation via SELinux?
> What you say, I think it applies to map iterators. The ability to
> access the path of an iterator gives you the ability to make changes to
> the map without further checks.
How? An example would really help me, I don't know much about iterators besides that I can pin them and that open() triggers the program.
Lorenz
