[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4D2A1543-273F-417F-921B-E9F994FBF2E8@amacapital.net>
Date: Tue, 23 Apr 2024 09:44:50 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Stas Sergeev <stsp2@...dex.ru>
Cc: linux-kernel@...r.kernel.org, Stefan Metzmacher <metze@...ba.org>,
Eric Biederman <ebiederm@...ssion.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Andy Lutomirski <luto@...nel.org>, Christian Brauner <brauner@...nel.org>,
Jan Kara <jack@...e.cz>, Jeff Layton <jlayton@...nel.org>,
Chuck Lever <chuck.lever@...cle.com>,
Alexander Aring <alex.aring@...il.com>, linux-fsdevel@...r.kernel.org,
linux-api@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
Christian Göttsche <cgzones@...glemail.com>
Subject: Re: [PATCH v2 0/2] implement OA2_INHERIT_CRED flag for openat2()
> On Apr 23, 2024, at 4:02 AM, Stas Sergeev <stsp2@...dex.ru> wrote:
>
> This patch-set implements the OA2_INHERIT_CRED flag for openat2() syscall.
> It is needed to perform an open operation with the creds that were in
> effect when the dir_fd was opened. This allows the process to pre-open
> some dirs and switch eUID (and other UIDs/GIDs) to the less-privileged
> user, while still retaining the possibility to open/create files within
> the pre-opened directory set.
I like the concept, as it’s a sort of move toward a capability system. But I think that making a dirfd into this sort of capability would need to be much more explicit. Right now, any program could do this entirely by accident, and applying OA2_INHERIT_CRED to an fd fished out of /proc seems hazardous.
So perhaps if an open file description for a directory could have something like FMODE_CRED, and if OA2_INHERIT_CRED also blocked .., magic links, symlinks to anywhere above the dirfd (or maybe all symlinks) and absolute path lookups, then this would be okay.
Also, there are lots of ways that f_cred could be relevant: fsuid/fsgid, effective capabilities and security labels. And it gets more complex if this ever gets extended to support connecting or sending to a socket or if someone opens a device node. Does CAP_SYS_ADMIN carry over?
>
> Changes in v2:
> - capture full struct cred instead of just fsuid/fsgid.
> Suggested by Stefan Metzmacher <metze@...ba.org>
>
> CC: Stefan Metzmacher <metze@...ba.org>
> CC: Eric Biederman <ebiederm@...ssion.com>
> CC: Alexander Viro <viro@...iv.linux.org.uk>
> CC: Andy Lutomirski <luto@...nel.org>
> CC: Christian Brauner <brauner@...nel.org>
> CC: Jan Kara <jack@...e.cz>
> CC: Jeff Layton <jlayton@...nel.org>
> CC: Chuck Lever <chuck.lever@...cle.com>
> CC: Alexander Aring <alex.aring@...il.com>
> CC: linux-fsdevel@...r.kernel.org
> CC: linux-kernel@...r.kernel.org
> CC: linux-api@...r.kernel.org
> CC: Paolo Bonzini <pbonzini@...hat.com>
> CC: Christian Göttsche <cgzones@...glemail.com>
>
> Stas Sergeev (2):
> fs: reorganize path_openat()
> openat2: add OA2_INHERIT_CRED flag
>
> fs/internal.h | 2 +-
> fs/namei.c | 52 +++++++++++++++++++++++++++++-------
> fs/open.c | 2 +-
> include/linux/fcntl.h | 2 ++
> include/uapi/linux/openat2.h | 3 +++
> 5 files changed, 50 insertions(+), 11 deletions(-)
>
> --
> 2.44.0
>
>
Powered by blists - more mailing lists