On Mon, Sep 26, 2022 at 8:41 AM Lorenz Bauer <oss@xxxxxx> wrote: > > On Fri, 23 Sep 2022, at 00:21, Hao Luo wrote: [...] > > > 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. Yes, that's what I mean. > 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. I actually think the problem is at OBJ_GET. I feel OBJ_GET is too permissive, which can turn any pinned object into rw object. I see what you meant by refusing !rw pin being more user-friendly. It makes sense. We don't yet know how the introspection of bpf_perm will look like. But on the other hand, I think introducing bpf_perm opens up more potential use cases, because one can pin read-only objects and allow others to get the object with less permissions. This is not possible if refusing !rw pin in the first place. I don't have strong opinions on the solution of this problem. Refusing !rw pin is a simple solution, we can go for it and see how it works. Thanks Lorenz for the ideas and discussions, let me know if there is anything I can help with, this is interesting. :) Hao
