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: <Zz9sTFBQQSe1P8AI@kawka3.in.waw.pl>
Date: Thu, 21 Nov 2024 17:22:20 +0000
From: Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
	Kees Cook <kees@...nel.org>, 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 Wed, Nov 20, 2024 at 06:23:55PM -0800, Linus Torvalds wrote:
> On Wed, 20 Nov 2024 at 16:55, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> >
> > __set_task_comm cannot be called with bprm->file->f_dentry
> > unconditionally.
> 
> No, no. Only for the "no path" case.
> 
> > The reason bprm->file->f_dentry.dentry was abandoned were concerns
> > about breaking userspace.
> 
> There's no way it can break user space considering that right now
> comm[] ends up being just garbage.

It'll "break userspace" in the sense the the resulting program name
visible in /proc/self/{comm,stat,status} would be different than the
expected value. Currently userspace is not using fexecve because this
string is "just garbage". We'd very much like to start using fexecve,
but we cannot do this (in the general case) if that'll result in a
changed program name. If we change the value from the current
(garbage) value to something that doesn't provide identical behaviour
between execve and fexecve, fexecve will unused.

As Eric wrote, there are various programs which are symlinked.
/etc/alternatives is one group, but we also have "multicall binaries"
which present different behaviour depending on the name.
Some of those use argv[0], but other may use comm.
We really need the name that the user called the program as,
not the name after symlink chasing.

Even if we end up copying a string from userspace unnecessarilly,
does this matter? execve is a heavyweight operation and copying a
a dozen bytes extra hardly matters.

Zbyszek