All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Joel Granados <joel.granados@kernel.org>,
	Luis Chamberlain <mcgrof@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] treewide: const qualify ctl_tables where applicable
Date: Thu, 9 Jan 2025 08:55:27 -0800	[thread overview]
Message-ID: <202501090854.40D19AD31@keescook> (raw)
In-Reply-To: <73f3c35b-35f1-433e-bd67-b428c3f2dd6e@t-8ch.de>

On Thu, Jan 09, 2025 at 04:25:06PM +0100, Thomas Weißschuh wrote:
> (Drop most recipients as it doesn't affect them)
> 
> On 2025-01-09 14:16:39+0100, Joel Granados wrote:
> > Add the const qualifier to all the ctl_tables in the tree except the
> > ones in ./net dir. The "net" sysctl code is special as it modifies the
> > arrays before passing it on to the registration function.
> > 
> > Constifying ctl_table structs will prevent the modification of
> > proc_handler function pointers as the arrays would reside in .rodata.
> > This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide:
> > constify the ctl_table argument of proc_handlers") constified all the
> > proc_handlers.
> > 
> > Created this by running an spatch followed by a sed command:
> > Spatch:
> >     virtual patch
> > 
> >     @
> >     depends on !(file in "net")
> >     disable optional_qualifier
> >     @
> >     identifier table_name;
> >     @@
> > 
> >     + const
> >     struct ctl_table table_name [] = { ... };
> > 
> > sed:
> >     sed --in-place \
> >       -e "s/struct ctl_table .table = &uts_kern/const struct ctl_table *table = \&uts_kern/" \
> >       kernel/utsname_sysctl.c
> > 
> > Signed-off-by: Joel Granados <joel.granados@kernel.org>
> > ---
> > This treewide commit builds upon the work Thomas began a few releases
> > ago [1], where he laid the groundwork for constifying ctl_tables. We
> > implement constification throughout the tree, with the exception of the
> > ctl_tables in the "net" directory. Those are special in that they treat
> > the ctl_table as non-const but we can take them at a later point.
> 
> The modifications in net/ are from register_net_sysctl_sz(), correct?
> Given that before modifying the table the code will already have called
> WARN() and thereby tainted and most likely panicked the system.
> If it is fine to crash the system I would argue it is also fine to just
> fail to register the sysctl. Then the modification would not be
> necessary anymore.
> 
> Something like (untested):
> 
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index 5a2a0df8ad91..5b0fff5fcaf9 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -496,12 +496,12 @@ struct ctl_table;
>  #ifdef CONFIG_SYSCTL
>  int net_sysctl_init(void);
>  struct ctl_table_header *register_net_sysctl_sz(struct net *net, const char *path,
> -					     struct ctl_table *table, size_t table_size);
> +					     const struct ctl_table *table, size_t table_size);
>  void unregister_net_sysctl_table(struct ctl_table_header *header);
>  #else
>  static inline int net_sysctl_init(void) { return 0; }
>  static inline struct ctl_table_header *register_net_sysctl_sz(struct net *net,
> -	const char *path, struct ctl_table *table, size_t table_size)
> +	const char *path, const struct ctl_table *table, size_t table_size)
>  {
>  	return NULL;
>  }
> diff --git a/net/sysctl_net.c b/net/sysctl_net.c
> index 19e8048241ba..754a3713eadb 100644
> --- a/net/sysctl_net.c
> +++ b/net/sysctl_net.c
> @@ -120,10 +120,10 @@ __init int net_sysctl_init(void)
>   *    data segment, and rather into the heap where a per-net object was
>   *    allocated.
>   */
> -static void ensure_safe_net_sysctl(struct net *net, const char *path,
> -				   struct ctl_table *table, size_t table_size)
> +static bool ensure_safe_net_sysctl(struct net *net, const char *path,
> +				   const struct ctl_table *table, size_t table_size)
>  {
> -	struct ctl_table *ent;
> +	const struct ctl_table *ent;
>  
>  	pr_debug("Registering net sysctl (net %p): %s\n", net, path);
>  	ent = table;
> @@ -155,18 +155,20 @@ static void ensure_safe_net_sysctl(struct net *net, const char *path,
>  		WARN(1, "sysctl %s/%s: data points to %s global data: %ps\n",
>  		     path, ent->procname, where, ent->data);
>  
> -		/* Make it "safe" by dropping writable perms */
> -		ent->mode &= ~0222;
> +		return false;
>  	}
> +
> +	return true;
>  }

Yeah, I like this solution. Perhaps update the WARN to say the sysctl is
being ignored?

-- 
Kees Cook

  reply	other threads:[~2025-01-09 16:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-09 13:16 [PATCH] treewide: const qualify ctl_tables where applicable Joel Granados
2025-01-09 13:16 ` Joel Granados
2025-01-09 14:50 ` Steven Rostedt
2025-01-09 14:50   ` Steven Rostedt
2025-01-09 14:58 ` Jani Nikula
2025-01-09 14:58   ` Jani Nikula
2025-01-09 15:00 ` Martin K. Petersen
2025-01-09 15:00   ` Martin K. Petersen
2025-01-09 15:08 ` ✗ Fi.CI.BUILD: failure for " Patchwork
2025-01-09 15:25 ` [PATCH] " Thomas Weißschuh
2025-01-09 16:55   ` Kees Cook [this message]
2025-01-10 14:12   ` Joel Granados
2025-01-09 15:45 ` Corey Minyard
2025-01-09 15:45   ` Corey Minyard
2025-01-09 15:51 ` Darrick J. Wong
2025-01-09 15:51   ` Darrick J. Wong
2025-01-09 16:10 ` ✓ CI.Patch_applied: success for " Patchwork
2025-01-09 16:11 ` ✗ CI.checkpatch: warning " Patchwork
2025-01-10 11:40   ` Joel Granados
2025-01-09 16:12 ` ✓ CI.KUnit: success " Patchwork
2025-01-09 16:20 ` ✗ CI.Build: failure " Patchwork
2025-01-10 11:38   ` Joel Granados
2025-01-09 18:05 ` [PATCH] " Song Liu
2025-01-09 18:05   ` Song Liu
     [not found] ` <501b718d1bd046bf3eb1932b11627e4cec6194f992124722840145bed109ac0a@mail.kernel.org>
     [not found]   ` <fnrup4bdfgoeiy3nfsl56juhqjrnstntf4fg5jrcdxv226ehqp@alrqzkyfw6sl>
2025-01-10 17:05     ` Daniel Xu
2025-01-13  8:44       ` Joel Granados
     [not found]     ` <Z4TnZXCjgCIGEfsR@pathway.suse.cz>
     [not found]       ` <42gh2e7ckwjcccorbrapeos42n4yr22koqotsu7qithb7cxl6x@ynn6yr5h7dtb>
2025-02-18 10:35         ` Joel Granados
2025-01-10 17:13 ` Dixit, Ashutosh
2025-01-10 17:13   ` Dixit, Ashutosh

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=202501090854.40D19AD31@keescook \
    --to=kees@kernel.org \
    --cc=joel.granados@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=mcgrof@kernel.org \
    /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.