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 62FEED7360A for ; Sat, 30 Nov 2024 20:28:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 799E86B007B; Sat, 30 Nov 2024 15:28:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 722B56B0082; Sat, 30 Nov 2024 15:28:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C2826B0083; Sat, 30 Nov 2024 15:28:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3AAFA6B007B for ; Sat, 30 Nov 2024 15:28:39 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A9A36A0A51 for ; Sat, 30 Nov 2024 20:28:38 +0000 (UTC) X-FDA: 82843899096.13.68034BB Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by imf30.hostedemail.com (Postfix) with ESMTP id F1EEE80009 for ; Sat, 30 Nov 2024 20:28:17 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VRRbMbjr; spf=pass (imf30.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732998512; 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=WyuIvPsDL28UptMe7uSjLO9ElhKUA/RSz9Xy4L6BC4E=; b=uAmZX3+P7CEBVF+nzusvFxQ1HEvwqK3/IhsQ03bo7QjwpiHg2OzPdsUSSgGUPUaBFfpBus jc5rQgiCMUbBB5Mh9mVKqKACEwHlQf2isywKhWd6CJfjd+Qo24ilRwo4SHLQZ6mx6Z0nTv m6Yu50sLFsKeAG0FxFHAGXLbczA6QbA= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VRRbMbjr; spf=pass (imf30.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732998512; a=rsa-sha256; cv=none; b=FS1nRvjZoSp20XH84UWenbKQKCYyOE4/545MbiIsokBVVsLdYN5zSNJsNlcu8iLLcuJtbp 3T625EwBpQ5V34hXFkSA4WFfPwbaEzg8IVjFYiR8QTcanG3Bf5l+9XP2tilMFGNMfmeCx2 P8PSu12zQPuOe5FrbgVKI0t9AtklmVU= Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-aa531a70416so181024766b.0 for ; Sat, 30 Nov 2024 12:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732998515; x=1733603315; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=WyuIvPsDL28UptMe7uSjLO9ElhKUA/RSz9Xy4L6BC4E=; b=VRRbMbjrHw+OwdD2uuszTbpLJ6M39/lS7C9e69mjjS7Xkt92XPNzpK/xMgjV4IMvkO 8+lhqwRag70U4HaWiWjAaBpwY+1/GstpkTwco3Fvv4zDM3ev6D5Vf46OHBYL2nQdsk7w RNLV4Lvkkm4mgIQNmJI/oaaFtz5aQlJihk2GirNZCdOfYUsrS9/WUWJVIF3zkkIz8dti /55j2jeSuonmv35ucn70HWjrBuXXHF3CFLd4PNFE7NSIlzJom7Eb/GJ2FQBxHDlJr5ou jqBwPpOHQ625Kh6AYzhbepN6ZZ+WpWiQOWCKlD/7f1FxdDOMe/37xIYD4T83boKyrKNt dPWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732998515; x=1733603315; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WyuIvPsDL28UptMe7uSjLO9ElhKUA/RSz9Xy4L6BC4E=; b=RpiM14xbGx3HI1WeOFuJC5OvbrwrrV/MzXYed3l+6bnGVFM2KvPGW2c9uCzhNHY22k iVSu+JeJk7Cv9iIDhX1SDCfjAgVNfMWKLPhg0EWsuEs8SCrfecQ6JXE+QtOckpXzIEY6 uVHGwqNMEkW+p6uIH3m0+HxL5NDTcJ6S2Cav/E9cvvbSvVPZIh6fChC21NLkqTz6cVtg ra+VCCF8kkuQEF6lNFs79ywKCNpevTW42Z2GIl898flqy6Ur8kgS2vzF7vzipBj85d8z D82pxH53ucMEWLYlwcWT0nwqSKgCinpsYbAUfM/lRAwfKPyxo94xGvGSPTKvSvdcfeyy IBSA== X-Forwarded-Encrypted: i=1; AJvYcCXDRPHgBObLd1j72SYiDOzH+avxLDllCbC/5cksEuWnuagmSdwW2eBKWeeboqIMVoxgpGMJNAczRA==@kvack.org X-Gm-Message-State: AOJu0YzzSZc/qSLzmCT7bHxVogtfqs2VrmSZgYy/+oizBYgudFJVrBj9 EQioYFF4oanl53QjjexiqBGMrk61f133uLun0mgtOnc/w1IuJsEC X-Gm-Gg: ASbGnctFBV8eC66/2+EVe3aj8eGm1DphAxOAGWRvbzJdxlPd3N1uSfiDpogpBwbBxhO npY1iWEVwIbQKh4Wf5eMcH2YAWvsfUNaYJh5loXTl1MihJq4z4tT0VFOc3tadgyqC4zUDI+ydoF tKY25+Z4njeL/nFxCBaGjGx4xIwsvw2KPN67EfXzHpvpARjzSjGgRxBEx+71sXR1Dd7ErZ1xHfX 3e79TKVs57FQ+xoCuDji5neAz5tGw24ZX0uxxkyTVIIAIWXif7PuEBNxv26y9ZseA== X-Google-Smtp-Source: AGHT+IH71PGkxMLJ3V53CD3l5A9uWkt1XBSzU+Pr2sONfbSmaJosGfTGrGB9uADN9NjOgAmOY2YJyw== X-Received: by 2002:aa7:d889:0:b0:5d0:c697:1f02 with SMTP id 4fb4d7f45d1cf-5d0c6971f0dmr6845571a12.17.1732998514576; Sat, 30 Nov 2024 12:28:34 -0800 (PST) Received: from f (cst-prg-87-214.cust.vodafone.cz. [46.135.87.214]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d097dd685csm3129447a12.44.2024.11.30.12.28.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Nov 2024 12:28:33 -0800 (PST) Date: Sat, 30 Nov 2024 21:28:07 +0100 From: Mateusz Guzik To: Kees Cook Cc: Al Viro , Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= , Tycho Andersen , Linus Torvalds , Aleksa Sarai , Eric Biederman , Christian Brauner , Jan Kara , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] exec: fix up /proc/pid/comm in the execveat(AT_EMPTY_PATH) case Message-ID: References: <20241130045437.work.390-kees@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241130045437.work.390-kees@kernel.org> X-Rspamd-Queue-Id: F1EEE80009 X-Stat-Signature: 7gzckjojmo5ew8ji5rykea16swok1z8t X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1732998497-786100 X-HE-Meta: U2FsdGVkX1+wCPnxyVHr1siPt9rG2i7ZqXKdznfjKZCzGbHWCNmn2dzxEbodmIKGMXslLgNP78CaRH4Y2Y86dj/7sM+OMsmE4pUzhqiCeG5y0LbJ+2L9ysBFdr4QZMqvBIe/Wb6RrXHHGr6U6fX3Kg7L8xuL+9zvXIZBhQtj4/NQDG61vWcUUKDvaYptCsyTZomCAzq0aDAn/WKNOSPNg56XOZUHEp6sel3isyG5KYyAQumswmn6/pxxLTHlmwkUj5YrFQJkF96Mi5xJLCpgl+Co2SdAQSkHCzZkNuOJYhMJfOZVvASIo0fRutNI8iMTZPgv48qVUNv6PIC69rdHx0r8aaZfabDiJoZxfnKIT1mJpwzl9s4sFqf31WZbIHsj1ZPm5ZrdShYUQD5jBzrutXI2ScbA5F57Sk0W3W39a/eq1wdNBj7utesOkVK+qiwEiRoGUScG/EA9d8qOYnZh9yg2O02ZrlecObHh4lOZ5EnyuXgBplZgOwSdLsRakCtilXuz1OxzLkTBh/fk2tnDyusaEqvjrXE8lHgznSifGlzdLCBUTBMAVSUp86EXLcV5pSb91vTNJUSgazJoG+3V6gxFABBOt66Lrl2mcwUZlfv+wMFunGDhioKL80R8Ks5PvGigZIlGHeDG54UVz8FQ1KoEnbTRAl2tiV+0+Bt3juYmfjvEyYsSTDYxnPPsUF81LH4oqav3iJmekSPqrZgKoswkr3zz7KqSU4l0wCfHgqOs9DPW4Cltsroj6qHRvAjwhCiXl+rwZAgU+jRzZmV4afXOJLDM/4OdRZ8AfSBZLBUnUjq9X0GyZaNsK5vfF44g6untZtqHMG1OLUWpjigKU/btk1uPZJarrXnCVTP4osslH9+I3vIUrlptTHUANtFjmzbXSuGDVc+EWhZHVQ3UoC9j8bvYCbX4jfw6PS1qwXtJbnHpsqv8aR89fD5KVclKIcHdH//SBKVv3ayc8u0 oE+OWwgT gi8xGItSzESlfzDQHQjWEGuvQj0+BRP3mwvH1lR0tVePnwho6pRJ0WdTWixrGtp1bAG8xXA0YIMzSWsb3hTeisYjblw8M9E4KPC/LSg0ajBQc1KP27ABdMjArPL7g+F7/qM1Wg6NtEIp7HHSIHY/GiBFaGTPW8AKnBmh0jYttfbkhbyPqKieuKT8LCgXU6pn1IFIwx95H6xiFJXEaPKU6Vm8kENt3uuGn2Y0G5RZGUrRybZXvW+4XlyBwjU3DcJVTNs5x6uWrYULcde8vbAtZCcsNeyPo4wlIxytWWFwzwr39cRDUN1cXjQZw0P9QI9UHAJaZ4YQlZTIABJW0eS3iPgyRacemstoFST4gvNb5zB369fgryYjt7XcD6RNwSSuKdLlz7WAYG64bX2bc+5cDQs3TY2A9Viqv40SJdGlzibNkWzFClerNiTwm4iggwAtWcIfs4gAltbVZrWjc1Dn1cdtMPH2kMPvHtr1t+gXEbaPzE3GQJfP/nGrd68vsHPh18IPhyAkzUcNqnEP3hL4LaMrUnPnTGItaakMTQf0ooOyG7x/jimY35WqU6PP/Iglfvj9GOtLw57FA+48X5/HOt+JyGhem5bQz14AUD7CnUZj8pOOs6KAgJhe+IsCifdaho/2uiNjYe60WRzySxkmf34ihemFvsBPYllvwhfpzjh6B/DbPVUjooC/O+tB/bsur87Icmrqq/nCVoGDONkLr9+OiYlU6J31A8APcIH11MTeDzZHXSCn66iAIKgP6n0Xp8tgmW5xP3CaQvUY3ARbPcuB0kk2UdgnaIpkGah2t0z4b4DKBqSsAjVr2y8n/MopUakjJ+kAL+bQtiUc= 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 Fri, Nov 29, 2024 at 08:54:38PM -0800, Kees Cook wrote: > 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. This makes the output of tools like > top and ps useless, especially in a world where most fds are opened > CLOEXEC so the number is truly meaningless. > > When the filename passed in is empty (e.g. with AT_EMPTY_PATH), use the > dentry's filename for "comm" instead of using the useless numeral from > the synthetic fdpath construction. This way the actual exec machinery > is unchanged, but cosmetically the comm looks reasonable to admins > investigating things. > > Instead of adding TASK_COMM_LEN more bytes to bprm, use one of the unused > flag bits to indicate that we need to set "comm" from the dentry. > > Suggested-by: Zbigniew Jędrzejewski-Szmek > Suggested-by: Tycho Andersen > Suggested-by: Al Viro > Suggested-by: Linus Torvalds > CC: Aleksa Sarai > Link: https://github.com/uapi-group/kernel-features#set-comm-field-before-exec > Signed-off-by: Kees Cook > --- > Cc: Al Viro > Cc: Linus Torvalds > Cc: Eric Biederman > Cc: Alexander Viro > Cc: Christian Brauner > Cc: Jan Kara > Cc: linux-mm@kvack.org > Cc: linux-fsdevel@vger.kernel.org > > Here's what I've put together from the various suggestions. I didn't > want to needlessly grow bprm, so I just added a flag instead. Otherwise, > this is very similar to what Linus and Al suggested. > --- > fs/exec.c | 22 +++++++++++++++++++--- > include/linux/binfmts.h | 4 +++- > 2 files changed, 22 insertions(+), 4 deletions(-) > > diff --git a/fs/exec.c b/fs/exec.c > index 5f16500ac325..d897d60ca5c2 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -1347,7 +1347,21 @@ int begin_new_exec(struct linux_binprm * bprm) > set_dumpable(current->mm, SUID_DUMP_USER); > > perf_event_exec(); > - __set_task_comm(me, kbasename(bprm->filename), true); > + > + /* > + * If the original filename was empty, alloc_bprm() made up a path > + * that will probably not be useful to admins running ps or similar. > + * Let's fix it up to be something reasonable. > + */ > + if (bprm->comm_from_dentry) { > + rcu_read_lock(); > + /* The dentry name won't change while we hold the rcu read lock. */ > + __set_task_comm(me, smp_load_acquire(&bprm->file->f_path.dentry->d_name.name), > + true); This does not sound legit whatsoever as it would indicate all renames wait for rcu grace periods to end, which would be prettye weird. Even commentary above dentry_cmp states: * Be careful about RCU walk racing with rename: * use 'READ_ONCE' to fetch the name pointer. * * NOTE! Even if a rename will mean that the length * was not loaded atomically, we don't care. It may be this is considered tolerable, but there should be no difficulty getting a real name there? Regardless, the comment looks bogus.