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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 280F6CF9C6B for ; Tue, 24 Sep 2024 21:37:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD9D06B00AB; Tue, 24 Sep 2024 17:37:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B89A06B00AC; Tue, 24 Sep 2024 17:37:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A79236B00AD; Tue, 24 Sep 2024 17:37:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 897626B00AB for ; Tue, 24 Sep 2024 17:37:18 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 021354048C for ; Tue, 24 Sep 2024 21:37:17 +0000 (UTC) X-FDA: 82600942956.29.E1FD746 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf19.hostedemail.com (Postfix) with ESMTP id 48C371A0004 for ; Tue, 24 Sep 2024 21:37:15 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=E1wU9e5+; spf=pass (imf19.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727213800; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mf1gGSnGoxvkKv9XLdy9cOBIW6DlDki8yenmm9QZiMY=; b=40mowfJQIC1JJMOslX+tqGqwmqmD3jIKc7JtnkZf0R6fzbW0fcIF7zQ4aU90zs02fSuDyj XS1i49yYFLopswidiGGQXeZeIV232/+dvtGV0VYdSPfBj6BRSBHZtjqiXMg5NkxofW+YMO sfpEqod9Aasv+QcoS4JgXj+jvyJpozQ= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=E1wU9e5+; spf=pass (imf19.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727213800; a=rsa-sha256; cv=none; b=BV3wS9tkpMaKW3XfaYCiAiqCCgshbmCy7AJTaLdAOUp8Hl2tlos5iFcwBGjqVn761vqQlG 2R/A00yxamG/7mJG7OGI4zIP+UW26pWSCFhfQv+RRIxw66MM3cRxtXrDW62fncW5eeKpS8 aw46Rmm7KU6hBVZLdEV8DZguvsJDDGM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2C1995C55FD; Tue, 24 Sep 2024 21:37:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9D76C4CEC4; Tue, 24 Sep 2024 21:37:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1727213833; bh=NtcrugAuxPs+bS2qbXsCsi/0ivuoPlB+E91MIF93xHM=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=E1wU9e5+Uxs1EPbT3y1RQHBRU4n8g2E0EpNj535Lxwq4CeSfBXXuCqWXpuvOmkZ9K HsVfsDabyS+BRUlmrfhayYio9AhH3Q4iFQ5JN4BzMg1WJXRiu7uvNsn9cMi0XIKslQ YHWgyJbyH6fSVsRn+4ryQy0bnFuy8E/NSTuq51hnTNQBpdKF+viHNgxj5xLAdsrIcw kfWYhhwHre4ROvWcDWkP0dT5Ty9XH0lni8CFkd+wSjYZ2k8z0asV513mjpcBrrqa/M DsJsSQDmxfjF1wXIG01zLkuTkbAl8AFhaQvNHsVWa0fkxTLb4/5+HpFEKqIghLbZhz wwNoqesepyRag== Date: Tue, 24 Sep 2024 14:37:13 -0700 From: Kees Cook To: "Eric W. Biederman" , Tycho Andersen CC: Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Chuck Lever , Alexander Aring , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Tycho Andersen , =?UTF-8?Q?Zbigniew_J=C4=99drzejewski-Szmek?= , Aleksa Sarai Subject: Re: [RFC] exec: add a flag for "reasonable" execveat() comm User-Agent: K-9 Mail for Android In-Reply-To: <87msjx9ciw.fsf@email.froward.int.ebiederm.org> References: <20240924141001.116584-1-tycho@tycho.pizza> <87msjx9ciw.fsf@email.froward.int.ebiederm.org> Message-ID: <8D545969-2EFA-419A-B988-74AD0C26020C@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 55w8huettkme4mac8xsxs4tmws119r1j X-Rspamd-Queue-Id: 48C371A0004 X-Rspamd-Server: rspam11 X-HE-Tag: 1727213835-490746 X-HE-Meta: U2FsdGVkX19Dn4uCdBaPHaBsvQ+udlRoHsKmxuLzjOqIpKAaq3bMI1vjZN7P0eg6o3JvfpA7KrYhUm2zDpf2GUSz+agrawAf3K555HvND2nrVRj1VZ2f2S1KjRGDJTI0XvfmjUJIhJtWWt/OFjRDIj1QACG+hB08N53wLGwraaXKU6jph3noUiu8B4aUofZSsoPhULpx7Io9qEJg68MnfJTwnZVHhsE027e0lTpJJSNMe7FykCarncmKnLtLp1CsRVOwcQstqLv0OFtw0MGgCrryTj+8P+XVmVOZFsW9Kti9m/3GlJTJUZCpMsBk+KZ1mgtemAsu1iw4tOuvZH9Pjs/zOS5v4AsAoftqYI4UQ2Xr6c/DYay0MgdKX9yny7FmL+tFexvzkiMH2rtSqcdGZzwJxsl9s4IFKaDPUKxTOqiXmJ/xJUNR5cE9rh7K5aeEf88VJGMxwHHRG3kDo/MftO+PJBA+A2qXK7RNCDTFBzp4RfdNMasODvo6zVdYjytW8TUT3NRrKEK11U3saON/hRivk0hyRu62aCLsECfsgsYuUZDZnjOEWThoakRoHcGmSMe+JV09oYqdpm9ug8DJ9Hb2qfxoBKOs7GyvxKk+l9dw5bouU8xy/IS3E9WPtnn/ZiZR5Q4YEORV6KcQTAYYodWS/Y/hGb34roMOXqIG8LD/fV2/Ksx+Vq83Xd+B7LQ+3Ae4o8xGW9/ThDRJ/zMjDdpeTeMfPmI6i1LMs01++druRfzz0W3P59TDPHcYZKQkkFhvcxuLFMLYyseMbCbCsE2TZP5D97YG3qp0mG6ymq4dP6ViqcMaAY4qjArE7tyRs39EQAdnOHzsF4P993AIS2gVhPv1tRv+Ra3pQeABb5Ex6uxCFrRdVC3vDgevvcOY48YWCTiBoX2fmHy7hCPCVWzvYMv+DxWUP8NaI++o8jNg5Rv44Kw8bbXc2BwUnHKZFaDwEHQM1f71q64t4WN 8hw+GqPC 6s+3XUNrAYZgOTGTsRMN5SsfhEqluwpNhieDhdGRjvcEgaVlvhLBQHsILzzNSxVTWX+64CdMW+7dV7B595OjYdeKyIPGz4yItUN6+vpiMzkxKnis0iKMz/+s+RCPkMAaEIzmvmkC+v6zUmrCAb14madxTZw9mkfEw7Mwe1D3NBzFs9aShin7DLZ5UyIg5h80UoXTuHx8VmreB93NdE5FeF2QzaNvN0AB2XgfGkWFBHPaZoNB/+LdGuPHAscwp0Or2vW8M1F4YG7paT64rn8tlawkHY9iNBAOMPJ2GSiUDTv/aSE8qWZ91H3FPIRwxrbWSBzi6k0lB4FNvT5NGFD3WtDfm4FjnRd25u1FpXV1G2uoWr1EV5TEwnX0mbg2Q5bmmDMMx X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On September 24, 2024 10:39:35 AM PDT, "Eric W=2E Biederman" wrote: >Tycho Andersen writes: > >> From: Tycho Andersen >> >> Zbigniew mentioned at Linux Plumber's that systemd is interested in >> switching to execveat() for service execution, but can't, because the >> contents of /proc/pid/comm are the file descriptor which was used, >> instead of the path to the binary=2E This makes the output of tools lik= e >> top and ps useless, especially in a world where most fds are opened >> CLOEXEC so the number is truly meaningless=2E And just to double check: systemd's use would be entirely cosmetic, yes? >> >> This patch adds an AT_ flag to fix up /proc/pid/comm to instead be the >> contents of argv[0], instead of the fdno=2E > >The kernel allows prctl(PR_SET_NAME, =2E=2E=2E) without any permission >checks so adding an AT_ flat to use argv[0] instead of the execed >filename seems reasonable=2E > >Maybe the flag should be called AT_NAME_ARGV0=2E If we add an AT flag I like this name=2E > > >That said I am trying to remember why we picked /dev/fd/N, as the >filename=2E > >My memory is that we couldn't think of anything more reasonable to use=2E >Looking at commit 51f39a1f0cea ("syscalls: implement execveat() system >call") unfortunately doesn't clarify anything for me, except that >/dev/fd/N was a reasonable choice=2E > >I am thinking the code could reasonably try: > get_fs_root_rcu(current->fs, &root); > path =3D __d_path(file->f_path, root, buf, buflen); > >To see if a path to the file from the current root directory can be >found=2E For files that are not reachable from the current root the code >still need to fallback to /dev/fd/N=2E > >Do you think you can investigate that and see if that would generate >a reasonable task->comm? > >If for no other reason than because it would generate a usable result >for #! scripts, without /proc mounted=2E > > >It looks like a reasonable case can be made that while /dev/fd/N is >a good path for interpreters, it is never a good choice for comm, >so perhaps we could always use argv[0] if the fdpath is of the >form /dev/fd/N=2E I haven't had a chance to go look closely yet, but this was the same thoug= ht I had when I first read this RFC=2E Nobody really wants a dev path in co= mm=2E Can we do this unconditionally? (And if argv0 is empty, use dev path= =2E=2E=2E) >All of that said I am not a fan of the implementation below as it has >the side effect of replacing /dev/fd/N with a filename that is not >usable by #! interpreters=2E So I suggest an implementation that affects >task->comm and not brpm->filename=2E Also agreed=2E There is already enough fiddly usage of the bprm filename/i= nterpreter/fdpath members -- the argv0 stuff should be distinct=2E Perhaps = store a pointer to argv0 during arg copy? I need to go look but I'm still A= FK/OoO=2E=2E=2E -Kees --=20 Kees Cook