linux-kernel - Re: [PATCH] allow disabling IMA at runtime

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090826170225.7574759e.akpm@linux-foundation.org>
Date:	Wed, 26 Aug 2009 17:02:25 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Kyle McMartin <kyle@...artin.ca>
Cc:	zohar@...ibm.com, linux-kernel@...r.kernel.org, eparis@...hat.com,
	torvalds@...ux-foundation.org, James Morris <jmorris@...ei.org>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH] allow disabling IMA at runtime

On Tue, 25 Aug 2009 22:10:05 -0400
Kyle McMartin <kyle@...artin.ca> wrote:

> From: Kyle McMartin <kyle@...hat.com>
> 
> Due to a memory leak in IMA that we're currently debugging in Fedora
> rawhide, it would be nice to be able to disable that support at runtime.
> Currently it's only able to be built in, and there's no toggle to avoid
> initializing it.
> 
> Provide one, in order to enhance debuggability. If a user can reboot a
> machine and edit its command line, one can do a far sight worse things
> than disabling a security precaution.
> 

nits:

> 
> ---
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 7936b80..0d1b1ed 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -926,6 +926,11 @@ and is between 256 and 4096 characters. It is defined in the file
>  	ihash_entries=	[KNL]
>  			Set number of hash buckets for inode cache.
>  
> +	ima=		[IMA]
> +			Format: { "0" | "1" }
> +			0 -- disable IMA.
> +			1 -- enable IMA. (default)
> +
>  	ima_audit=	[IMA]
>  			Format: { "0" | "1" }
>  			0 -- integrity auditing messages. (Default)
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 101c512..cc7603e 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -339,10 +339,27 @@ int ima_bprm_check(struct linux_binprm *bprm)
>  	return 0;
>  }
>  
> +static int ima_disabled = 0;
> +static int __init ima_enabled(char *str)
> +{
> +	unsigned long enabled;
> +
> +	if (!strict_strtoul(str, 0, &enabled))
> +		ima_disabled = enabled ? 0 : 1;
> +	return 1;
> +}

- documentation says "0 or 1" but the implementation says "0 or non-zero".

- implementation returns `1' whether or not the argument was
  successfully parsed.

  What happens if a __setup() functions returns non-1?

  <spends a while fossicking through prehistory and RustyCode>

  From my reading of kernel/params.c:parse_args(), every __setup()
  function which returns `1' should result in printk("%s: `%s' invalid
  for parameter `%s'), so I'm all confused and giving up.

> +__setup("ima=", ima_enabled);

Are we supposed to use core_param() nowadays?

>  static int __init init_ima(void)
>  {
>  	int error;
>  
> +	if (ima_disabled) {
> +		pr_info("IMA disabled at user request.\n");
> +		return 0;
> +	}
> +
>  	ima_iintcache_init();
>  	error = ima_init();
>  	ima_initialized = 1;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/