linux-kernel - Re: Are setuid shell scripts safe? (Implied by security_bprm_creds_for

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] [day] [month] [year] [list]

Message-ID: <722m42dxrfxao7y6ul5cb26orxoinsrozwqlf7ts52lpbfzgxs@gm6kakrzlhkz>
Date: Tue, 9 Dec 2025 13:28:48 +0100
From: Jan Kara <jack@...e.cz>
To: Bernd Edlinger <bernd.edlinger@...mail.de>
Cc: Al Viro <viro@...iv.linux.org.uk>, 
	"Eric W. Biederman" <ebiederm@...ssion.com>, Roberto Sassu <roberto.sassu@...weicloud.com>, 
	Alexey Dobriyan <adobriyan@...il.com>, Oleg Nesterov <oleg@...hat.com>, Kees Cook <kees@...nel.org>, 
	Andy Lutomirski <luto@...capital.net>, Will Drewry <wad@...omium.org>, 
	Christian Brauner <brauner@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Michal Hocko <mhocko@...e.com>, Serge Hallyn <serge@...lyn.com>, 
	James Morris <jamorris@...ux.microsoft.com>, Randy Dunlap <rdunlap@...radead.org>, 
	Suren Baghdasaryan <surenb@...gle.com>, Yafang Shao <laoar.shao@...il.com>, Helge Deller <deller@....de>, 
	Adrian Reber <areber@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Jens Axboe <axboe@...nel.dk>, Alexei Starovoitov <ast@...nel.org>, 
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	linux-kselftest@...r.kernel.org, linux-mm@...ck.org, linux-security-module@...r.kernel.org, 
	tiozhang <tiozhang@...iglobal.com>, Luis Chamberlain <mcgrof@...nel.org>, 
	"Paulo Alcantara (SUSE)" <pc@...guebit.com>, Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Frederic Weisbecker <frederic@...nel.org>, YueHaibing <yuehaibing@...wei.com>, 
	Paul Moore <paul@...l-moore.com>, Aleksa Sarai <cyphar@...har.com>, 
	Stefan Roesch <shr@...kernel.io>, Chao Yu <chao@...nel.org>, xu xin <xu.xin16@....com.cn>, 
	Jeff Layton <jlayton@...nel.org>, Jan Kara <jack@...e.cz>, David Hildenbrand <david@...hat.com>, 
	Dave Chinner <dchinner@...hat.com>, Shuah Khan <shuah@...nel.org>, 
	Elena Reshetova <elena.reshetova@...el.com>, David Windsor <dwindsor@...il.com>, 
	Mateusz Guzik <mjguzik@...il.com>, Ard Biesheuvel <ardb@...nel.org>, 
	"Joel Fernandes (Google)" <joel@...lfernandes.org>, "Matthew Wilcox (Oracle)" <willy@...radead.org>, 
	Hans Liljestrand <ishkamiel@...il.com>, Penglei Jiang <superman.xpt@...il.com>, 
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Adrian Ratiu <adrian.ratiu@...labora.com>, 
	Ingo Molnar <mingo@...nel.org>, "Peter Zijlstra (Intel)" <peterz@...radead.org>, 
	Cyrill Gorcunov <gorcunov@...il.com>, Eric Dumazet <edumazet@...gle.com>, zohar@...ux.ibm.com, 
	linux-integrity@...r.kernel.org, Ryan Lee <ryan.lee@...onical.com>, 
	apparmor <apparmor@...ts.ubuntu.com>
Subject: Re: Are setuid shell scripts safe? (Implied by
 security_bprm_creds_for_exec)

On Thu 04-12-25 14:03:27, Bernd Edlinger wrote:
> On 12/4/25 06:49, Al Viro wrote:
> > On Wed, Dec 03, 2025 at 02:16:29PM +0100, Bernd Edlinger wrote:
> > 
> >> Hmm, yes, that looks like an issue.
> >>
> >> I would have expected the security engine to look at bprm->filenanme
> >> especially in the case, when bprm->interp != bprm->filename,
> >> and check that it is not a sym-link with write-access for the
> >> current user and of course also that the bprm->file is not a regular file
> >> which is writable by the current user, if that is the case I would have expected
> >> the secuity engine to enforce non-new-privs on a SUID executable somehow.
> > 
> > Check that _what_ is not a symlink?  And while we are at it, what do write
> > permissions to any symlinks have to do with anything whatsoever?
> 
> When we execve a normal executable, we do open the binary file with
> deny_write_access so this might allow the security engine to inspaect the
> binary, before it is used.

That would be seriously flawed IMO because there are lot of cases where
code is executed without deny_write_access() - like shared libraries, code
loaded by interpreter, and probably more.

> However this behavior has changed recently,
> now it has some exceptions, where even this behavior is no longer
> guaranteed for binary executables, due to commit
> 0357ef03c94ef835bd44a0658b8edb672a9dbf51, but why?  I have no idea...

Because for hierarchical storage implementation you may need to fill in the
executable data from remote storage on demand and the deny_write_access
logic was making this impossible. We even tried to completely remove the
deny_write_access logic exactly because it has very limited use and
complicates things (commit 2a010c412853 ("fs: don't block i_writecount
during exec")) but that had to be reverted because some userspace depends
on the ETXTBUSY behavior.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR