From: Andy Lutomirski <luto@amacapital.net>
To: Christian Brauner <brauner@kernel.org>
Cc: "Aleksa Sarai" <cyphar@cyphar.com>,
"Stas Sergeev" <stsp2@yandex.ru>,
"Serge E. Hallyn" <serge@hallyn.com>,
linux-kernel@vger.kernel.org,
"Stefan Metzmacher" <metze@samba.org>,
"Eric Biederman" <ebiederm@xmission.com>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Andy Lutomirski" <luto@kernel.org>, "Jan Kara" <jack@suse.cz>,
"Jeff Layton" <jlayton@kernel.org>,
"Chuck Lever" <chuck.lever@oracle.com>,
"Alexander Aring" <alex.aring@gmail.com>,
"David Laight" <David.Laight@aculab.com>,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Christian Göttsche" <cgzones@googlemail.com>
Subject: Re: [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2()
Date: Wed, 8 May 2024 10:30:50 -0700 [thread overview]
Message-ID: <CALCETrWEBY6HLyRqgN65YVp0gP0akU_HyVbGctC6sph5NX6RkQ@mail.gmail.com> (raw)
In-Reply-To: <20240508-flugverbindung-sonnig-dcfa4971152e@brauner>
On Wed, May 8, 2024 at 12:32 AM Christian Brauner <brauner@kernel.org> wrote:
>
> On Tue, May 07, 2024 at 01:38:42PM -0700, Andy Lutomirski wrote:
> > On Tue, May 7, 2024 at 12:42 AM Christian Brauner <brauner@kernel.org> wrote:
> > >
> > > > With my kernel hat on, maybe I agree. But with my *user* hat on, I
> > > > think I pretty strongly disagree. Look, idmapis lousy for
> > > > unprivileged use:
> > > >
> > > > $ install -m 0700 -d test_directory
> > > > $ echo 'hi there' >test_directory/file
> > > > $ podman run -it --rm
> > > > --mount=type=bind,src=test_directory,dst=/tmp,idmap [debian-slim]
> > >
> > > $ podman run -it --rm --mount=type=bind,src=test_directory,dst=/tmp,idmap [debian-slim]
> > >
> > > as an unprivileged user doesn't use idmapped mounts at all. So I'm not
> > > sure what this is showing. I suppose you're talking about idmaps in
> > > general.
> >
> > Meh, fair enough. But I don't think this would have worked any better
> > with privilege.
> >
> > Can idmaps be programmed by an otherwise unprivileged owner of a
> > userns and a mountns inside?
>
> Yes, but only for userns mountable filesystems that support idmapped
> mounts. IOW, you need privilege over the superblock and the idmapping
> you're trying to use.
Hmm. Is there a good reason to require privilege over the superblock?
Obviously creating an idmap that allows one to impersonate someone
else seems like a problem, but if an unprivileged task already "owns"
(see below) a UID or GID, then effectively delegating that UID or GID
is would need caution but is not fundamentally terrible.
So, if I'm 1000:1000, then creating an idmap that makes some other
task (that isn't 1000:1000) get to act as 1000:1000 doesn't grant new
powers. But maybe something even more general could be done (although
I'm not sure this is worthwhile): if I own a userns and that userns
has an outside UID 1001 mapped (via newuidmap, for example), then
perhaps letting me configure an idmap that grants UID 1001 seems not
especially dangerous. But maybe that particular job should also be
delegated to newuidmap.
Out of an abundance of caution, maybe this whole thing should be
opt-in. For example, there could be a new CAP_DELEGATE that allows
delegation of one's own uid and gid. The idea is that it should be
safe to grant regular users CAP_DELEGATE as an ambient capability.
--Andy
prev parent reply other threads:[~2024-05-08 17:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 13:33 [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2() Stas Sergeev
2024-04-26 13:33 ` [PATCH v5 1/3] fs: reorganize path_openat() Stas Sergeev
2024-04-26 13:33 ` [PATCH v5 2/3] open: add O_CRED_ALLOW flag Stas Sergeev
2024-04-27 2:12 ` kernel test robot
2024-04-26 13:33 ` [PATCH v5 3/3] openat2: add OA2_CRED_INHERIT flag Stas Sergeev
2024-04-28 16:41 ` [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2() Andy Lutomirski
2024-04-28 17:39 ` stsp
2024-04-28 19:15 ` stsp
2024-04-28 20:19 ` Andy Lutomirski
2024-04-28 21:14 ` stsp
2024-04-28 21:30 ` Andy Lutomirski
2024-04-28 22:12 ` stsp
2024-04-29 1:12 ` stsp
2024-04-29 9:12 ` Christian Brauner
2024-05-06 7:13 ` Aleksa Sarai
2024-05-06 17:29 ` Andy Lutomirski
2024-05-06 17:34 ` Andy Lutomirski
2024-05-06 19:34 ` David Laight
2024-05-06 21:53 ` Andy Lutomirski
2024-05-07 7:42 ` Christian Brauner
2024-05-07 20:38 ` Andy Lutomirski
2024-05-08 7:32 ` Christian Brauner
2024-05-08 17:30 ` Andy Lutomirski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrWEBY6HLyRqgN65YVp0gP0akU_HyVbGctC6sph5NX6RkQ@mail.gmail.com \
--to=luto@amacapital.net \
--cc=David.Laight@aculab.com \
--cc=alex.aring@gmail.com \
--cc=brauner@kernel.org \
--cc=cgzones@googlemail.com \
--cc=chuck.lever@oracle.com \
--cc=cyphar@cyphar.com \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=metze@samba.org \
--cc=pbonzini@redhat.com \
--cc=serge@hallyn.com \
--cc=stsp2@yandex.ru \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).