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, 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ