From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D790C43219 for ; Wed, 6 Apr 2022 02:41:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1446976AbiDFCmG (ORCPT ); Tue, 5 Apr 2022 22:42:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1585626AbiDFAAG (ORCPT ); Tue, 5 Apr 2022 20:00:06 -0400 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FB4B5DE40; Tue, 5 Apr 2022 15:22:11 -0700 (PDT) Received: from cwcc.thunk.org (pool-108-7-220-252.bstnma.fios.verizon.net [108.7.220.252]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 235MLeah002791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Apr 2022 18:21:40 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id DFA5915C3EB6; Tue, 5 Apr 2022 18:21:39 -0400 (EDT) Date: Tue, 5 Apr 2022 18:21:39 -0400 From: "Theodore Ts'o" To: Linus Torvalds Cc: Kees Cook , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , Al Viro , Andrew Morton , Christian Heimes , Geert Uytterhoeven , James Morris , Luis Chamberlain , Mimi Zohar , Muhammad Usama Anjum , Paul Moore , Philippe =?iso-8859-1?Q?Tr=E9buchet?= , Shuah Khan , Steve Dower , Thibaut Sautereau , Vincent Strubel , linux-fsdevel , linux-integrity , Linux Kernel Mailing List , LSM List , Christian Brauner Subject: Re: [GIT PULL] Add trusted_for(2) (was O_MAYEXEC) Message-ID: References: <20220321161557.495388-1-mic@digikod.net> <202204041130.F649632@keescook> <816667d8-2a6c-6334-94a4-6127699d4144@digikod.net> <202204041451.CC4F6BF@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: On Mon, Apr 04, 2022 at 04:26:44PM -0700, Linus Torvalds wrote: > > > (a) "what about suid bits that user space cannot react to" > > > > What do you mean here? Do you mean setid bits on the file itself? > > Right. > > Maybe we don't care. > > Maybe we do. > > Is the user-space loader going to honor them? Is it going to ignore > them? I don't know. And it actually interacts with things like > 'nosuid', which the kernel does know about, and user space has a hard > time figuring out. So there *used* to be suidperl which was a setuid version of perl with some extra security checks. (See [1] for more details.) The suidperl binary would be used by #!/usr/bin/perl so it could honor setuid bits on perl scripts, but it was deprecated in Perl 5.8 and removed in Perl 5.12 in 2010[2]. [1] https://mattmccutchen.net/suidperl.html [2] https://metacpan.org/release/SHAY/perl-5.20.2/view/pod/perl5120delta.pod#Deprecations So it's possible that the user-space loader might try to honor them, and if there was such an example "in the field", it might be nice if there was a way for the kernel to advise userspace about the nosuid. But I'm not aware of any other shell script interpreter that tried do what perl did with suidperl. > So if the point is "give me an interface so that I can do the same > thing a kernel execve() loader would do", then those sgid/suid bits > actually may be exactly the kind of thing that user space wants the > kernel to react to - should it ignore them, or should it do something > special when it sees that they are set? > > I'm not saying that they *should* be something we care about. All I'm > saying is that I want that *discussion* to happen. I'm not convinced we should. I suppose *if* the shell script was suid, *and* the file system was mounted nosuid, then the check could return false, and that would be mostly harmless even if the script interpreter didn't support setuid. But it's extra complexity, and in theory it could break a setuid script, where the setuid bit was previously a no-op, and it now might cause a problem for that user. - Ted