All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tycho Andersen <tycho@tycho.pizza>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Aleksa Sarai" <cyphar@cyphar.com>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Christian Brauner" <brauner@kernel.org>,
	"Jan Kara" <jack@suse.cz>, "Kees Cook" <kees@kernel.org>,
	"Jeff Layton" <jlayton@kernel.org>,
	"Chuck Lever" <chuck.lever@oracle.com>,
	"Alexander Aring" <alex.aring@gmail.com>,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	"Tycho Andersen" <tandersen@netflix.com>,
	"Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>
Subject: Re: [RFC] exec: add a flag for "reasonable" execveat() comm
Date: Fri, 27 Sep 2024 08:56:20 -0600	[thread overview]
Message-ID: <ZvbHlChEmj35+jHF@tycho.pizza> (raw)
In-Reply-To: <87h6a1xilx.fsf@email.froward.int.ebiederm.org>

On Fri, Sep 27, 2024 at 09:43:22AM -0500, Eric W. Biederman wrote:
> Tycho Andersen <tycho@tycho.pizza> writes:
> 
> > On Wed, Sep 25, 2024 at 09:09:18PM -0500, Eric W. Biederman wrote:
> >> Tycho Andersen <tycho@tycho.pizza> writes:
> >> 
> >> > Yep, I did this for the test above, and it worked fine:
> >> >
> >> >         if (bprm->fdpath) {
> >> >                 /*
> >> >                  * If fdpath was set, execveat() 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.
> >> >                  */
> >> >                 struct path root;
> >> >                 char *path, buf[1024];
> >> >
> >> >                 get_fs_root(current->fs, &root);
> >> >                 path = __d_path(&bprm->file->f_path, &root, buf, sizeof(buf));
> >> >
> >> >                 __set_task_comm(me, kbasename(path), true);
> >> >         } else {
> >> >                 __set_task_comm(me, kbasename(bprm->filename), true);
> >> >         }
> >> >
> >> > obviously we don't want a stack allocated buffer, but triggering on
> >> > ->fdpath != NULL seems like the right thing, so we won't need a flag
> >> > either.
> >> >
> >> > The question is: argv[0] or __d_path()?
> >> 
> >> You know.  I think we can just do:
> >> 
> >> 	BUILD_BUG_ON(DNAME_INLINE_LEN >= TASK_COMM_LEN);
> >> 	__set_task_comm(me, bprm->file->f_path.dentry->d_name.name, true);
> >> 
> >> Barring cache misses that should be faster and more reliable than what
> >> we currently have and produce the same output in all of the cases we
> >> like, and produce better output in all of the cases that are a problem
> >> today.
> >> 
> >> Does anyone see any problem with that?
> >
> > Nice, this works great. We need to drop the BUILD_BUG_ON() since it is
> > violated in today's tree, but I think this is safe to do anyway since
> > __set_task_comm() does strscpy_pad(tsk->comm, buf, sizeof(tsk->comm)).
> 
> Doh.  I simply put the conditional in the wrong order.  That should have
> been:
> 	BUILD_BUG_ON(TASK_COMM_LEN > DNAME_INLINE_LEN);
> 
> Sorry I was thinking of the invariant that needs to be preserved rather
> than the bug that happens.

Thanks, I will include that. Just for my own education: this is still
*safe* to do, because of _pad, it's just that it is a userspace
visible break if TASK_COMM_LEN > DNAME_INLINE_LEN is ever true?

Tycho

  reply	other threads:[~2024-09-27 14:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-24 14:10 [RFC] exec: add a flag for "reasonable" execveat() comm Tycho Andersen
2024-09-24 17:39 ` Eric W. Biederman
2024-09-24 21:37   ` Kees Cook
2024-09-24 22:59     ` Tycho Andersen
2024-09-25 13:12       ` Eric W. Biederman
2024-09-25 15:50   ` Aleksa Sarai
2024-09-25 21:20     ` Tycho Andersen
2024-09-26  2:09       ` Eric W. Biederman
2024-09-27 14:07         ` Tycho Andersen
2024-09-27 14:43           ` Eric W. Biederman
2024-09-27 14:56             ` Tycho Andersen [this message]
2024-09-27 15:38               ` Eric W. Biederman
2024-10-02 14:34   ` Zbigniew Jędrzejewski-Szmek
2024-10-09 14:41     ` Tycho Andersen
2024-10-14 21:13       ` Kees Cook
2024-10-17 14:34         ` Tycho Andersen
2024-10-17 15:47           ` Kees Cook
2024-10-17 20:38             ` Tycho Andersen
2024-09-25  8:31 ` Christian Brauner
2024-09-25 13:18   ` Eric W. Biederman
2024-09-25 14:53     ` Christian Brauner
  -- strict thread matches above, loose matches on Subject: below --
2024-09-25 16:44 Alexey Dobriyan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZvbHlChEmj35+jHF@tycho.pizza \
    --to=tycho@tycho.pizza \
    --cc=alex.aring@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=cyphar@cyphar.com \
    --cc=ebiederm@xmission.com \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tandersen@netflix.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zbyszek@in.waw.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.