Message ID | ZDWAcN6wfeXzipHz@gofer.mess.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2683513vqo; Tue, 11 Apr 2023 09:03:18 -0700 (PDT) X-Google-Smtp-Source: AKy350YArX82cA+K8BBTHOC18buo0LMAlXJVtk//sWbedbF0Gs8EM57EARNxi/2gyzsEK47dK4WZ X-Received: by 2002:a17:907:c21:b0:94d:de69:287b with SMTP id ga33-20020a1709070c2100b0094dde69287bmr5095270ejc.22.1681228997900; Tue, 11 Apr 2023 09:03:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681228997; cv=none; d=google.com; s=arc-20160816; b=OdCYyfEtv9PTm4K36fsFEuDz9oiRUwyXqOszCAgGZX7XOhW3/6PX9TxJVUBO25JWp1 gEKiPNN8hPAB4XamCVbnDOXvA3i/0jFWpEp1ea8+moiPSmpqK4kMQNYYGbhO+Xf7+qF/ ZHgANHpY60BljXvbbuTkP/x2zQn/Sj1ZHoUBlGnTLqnB1W4mM2ype+bAkyUvDX6xdqTu u+f0GnxQ9QsFwF/9GAlDDJDsKbeoO037/GzWgPlwuy6RvsZ9tBHkH4GHITafeR0eDZvz dyLDHPjvD41ncEICOl/Qrosib/EcZQn1UNxjfGwM4kO3wxL1C/gZ5MJNWJrU5YAVq+qn CyAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:to:from:date:dkim-signature; bh=Lna1JPwmiqnY2JDXr39zTylCAa38M098kz1ac1GWQVc=; b=HPY3idv0z9FhgFNA02Z6XpLftih95TPG4mLFa0tr653hcM4Y+IMLrSj312EZoMvg4/ s9PXUZomU27TmI5t0xbrHLeogjB1fnDvw/zYc5RoiEe/GKihp2pSpin2ScGlT/aBsx4K zrwCIN0t3PHHyML8TMthuVSEPOT2SLlIuH3WDY7MVuMXnhLc0fxpzjbVO82o575bJaGj skTKbHYjiv+KzzoRctIUd3bcrZUGpqvZk1u20PmR8IGi4ocAlqixcJQ8PSI6XdkHQqG1 lxIkDOJPoS2kYDYY/Msrko+86tWv8uXOYYZXjziF5mfTOY87uTevNbym3bFqWGGII+BL x3vA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mess.org header.s=2020 header.b=itG1vCno; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mess.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id vt3-20020a170907a60300b0094a460b5225si571197ejc.651.2023.04.11.09.02.52; Tue, 11 Apr 2023 09:03:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@mess.org header.s=2020 header.b=itG1vCno; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mess.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230050AbjDKPpA (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Tue, 11 Apr 2023 11:45:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229806AbjDKPoy (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 11 Apr 2023 11:44:54 -0400 Received: from gofer.mess.org (gofer.mess.org [88.97.38.141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F1AF3AAA; Tue, 11 Apr 2023 08:44:51 -0700 (PDT) Received: by gofer.mess.org (Postfix, from userid 1000) id DB2D710006C; Tue, 11 Apr 2023 16:44:48 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mess.org; s=2020; t=1681227888; bh=gJjMJGahaI4tDqMGSnFJtVV+yhLoA/zGWC6OQiONgNs=; h=Date:From:To:Subject:From; b=itG1vCnoNZM1cPwHzAQ/prPhh0o9FtCqjcBroB54pY88YIaACXthSNmc4aAlzDsbn mKLKdrbFbrmV7mOLUGPp5dqIXThEksK0JVCfaaewRSpFfn9v999gV7zjBnFPqMBGC6 /9EsJRam85qWDfBTmFgMTtE4HUaUuysWKI4DopmhYFJfh08vdFsWtFXej8W6PjfEqL aXP37EerC23NVpAUbc3fTLGXPYeunMiwjDqZkc73AKYyIbeGVI63F0Xc45Ril37gRI 9T78F+525ATztbGjyD3qnraZe9zhj/xXtALX9CixGcgryzX0oBgbrgM5tPxiMiZPvV pcJUiPK2a8GfA== Date: Tue, 11 Apr 2023 16:44:48 +0100 From: Sean Young <sean@mess.org> To: Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, John Fastabend <john.fastabend@gmail.com>, Andrii Nakryiko <andrii@kernel.org>, Martin KaFai Lau <martin.lau@linux.dev>, Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>, KP Singh <kpsingh@kernel.org>, Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org Subject: [PATCH] bpf: lirc program type should not require SYS_CAP_ADMIN Message-ID: <ZDWAcN6wfeXzipHz@gofer.mess.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762896377936213996?= X-GMAIL-MSGID: =?utf-8?q?1762896377936213996?= |
Series |
bpf: lirc program type should not require SYS_CAP_ADMIN
|
|
Commit Message
Sean Young
April 11, 2023, 3:44 p.m. UTC
Make it possible to load lirc program type with just CAP_BPF.
Signed-off-by: Sean Young <sean@mess.org>
---
kernel/bpf/syscall.c | 1 -
1 file changed, 1 deletion(-)
Comments
On Tue, Apr 11, 2023 at 8:45 AM Sean Young <sean@mess.org> wrote: > > Make it possible to load lirc program type with just CAP_BPF. Is it safe? If the user can load with just CAP_BPF the FD to the prog and target_fd will allow attach as well. > Signed-off-by: Sean Young <sean@mess.org> > --- > kernel/bpf/syscall.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > index adc83cb82f37..19d9265270b3 100644 > --- a/kernel/bpf/syscall.c > +++ b/kernel/bpf/syscall.c > @@ -2439,7 +2439,6 @@ static bool is_net_admin_prog_type(enum bpf_prog_type prog_type) > case BPF_PROG_TYPE_LWT_SEG6LOCAL: > case BPF_PROG_TYPE_SK_SKB: > case BPF_PROG_TYPE_SK_MSG: > - case BPF_PROG_TYPE_LIRC_MODE2: > case BPF_PROG_TYPE_FLOW_DISSECTOR: > case BPF_PROG_TYPE_CGROUP_DEVICE: > case BPF_PROG_TYPE_CGROUP_SOCK: > -- > 2.39.2 >
On Wed, Apr 12, 2023 at 04:14:05PM -0700, Alexei Starovoitov wrote: > On Tue, Apr 11, 2023 at 8:45 AM Sean Young <sean@mess.org> wrote: > > > > Make it possible to load lirc program type with just CAP_BPF. > > Is it safe? > If the user can load with just CAP_BPF the FD to the prog and target_fd > will allow attach as well. Exactly, that's the $1m question of course. I think it's safe from a lirc perspective because you need to be able to open the /dev/lirc0 device in the first place; if you can open it, you alter all sorts of lirc receiving options already. Changing the IR protocol decoder is no different in that perspective. The other side of course, is it save to load a bpf lirc program as a normal user. I don't see any issue with this; I guess this depends on whether the subset of functions in lirc_mode2_func_proto() is safe. I am hoping that the expert opinion everyone here can help answer that question. Thanks, Sean > > > > Signed-off-by: Sean Young <sean@mess.org> > > --- > > kernel/bpf/syscall.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > > index adc83cb82f37..19d9265270b3 100644 > > --- a/kernel/bpf/syscall.c > > +++ b/kernel/bpf/syscall.c > > @@ -2439,7 +2439,6 @@ static bool is_net_admin_prog_type(enum bpf_prog_type prog_type) > > case BPF_PROG_TYPE_LWT_SEG6LOCAL: > > case BPF_PROG_TYPE_SK_SKB: > > case BPF_PROG_TYPE_SK_MSG: > > - case BPF_PROG_TYPE_LIRC_MODE2: > > case BPF_PROG_TYPE_FLOW_DISSECTOR: > > case BPF_PROG_TYPE_CGROUP_DEVICE: > > case BPF_PROG_TYPE_CGROUP_SOCK: > > -- > > 2.39.2 > >
On Thu, Apr 13, 2023 at 1:28 AM Sean Young <sean@mess.org> wrote: > > On Wed, Apr 12, 2023 at 04:14:05PM -0700, Alexei Starovoitov wrote: > > On Tue, Apr 11, 2023 at 8:45 AM Sean Young <sean@mess.org> wrote: > > > > > > Make it possible to load lirc program type with just CAP_BPF. > > > > Is it safe? > > If the user can load with just CAP_BPF the FD to the prog and target_fd > > will allow attach as well. > > Exactly, that's the $1m question of course. > > I think it's safe from a lirc perspective because you need to be able to > open the /dev/lirc0 device in the first place; if you can open it, you > alter all sorts of lirc receiving options already. Changing the IR protocol > decoder is no different in that perspective. > > The other side of course, is it save to load a bpf lirc program as a normal > user. I don't see any issue with this; I guess this depends on whether the > subset of functions in lirc_mode2_func_proto() is safe. I am hoping that > the expert opinion everyone here can help answer that question. That part is fine under CAP_BPF. I don't know how lirc devices are typically setup. If they need root to open them then why bother relaxing bpf loading part?
On Thu, Apr 13, 2023 at 04:54:21PM -0700, Alexei Starovoitov wrote: > On Thu, Apr 13, 2023 at 1:28 AM Sean Young <sean@mess.org> wrote: > > > > On Wed, Apr 12, 2023 at 04:14:05PM -0700, Alexei Starovoitov wrote: > > > On Tue, Apr 11, 2023 at 8:45 AM Sean Young <sean@mess.org> wrote: > > > > > > > > Make it possible to load lirc program type with just CAP_BPF. > > > > > > Is it safe? > > > If the user can load with just CAP_BPF the FD to the prog and target_fd > > > will allow attach as well. > > > > Exactly, that's the $1m question of course. > > > > I think it's safe from a lirc perspective because you need to be able to > > open the /dev/lirc0 device in the first place; if you can open it, you > > alter all sorts of lirc receiving options already. Changing the IR protocol > > decoder is no different in that perspective. > > > > The other side of course, is it save to load a bpf lirc program as a normal > > user. I don't see any issue with this; I guess this depends on whether the > > subset of functions in lirc_mode2_func_proto() is safe. I am hoping that > > the expert opinion everyone here can help answer that question. > > That part is fine under CAP_BPF. > I don't know how lirc devices are typically setup. > If they need root to open them > then why bother relaxing bpf loading part? I'd like to get a point where /dev/lircN can have the same permissions as for example /dev/videoN devices: group read/write, so that local users don't have to become root to use them. Without relaxing the bpf side, this seems like a chicken and egg problem (tiktaalik and egg?). Also - the CAP_NET_ADMIN requirement seems completely arbitrary compared to other program types. Sean
On Fri, Apr 14, 2023 at 3:58 AM Sean Young <sean@mess.org> wrote: > > On Thu, Apr 13, 2023 at 04:54:21PM -0700, Alexei Starovoitov wrote: > > On Thu, Apr 13, 2023 at 1:28 AM Sean Young <sean@mess.org> wrote: > > > > > > On Wed, Apr 12, 2023 at 04:14:05PM -0700, Alexei Starovoitov wrote: > > > > On Tue, Apr 11, 2023 at 8:45 AM Sean Young <sean@mess.org> wrote: > > > > > > > > > > Make it possible to load lirc program type with just CAP_BPF. > > > > > > > > Is it safe? > > > > If the user can load with just CAP_BPF the FD to the prog and target_fd > > > > will allow attach as well. > > > > > > Exactly, that's the $1m question of course. > > > > > > I think it's safe from a lirc perspective because you need to be able to > > > open the /dev/lirc0 device in the first place; if you can open it, you > > > alter all sorts of lirc receiving options already. Changing the IR protocol > > > decoder is no different in that perspective. > > > > > > The other side of course, is it save to load a bpf lirc program as a normal > > > user. I don't see any issue with this; I guess this depends on whether the > > > subset of functions in lirc_mode2_func_proto() is safe. I am hoping that > > > the expert opinion everyone here can help answer that question. > > > > That part is fine under CAP_BPF. > > I don't know how lirc devices are typically setup. > > If they need root to open them > > then why bother relaxing bpf loading part? > > I'd like to get a point where /dev/lircN can have the same permissions as > for example /dev/videoN devices: group read/write, so that local users > don't have to become root to use them. > > Without relaxing the bpf side, this seems like a chicken and egg problem > (tiktaalik and egg?). > > Also - the CAP_NET_ADMIN requirement seems completely arbitrary compared > to other program types. Yeah. Agree. Could you respin with all these additional details explaining the motivation and driver permission model?
On Fri, Apr 14, 2023 at 08:39:13AM -0700, Alexei Starovoitov wrote: > Yeah. Agree. Could you respin with all these additional details > explaining the motivation and driver permission model? Thanks, will do. The commit message was way too short. Sean
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index adc83cb82f37..19d9265270b3 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -2439,7 +2439,6 @@ static bool is_net_admin_prog_type(enum bpf_prog_type prog_type) case BPF_PROG_TYPE_LWT_SEG6LOCAL: case BPF_PROG_TYPE_SK_SKB: case BPF_PROG_TYPE_SK_MSG: - case BPF_PROG_TYPE_LIRC_MODE2: case BPF_PROG_TYPE_FLOW_DISSECTOR: case BPF_PROG_TYPE_CGROUP_DEVICE: case BPF_PROG_TYPE_CGROUP_SOCK: