On Fri, 23 Sep 2022, at 00:21, Hao Luo wrote: > For this problem, I'm thinking of a fix purely in the verifier: > passing along the file permission up to the site where the map is > used. > > For maps that are not passed from outside, this permission is rw by default. > > For maps that are obtained from fdget(), we can do the following: > > - associate the env->used_maps with an array of permissions. > - then extend bpf_reg_state and bpf_call_arg_meta to include the > permission information. > - then in record_func_map(), we can reject the program if the > permission doesn't allow the map operation. > > Not the simplest solution, but this is the first solution that comes > up in my head. That's roughly what I have as well! > For an idea mentioned in the summary, > >> In OBJ_GET, refuse a read-write fd if the fd passed to OBJ_PIN wasn't read-write. > > This sounds reasonable to me. Can we extend the object type referenced > by inode to include the permission? You're saying, add a layer of indirection? Instead of inode => bpf_map we have something like inode => bpf_perm => bpf_map. I think this is less user friendly than refusing !rw pin, since we decouple what you can do with a pinned file from the state that is observable via ls. Put another way, there should be a way to introspect bpf_perm if we end up going this way. I also think that this tries to plug the hole in the wrong place: it's not the caller of OBJ_GET that is escalating privs, is OBJ_PIN.
