From: Andy Lutomirski <luto@amacapital.net>
To: stsp <stsp2@yandex.ru>
Cc: "Aleksa Sarai" <cyphar@cyphar.com>,
"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>,
"Christian Brauner" <brauner@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: Sun, 28 Apr 2024 14:30:40 -0700 [thread overview]
Message-ID: <CALCETrXPgabERgWAru7PNz6A5rc6BTG9k2RRmjU71kQs4rSsPQ@mail.gmail.com> (raw)
In-Reply-To: <33bbaf98-db4f-4ea6-9f34-d1bebf06c0aa@yandex.ru>
On Sun, Apr 28, 2024 at 2:15 PM stsp <stsp2@yandex.ru> wrote:
>
> 28.04.2024 23:19, Andy Lutomirski пишет:
> >> Doesn't this have the same problem
> >> that was pointed to me? Namely (explaining
> >> my impl first), that if someone puts the cred
> >> fd to an unaware process's fd table, such
> >> process can't fully drop its privs. He may not
> >> want to access these dirs, but once its hacked,
> >> the hacker will access these dirs with the
> >> creds came from an outside.
> > This is not a real problem. If I have a writable fd for /etc/shadow or
> > an fd for /dev/mem, etc, then I need close them to fully drop privs.
>
> But isn't that becoming a problem once
> you are (maliciously) passed such fds via
> exec() or SCM_RIGHTS? You may not know
> about them (or about their creds), so you
> won't close them. Or?
Wait, who's the malicious party? Anyone who can open a directory has,
at the time they do so, permission to do so. If you send that fd to
someone via SCM_RIGHTS, all you accomplish is that they now have the
fd.
In my scenario, the malicious party attacks an *existing* program that
opens an fd for purposes that it doesn't think are dangerous. And
then it gives the fd *to the malicious program* by whatever means
(could be as simple as dropping privs then doing dlopen). Then the
malicious program does OA2_INHERIT_CREDS and gets privileges it
shouldn't have.
But if the *whole point* of opening the fd was to capture privileges
and preserve them across a privilege drop, and the program loads
malicious code after dropping privs, then that's a risk that's taken
intentionally. This is like how, if you do curl
http://whatever.com/foo.sh | bash, you are granting all kinds of
permissions to unknown code.
> >> My solution was to close such fds on
> >> exec and disallowing SCM_RIGHTS passage.
> > I don't see what problem this solves.
>
> That the process that received them,
> doesn't know they have O_CRED_ALLOW
> within. So it won't deduce to close them
> in time.
Hold on -- what exactly are you talking about? A process does
recvmsg() and doesn't trust the party at the other end. Then it
doesn't close the received fd. Then it does setuid(getuid()). Then
it does dlopen or exec of an untrusted program.
Okay, so the program now has a completely unknown fd. This is already
part of the thread model. It could be a cred-capturing fd, it could
be a device node, it could be a socket, it could be a memfd -- it
could be just about anything. How do any of your proposals or my
proposals cause an actual new problem here?
> > This is fundamental to the whole model. If I stick a FAT formatted USB
> > drive in the system and mount it, then any process that can find its
> > way to the mountpoint can write to it. And if I open a dirfd, any
> > process with that dirfd can write it. This is old news and isn't a
> > problem.
>
> But IIRC O_DIRECTORY only allows O_RDONLY.
> I even re-checked now, and O_DIRECTORY|O_RDWR
> gives EISDIR. So is it actually true that
> whoever has dir_fd, can write to it?
If the filesystem grants that UID permission to write, then it can write.
next prev parent reply other threads:[~2024-04-28 21:30 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 [this message]
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
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=CALCETrXPgabERgWAru7PNz6A5rc6BTG9k2RRmjU71kQs4rSsPQ@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.