| Message ID | 20210326160501.46234-1-lmb@cloudflare.com |
|---|---|
| State | New |
| Headers | show |
| Series | [bpf,v2,1/2] bpf: link: refuse non-O_RDWR flags in BPF_OBJ_GET | expand |
On Fri, Mar 26, 2021 at 9:05 AM Lorenz Bauer <lmb@cloudflare.com> wrote: > > Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access > permissions based on file_flags, but the returned fd ignores flags. > This means that any user can acquire a "read-write" fd for a pinned > link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in > file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc. > > Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works > because OBJ_GET by default returns a read write mapping and libbpf > doesn't expose a way to override this behaviour for programs > and links. > > Fixes: 70ed506c3bbc ("bpf: Introduce pinnable bpf_link abstraction") > Signed-off-by: Lorenz Bauer <lmb@cloudflare.com> > --- LGTM. Acked-by: Andrii Nakryiko <andrii@kernel.org> > kernel/bpf/inode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c > index 1576ff331ee4..dc56237d6960 100644 > --- a/kernel/bpf/inode.c > +++ b/kernel/bpf/inode.c > @@ -547,7 +547,7 @@ int bpf_obj_get_user(const char __user *pathname, int flags) > else if (type == BPF_TYPE_MAP) > ret = bpf_map_new_fd(raw, f_flags); > else if (type == BPF_TYPE_LINK) > - ret = bpf_link_new_fd(raw); > + ret = (f_flags != O_RDWR) ? -EINVAL : bpf_link_new_fd(raw); > else > return -ENOENT; > > -- > 2.27.0 >
On Fri, 26 Mar 2021 at 16:05, Lorenz Bauer <lmb@cloudflare.com> wrote: > > Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access > permissions based on file_flags, but the returned fd ignores flags. > This means that any user can acquire a "read-write" fd for a pinned > link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in > file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc. > > Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works > because OBJ_GET by default returns a read write mapping and libbpf > doesn't expose a way to override this behaviour for programs > and links. Hi Alexei and Daniel, I think these two patches might have fallen through the cracks, could you take a look? I'm not sure what the etiquette is around bumping a set, so please let me know if you'd prefer me to send the patches with acks included or something like that. Best -- Lorenz Bauer | Systems Engineer 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK www.cloudflare.com
On Wed, Mar 31, 2021 at 7:04 AM Lorenz Bauer <lmb@cloudflare.com> wrote: > > On Fri, 26 Mar 2021 at 16:05, Lorenz Bauer <lmb@cloudflare.com> wrote: > > > > Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access > > permissions based on file_flags, but the returned fd ignores flags. > > This means that any user can acquire a "read-write" fd for a pinned > > link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in > > file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc. > > > > Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works > > because OBJ_GET by default returns a read write mapping and libbpf > > doesn't expose a way to override this behaviour for programs > > and links. > > Hi Alexei and Daniel, > > I think these two patches might have fallen through the cracks, could > you take a look? I'm not sure what the etiquette is around bumping a > set, so please let me know if you'd prefer me to send the patches with > acks included or something like that. It is still in patchworks. I didn't have time to think it through. Sorry for delay.
On Wed, Mar 31, 2021 at 7:04 AM Lorenz Bauer <lmb@cloudflare.com> wrote: > > On Fri, 26 Mar 2021 at 16:05, Lorenz Bauer <lmb@cloudflare.com> wrote: > > > > Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access > > permissions based on file_flags, but the returned fd ignores flags. > > This means that any user can acquire a "read-write" fd for a pinned > > link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in > > file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc. > > > > Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works > > because OBJ_GET by default returns a read write mapping and libbpf > > doesn't expose a way to override this behaviour for programs > > and links. > > Hi Alexei and Daniel, > > I think these two patches might have fallen through the cracks, could > you take a look? I'm not sure what the etiquette is around bumping a > set, so please let me know if you'd prefer me to send the patches with > acks included or something like that. Applied both. Thanks
diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c index 1576ff331ee4..dc56237d6960 100644 --- a/kernel/bpf/inode.c +++ b/kernel/bpf/inode.c @@ -547,7 +547,7 @@ int bpf_obj_get_user(const char __user *pathname, int flags) else if (type == BPF_TYPE_MAP) ret = bpf_map_new_fd(raw, f_flags); else if (type == BPF_TYPE_LINK) - ret = bpf_link_new_fd(raw); + ret = (f_flags != O_RDWR) ? -EINVAL : bpf_link_new_fd(raw); else return -ENOENT;
Invoking BPF_OBJ_GET on a pinned bpf_link checks the path access permissions based on file_flags, but the returned fd ignores flags. This means that any user can acquire a "read-write" fd for a pinned link with mode 0664 by invoking BPF_OBJ_GET with BPF_F_RDONLY in file_flags. The fd can be used to invoke BPF_LINK_DETACH, etc. Fix this by refusing non-O_RDWR flags in BPF_OBJ_GET. This works because OBJ_GET by default returns a read write mapping and libbpf doesn't expose a way to override this behaviour for programs and links. Fixes: 70ed506c3bbc ("bpf: Introduce pinnable bpf_link abstraction") Signed-off-by: Lorenz Bauer <lmb@cloudflare.com> --- kernel/bpf/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)