linux-kernel - Re: [PATCH v2 4/4] bpf,lsm: Allow editing capabilities in BPF-LSM hooks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 11 Jun 2024 03:31:59 -0700
From: John Johansen <john.johansen@...onical.com>
To: Jonathan Calmels <jcalmels@...0.net>, Paul Moore <paul@...l-moore.com>
Cc: brauner@...nel.org, ebiederm@...ssion.com,
 Jonathan Corbet <corbet@....net>, James Morris <jmorris@...ei.org>,
 "Serge E. Hallyn" <serge@...lyn.com>, KP Singh <kpsingh@...nel.org>,
 Matt Bobrowski <mattbobrowski@...gle.com>,
 Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
 <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>,
 Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
 John Fastabend <john.fastabend@...il.com>,
 Stanislav Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>, Luis Chamberlain <mcgrof@...nel.org>,
 Kees Cook <kees@...nel.org>, Joel Granados <j.granados@...sung.com>,
 David Howells <dhowells@...hat.com>, Jarkko Sakkinen <jarkko@...nel.org>,
 Stephen Smalley <stephen.smalley.work@...il.com>,
 Ondrej Mosnacek <omosnace@...hat.com>, Mykola Lysenko <mykolal@...com>,
 Shuah Khan <shuah@...nel.org>, containers@...ts.linux.dev,
 linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-security-module@...r.kernel.org,
 bpf@...r.kernel.org, apparmor@...ts.ubuntu.com, keyrings@...r.kernel.org,
 selinux@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v2 4/4] bpf,lsm: Allow editing capabilities in BPF-LSM
 hooks

On 6/11/24 01:09, Jonathan Calmels wrote:
> On Sun, Jun 09, 2024 at 08:18:48PM GMT, Paul Moore wrote:
>> On Sun, Jun 9, 2024 at 6:40 AM Jonathan Calmels <jcalmels@...0.net> wrote:
>>>
>>> This patch allows modifying the various capabilities of the struct cred
>>> in BPF-LSM hooks. More specifically, the userns_create hook called
>>> prior to creating a new user namespace.
>>>
>>> With the introduction of userns capabilities, this effectively provides
>>> a simple way for LSMs to control the capabilities granted to a user
>>> namespace and all its descendants.
>>>
>>> Update the selftests accordingly by dropping CAP_SYS_ADMIN in
>>> namespaces and checking the resulting task's bounding set.
>>>
>>> Signed-off-by: Jonathan Calmels <jcalmels@...0.net>
>>> ---
>>>   include/linux/lsm_hook_defs.h                 |  2 +-
>>>   include/linux/security.h                      |  4 +-
>>>   kernel/bpf/bpf_lsm.c                          | 55 +++++++++++++++++++
>>>   security/apparmor/lsm.c                       |  2 +-
>>>   security/security.c                           |  6 +-
>>>   security/selinux/hooks.c                      |  2 +-
>>>   .../selftests/bpf/prog_tests/deny_namespace.c | 12 ++--
>>>   .../selftests/bpf/progs/test_deny_namespace.c |  7 ++-
>>>   8 files changed, 76 insertions(+), 14 deletions(-)
>>
>> I'm not sure we want to go down the path of a LSM modifying the POSIX
>> capabilities of a task, other than the capabilities/commoncap LSM.  It
>> sets a bad precedent and could further complicate issues around LSM
>> ordering.
> 
> Well unless I'm misunderstanding, this does allow modifying the
> capabilities/commoncap LSM through BTF. The reason for allowing
> `userns_create` to be modified is that it is functionally very similar
> to `cred_prepare` in that it operates with new creds (but specific to
> user namespaces because of reasons detailed in [1]).
> 
yes

> There were some concerns in previous threads that the userns caps by
> themselves wouldn't be granular enough, hence the LSM integration.

> Ubuntu for example, currently has to resort to a hardcoded profile
> transition to achieve this [2].
> 

The hard coded profile transition, is because the more generic solution
as part of policy just wasn't ready. The hard coding will go away before
it is upstreamed.

But yes, updating the cred really is necessary for the flexibility needed
whether it is modifying the POSIX capabilities of the task or the LSM
modifying its own security blob.

I do share some of Paul's concerns about the LSM modifying the POSIX
capabilities of the task, but also thing the LSM here needs to be
able to modify its own blob.

I have a very similar patch I was planning on posting once the
work to fix the hard coded profile transition is done.

> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7cd4c5c2101cb092db00f61f69d24380cf7a0ee8
> [2] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble/commit/?id=43a6c29532f517179fea8c94949d657d71f4fc13