From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BFA091877 for ; Thu, 13 Jun 2024 20:55:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718312114; cv=none; b=q76NelsKRhcfBZbbHl5PLKFQWss7KXjrwCUf97Yvj5xN7auwdyBb4u3vl0YC+AUw7q99UoLSItUfOLlCYQDhWPYNv2atbhz7YrLloeOMZc6kRxeQl6NdHd96b1aEK443qi1d/reGshUOdt9uleZyqRmqmeC5yw04huiV0AWJkyM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718312114; c=relaxed/simple; bh=l5BZRVe4EjUxYN3yXF5F7zfYiMw/7+iKLgPHpiV/pbM=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=VZFqASrTGggz982qhp2IEM6cnEuXYtR3JFmm8RYrMjmoO/cvc0Kkr8qrJfM2fS6i+3Vg3iJvNloOAdxugxxfeDIr+KPIyOZFQpX2Fp1wnk8OTAuke3NbA6GDGvipvjyZEpXIIoOlNZzvh6mUyuyIi1iHjwTXDKFCkmOv68ZINRI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=paul-moore.com; spf=pass smtp.mailfrom=paul-moore.com; dkim=pass (2048-bit key) header.d=paul-moore.com header.i=@paul-moore.com header.b=LY4ASSj5; arc=none smtp.client-ip=209.85.128.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=paul-moore.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=paul-moore.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=paul-moore.com header.i=@paul-moore.com header.b="LY4ASSj5" Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-63152a07830so10688447b3.3 for ; Thu, 13 Jun 2024 13:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1718312112; x=1718916912; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mcXAwgD8G/DtMBTj2XjZiXsT2OTNX1kHEG3gcoNV7As=; b=LY4ASSj5sD1R9fmYZn5gSBdQcVKzA/Abv6SD3GZehE/Wn/sDSFoAp1R/vhdCDnwbf+ b83ZV/RHzrYz32yqmtZQVOwlbNCk5jFSSY8Ik3l/S3j10VNT7tVhSg7az9C8eBWBFjdy j2PuEv2yLn903jg6kZp4KtNTlc5UaM4pK+W38Sx7a9auud2uZ5LoWNHqLqacnv8dYGrW xRALKPOwEPfpDwZ5tuXLIxYXsGseEFUbyVIVyPZpZ90SbdwdV6aaDp/xx0S+06fJ6bbx WBaG+a7x50apV2PFHdkYt6I9t/ZZGrkI6JfBLa14L/dhPQ/Y7UR4OpHbRhwRJkSnhMEb p5MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718312112; x=1718916912; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mcXAwgD8G/DtMBTj2XjZiXsT2OTNX1kHEG3gcoNV7As=; b=MWW1I0gRVWJ0m/aHTfWwsiScrIzW+vDE2h+r31HhatCoqrHaEPHJgQ9IWCNHslv2EE YkV3FoglrpXf+TgSPdMvm1i/pPEgPv1SY0TRxX/Fr9SaU/tE/lVQQGz6dPYWNFXMo6On E0eScko7RjYUfdP5wmSmll8B9b6sDCih/nJ96cICv6En+yDEa5LiYpBFNKXNETc/X8Z2 1PqISeJq5wiOkx8QwJfb5iheWlk1f35dwJm6whKiTCdNUh2UctyhoodIDIoZb7yi8IDA fHhD4DGGfg1NoxrExhJwdOwvtss6BJMuMXHU62ytQUZA31lNXj4R8FI1dHs3n40C6DcC hOHA== X-Forwarded-Encrypted: i=1; AJvYcCUA0FOgXhIFulDPArVz3iyWUTO+eCFzZRLlroaUfl+QdRzpkSQXUkWi8ZhAWf9zdsZXJPw0p/Co5s+yn1NN6LvfcRhyMLO5bFQYIVtHOGnEscb4Gf5W X-Gm-Message-State: AOJu0YxQH1AoR0xtoIoPuE6q343e9YGCSUPXJWTLoKcdaz1Alx9PCU7t VC5tAbOB15oYdn7QQ9DHReuoXa5BPKKk4qQwo9ZkOClTSBz3aUNGKcK7nZ+IWZRIYEhjiMpgmFw ecOGrkZvfcNDQIpknR8jDzbs6w8dSgaCx0qpu X-Google-Smtp-Source: AGHT+IGDrzqvYL8x8To8WRZC5EK4ZE7eYh19cN6eIrPp+Dp9L8DQSAkqnp5RVfEyty6oWnZormmtfNXBsvqkuSccnaA= X-Received: by 2002:a81:910f:0:b0:62f:ad9c:cd4 with SMTP id 00721157ae682-6322470facfmr6187707b3.41.1718312111715; Thu, 13 Jun 2024 13:55:11 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240609104355.442002-5-jcalmels@3xx0.net> <887a3658-2d8d-4f9e-98f2-27124bb6f8e6@canonical.com> In-Reply-To: From: Paul Moore Date: Thu, 13 Jun 2024 16:55:00 -0400 Message-ID: Subject: Re: [PATCH v2 4/4] bpf,lsm: Allow editing capabilities in BPF-LSM hooks To: Jonathan Calmels Cc: John Johansen , brauner@kernel.org, ebiederm@xmission.com, Jonathan Corbet , James Morris , "Serge E. Hallyn" , KP Singh , Matt Bobrowski , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , Stanislav Fomichev , Hao Luo , Jiri Olsa , Luis Chamberlain , Kees Cook , Joel Granados , David Howells , Jarkko Sakkinen , Stephen Smalley , Ondrej Mosnacek , Mykola Lysenko , Shuah Khan , containers@lists.linux.dev, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-security-module@vger.kernel.org, bpf@vger.kernel.org, apparmor@lists.ubuntu.com, keyrings@vger.kernel.org, selinux@vger.kernel.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 13, 2024 at 4:45=E2=80=AFAM Jonathan Calmels wrote: > On Wed, Jun 12, 2024 at 08:54:28PM GMT, John Johansen wrote: > > On 6/12/24 10:29, Paul Moore wrote: > > > On Wed, Jun 12, 2024 at 4:15=E2=80=AFAM Jonathan Calmels wrote: > > > > On Tue, Jun 11, 2024 at 06:38:31PM GMT, Paul Moore wrote: > > > > > On Tue, Jun 11, 2024 at 6:15=E2=80=AFPM Jonathan Calmels wrote: > > > > > > ... > > > > > > > > > Arguably, if we do want fine-grained userns policies, we need L= SMs to > > > > > > influence the userns capset at some point. > > > > > > > > > > One could always use, or develop, a LSM that offers additional > > > > > controls around exercising capabilities. There are currently fou= r > > > > > in-tree LSMs, including the capabilities LSM, which supply a > > > > > security_capable() hook that is used by the capability-based acce= ss > > > > > controls in the kernel; all of these hook implementations work > > > > > together within the LSM framework and provide an additional level= of > > > > > control/granularity beyond the existing capabilities. > > > > > > > > Right, but the idea was to have a simple and easy way to reuse/trig= ger > > > > as much of the commoncap one as possible from BPF. If we're saying = we > > > > need to reimplement and/or use a whole new framework, then there is > > > > little value. > > > > > > I can appreciate how allowing direct manipulation of capability bits > > > from a BPF LSM looks attractive, but my hope is that our discussion > > > here revealed that as you look deeper into making it work there are a > > > number of pitfalls which prevent this from being a safe option for > > > generalized systems. > > > > > > > TBH, I don't feel strongly about this, which is why it is absent fr= om > > > > v1. However, as John pointed out, we should at least be able to mod= ify > > > > the blob if we want flexible userns caps policies down the road. > > > > > > As discussed in this thread, there are existing ways to provide fine > > > grained control over exercising capabilities that can be safely used > > > within the LSM framework. I don't want to speak to what John is > > > envisioning, but he should be aware of these mechanisms, and if I > > > recall he did voice a level of concern about the same worries I > > > mentioned. > > > > > > > sorry, I should have been more clear. I envision LSMs being able to > > update their own state in the userns hook. > > > > Basically the portion of the patch that removes const from the > > userns hook. > > Yes, pretty sure we'll need this regardless. > > > An LSM updating the capset is worrysome for all the reasons you > > pointed out, and I think a few more. I haven't had a chance to really > > look at v2 yet, so I didn't want to speak directly on the bpf part of > > the patch without first giving a good once over. > > > I'm happy to discuss ways in which we can adjust the LSM hooks/layer > > > to support different approaches to capability controls, but one LSM > > > directly manipulating the state of another is going to be a no vote > > > from me. > > > > I might not be as hard no as Paul here, I am always willing to listen > > to arguments, but it would have to be a really good argument to > > modify the capset, when there are multiple LSMs in play on a system. > > The way I see it, it's more about enhancing the capability LSM with BPF > hooks and have it modify its own state dynamically, not so much > crosstalk between two distinct LSM frameworks (say one where the BPF > LSM implements a lot of things like capable()). As I mentioned previously, if you want to do something with the capability sets you simply need to do it within the confines of security/commoncap.c. If you're really set on the "MUST BE BPF!" way of life, and you can convince Serge (capabilities maintainer) that it would be a good idea, you could propose a dedicated BPF hook within the capabilities LSM. I'm not sure how wise that would be, but it would resolve a lot of the LSM ordering/stacking issues that we've discussed. > If we think there is no way we can come up with something that's safe > enough, and that the risks outweigh the benefits, fine by me, we can > drop this patch from the series. To be clear, this patch is not acceptable at this point in time. With the understanding that I haven't looked that closely at the rest of the patchset, it looks fairly well contained to the capabilities code which means it is largely up to Serge, not me. I will mention that you should update the audit code to recognize the new capability set, look at kernel/auditsc.c for more information. --=20 paul-moore.com