linux-kernel - Re: [GIT PULL] execve updates for v6.13-rc1

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]

Message-ID: <Zz-zJr4_qMED8ned@kawka3.in.waw.pl>
Date: Thu, 21 Nov 2024 22:24:38 +0000
From: Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Kees Cook <kees@...nel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christophe JAILLET <christophe.jaillet@...adoo.fr>,
	Dan Carpenter <dan.carpenter@...aro.org>,
	Nir Lichtman <nir@...htman.org>,
	syzbot+03e1af5c332f7e0eb84b@...kaller.appspotmail.com,
	Tycho Andersen <tandersen@...flix.com>,
	Vegard Nossum <vegard.nossum@...cle.com>
Subject: Re: [GIT PULL] execve updates for v6.13-rc1

On Thu, Nov 21, 2024 at 01:48:59PM -0800, Linus Torvalds wrote:
> On Thu, 21 Nov 2024 at 13:31, Zbigniew Jędrzejewski-Szmek
> <zbyszek@...waw.pl> wrote:
> >
> > The point is that comm _is_ used in many places that matter. I'm not
> > sure what you're trying to say really, since in the second half of
> > your mail you actually showed an example where this is true.
> 
> Really, let me say this one more time: if you don't like the dentry
> name, don't give execveat() a bare file descriptor that has no other
> name, and claim that you want to use some completely unrelated third
> thing that has nothing to do with it except in your little
> dream-world.
> 
> The dentry name is not just fine, it's THE TRUTH. It's fundamentally
> what you are executing.

It may be THE TRUTH, but this is not what userspace expects.
A user calls e.g. /usr/bin/wget and they really expect 'pgrep wget'
to return a PID. They don't care that the dentry name is actually
'wget2', even if the exec is realized through fexecve.

> It's better than - and fundamentally different from - argv[0], which
> is something entirely different and is defined to be available
> elsewhere.

Kees explained this really well, please check his mail. Everybody
knows that argv[0] is (or rather can be) different.

What people expect is for /proc//comm to be the basename of the path
that was passed to execve(2). Give me an interface that allows the
caller to use fexecve() instead and set comm. I don't really care how
that interface looks, as long as it's possible to set comm to
mimick previous behaviour.

The patch uses argv[0] because in a great majority of cases in normal
use basename(argv[0]) is the same as comm. So it provides a good
fallback. _Better_ than the dentry name, as far as the userspace is
concerned.

> If you have done an open() that followed a symlink, the name *behind*
> the symlink is the *CORRECT* name. So when you then do an execveat(),
> it's literally the thing *behind* the symlink that you are executing.
> 
> You are trying to claim that people want argv[0]. No they don't. If
> they wanted argv[0], they'd use /proc/*/cmdline, which already give
> you that, and more.

That's not what I said. What was said is that argv[0] can be used
to set comm in a way that _the userspace expects_.

To be clear: the dentry name goes 95% of the way. It certainly
is better than the current "3" or whatever. If we cannot fix the
remaining 5%, we'll need to adjust some userspace and possibly
have some annoyed users. So I'd prefer that the kernel merges a
patch that uses the dentry name, but it'd be better to use
argv[0] which solves the problem 99+% of the way.

> And if they don't want argv[0], then they get the name that the
> executable was started with. Which is the name *behind* the symlink
> that was resolved by the (preceding) 'open()'.
> 
> I'm trying to explain to you that comm[] IS NOT, AND HAS NEVER BEEN,
> argv[0]. The two have *never* matched up and been the same thing. It's
> simply not how execve() works.

Yes, this is exactly what Kees wrote in his mail. Nobody is disputing
that.

> I don't even understand why you care about the symlink thing. You did
> an open, you followed the symlink, the file no longer points to the
> symlink, trying to claim that it does is simply not *true* in any
> shape or form.

I have a generic execution engine (systemd). Userspace uses it to call
arbitrary programs. That userspace expects that comm/pgrep/top/htop/etc/etc/etc
show the "name of the program". The _name by which it was called_.
For decades, this has been the symlink name, not target.

Zbyszek