[PATCH] kmod: Pass usermodehelper "-b" to use blacklist commands

[PATCH] kmod: Pass usermodehelper "-b" to use blacklist commands

[Kirill Tkhai]

User may want to prohibit autoloading of some modules,
which happens when someone in kernel calls request_module().
    
For comparison, udev considers blacklist even if corresponding
hardware presents in the system. In-kernel request_module()
functionality is rather similar to udev's, so user may want
to disallow it too.
    
Signed-off-by: Kirill Tkhai <ktkhai@parallels.com>
---
 kernel/kmod.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/kernel/kmod.c b/kernel/kmod.c
index 0ac67a5..68a4ca4 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -71,7 +71,7 @@ char modprobe_path[KMOD_PATH_LEN] = "/sbin/modprobe";
 
 static void free_modprobe_argv(struct subprocess_info *info)
 {
-	kfree(info->argv[3]); /* check call_modprobe() */
+	kfree(info->argv[4]); /* check call_modprobe() */
 	kfree(info->argv);
 }
 
@@ -85,7 +85,7 @@ static int call_modprobe(char *module_name, int wait)
 		NULL
 	};
 
-	char **argv = kmalloc(sizeof(char *[5]), GFP_KERNEL);
+	char **argv = kmalloc(sizeof(char *[6]), GFP_KERNEL);
 	if (!argv)
 		goto out;
 
@@ -95,9 +95,10 @@ static int call_modprobe(char *module_name, int wait)
 
 	argv[0] = modprobe_path;
 	argv[1] = "-q";
-	argv[2] = "--";
-	argv[3] = module_name;	/* check free_modprobe_argv() */
-	argv[4] = NULL;
+	argv[2] = "-b";
+	argv[3] = "--";
+	argv[4] = module_name;	/* check free_modprobe_argv() */
+	argv[5] = NULL;
 
 	info = call_usermodehelper_setup(modprobe_path, argv, envp, GFP_KERNEL,
 					 NULL, free_modprobe_argv, NULL);

Re: [PATCH] kmod: Pass usermodehelper "-b" to use blacklist commands

[Oleg Nesterov]

On 05/06, Kirill Tkhai wrote:
>
> User may want to prohibit autoloading of some modules,
> which happens when someone in kernel calls request_module().
>
> For comparison, udev considers blacklist even if corresponding
> hardware presents in the system. In-kernel request_module()
> functionality is rather similar to udev's, so user may want
> to disallow it too.

Personally, I am always nervous (perhaps too much) when it comes to the
user-visible changes like this.

And if a user/distro wants "-b" it can create a simple script which just
execs /sbin/modprobe with "-b" and overwrite /proc/sys/kernel/modprobe.

OTOH. What if /proc/sys/kernel/modprobe points to a binary which is not
/sbin/modprobe and doesn't expect "-b" ? This can break things.

I am not really arguing, but someone should ack this change ;)


As for correctness:

Reviewed-by: Oleg Nesterov <oleg@redhat.com>



> Signed-off-by: Kirill Tkhai <ktkhai@parallels.com>
> ---
>  kernel/kmod.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index 0ac67a5..68a4ca4 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -71,7 +71,7 @@ char modprobe_path[KMOD_PATH_LEN] = "/sbin/modprobe";
>
>  static void free_modprobe_argv(struct subprocess_info *info)
>  {
> -	kfree(info->argv[3]); /* check call_modprobe() */
> +	kfree(info->argv[4]); /* check call_modprobe() */
>  	kfree(info->argv);
>  }
>
> @@ -85,7 +85,7 @@ static int call_modprobe(char *module_name, int wait)
>  		NULL
>  	};
>
> -	char **argv = kmalloc(sizeof(char *[5]), GFP_KERNEL);
> +	char **argv = kmalloc(sizeof(char *[6]), GFP_KERNEL);
>  	if (!argv)
>  		goto out;
>
> @@ -95,9 +95,10 @@ static int call_modprobe(char *module_name, int wait)
>
>  	argv[0] = modprobe_path;
>  	argv[1] = "-q";
> -	argv[2] = "--";
> -	argv[3] = module_name;	/* check free_modprobe_argv() */
> -	argv[4] = NULL;
> +	argv[2] = "-b";
> +	argv[3] = "--";
> +	argv[4] = module_name;	/* check free_modprobe_argv() */
> +	argv[5] = NULL;
>
>  	info = call_usermodehelper_setup(modprobe_path, argv, envp, GFP_KERNEL,
>  					 NULL, free_modprobe_argv, NULL);
>
>

Re: [PATCH] kmod: Pass usermodehelper "-b" to use blacklist commands

[Andrew Morton]

On Tue, 6 May 2014 19:31:36 +0200 Oleg Nesterov <oleg@redhat.com> wrote:

> On 05/06, Kirill Tkhai wrote:
> >
> > User may want to prohibit autoloading of some modules,
> > which happens when someone in kernel calls request_module().
> >
> > For comparison, udev considers blacklist even if corresponding
> > hardware presents in the system. In-kernel request_module()
> > functionality is rather similar to udev's, so user may want
> > to disallow it too.
> 
> Personally, I am always nervous (perhaps too much) when it comes to the
> user-visible changes like this.
> 
> And if a user/distro wants "-b" it can create a simple script which just
> execs /sbin/modprobe with "-b" and overwrite /proc/sys/kernel/modprobe.
> 
> OTOH. What if /proc/sys/kernel/modprobe points to a binary which is not
> /sbin/modprobe and doesn't expect "-b" ? This can break things.
> 

Yup.  Perhaps the kernel should provide modprobe with a reliable way of
knowing "you were called by the kernel" (if there isn't presently a
way) and let modprobe work out what to do.

Re: [PATCH] kmod: Pass usermodehelper "-b" to use blacklist commands

[Rusty Russell]

Andrew Morton <akpm@linux-foundation.org> writes:
> On Tue, 6 May 2014 19:31:36 +0200 Oleg Nesterov <oleg@redhat.com> wrote:
>
>> On 05/06, Kirill Tkhai wrote:
>> >
>> > User may want to prohibit autoloading of some modules,
>> > which happens when someone in kernel calls request_module().
>> >
>> > For comparison, udev considers blacklist even if corresponding
>> > hardware presents in the system. In-kernel request_module()
>> > functionality is rather similar to udev's, so user may want
>> > to disallow it too.
>> 
>> Personally, I am always nervous (perhaps too much) when it comes to the
>> user-visible changes like this.
>> 
>> And if a user/distro wants "-b" it can create a simple script which just
>> execs /sbin/modprobe with "-b" and overwrite /proc/sys/kernel/modprobe.
>> 
>> OTOH. What if /proc/sys/kernel/modprobe points to a binary which is not
>> /sbin/modprobe and doesn't expect "-b" ? This can break things.
>> 
>
> Yup.  Perhaps the kernel should provide modprobe with a reliable way of
> knowing "you were called by the kernel" (if there isn't presently a
> way) and let modprobe work out what to do.

Indeed, this is a non-starter.

Cheers,
Rusty.