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: <20171025150544.GC26762@glitch>
Date:   Wed, 25 Oct 2017 13:05:44 -0200
From:   "Bruno E. O. Meneguele" <brdeoliv@...hat.com>
To:     Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-integrity@...r.kernel.org, serge@...lyn.com,
        james.l.morris@...cle.com, dmitry.kasatkin@...il.com,
        rusty@...tcorp.com.au, jeyu@...nel.org
Subject: Re: [PATCH v3 2/2] ima: check signature enforcement against cmdline
 param instead of CONFIG

On 24-10, Mimi Zohar wrote:
> On Tue, 2017-10-24 at 15:37 -0200, Bruno E. O. Meneguele wrote:
> > When the user requests MODULE_CHECK policy and its kernel is compiled
> > with CONFIG_MODULE_SIG_FORCE not set, all modules would not load, just
> > those loaded in initram time. One option the user would have would be
> > set a kernel cmdline param (module.sig_enforce) to true, but the IMA
> > module check code doesn't rely on this value, it checks just
> > CONFIG_MODULE_SIG_FORCE.
> > 
> > This patch solves this problem checking for the exported value of
> > module.sig_enforce cmdline param intead of CONFIG_MODULE_SIG_FORCE,
> > which holds the effective value (CONFIG || param).
> > 
> > Signed-off-by: Bruno E. O. Meneguele <brdeoliv@...hat.com>
> > ---
> >  security/integrity/ima/ima_main.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> > index e4ab8ef8016e..d11a7fcc5c8b 100644
> > --- a/security/integrity/ima/ima_main.c
> > +++ b/security/integrity/ima/ima_main.c
> > @@ -356,12 +356,12 @@ void ima_post_path_mknod(struct dentry *dentry)
> >   */
> >  int ima_read_file(struct file *file, enum kernel_read_file_id read_id)
> >  {
> > +	bool sig_enforce = is_module_sig_enforced();
> > +
> >  	if (!file && read_id == READING_MODULE) {
> 
> The only reason for getting here is that you're using the old module
> load syscall.  Is there a reason for not using the new one, which
> passes the file descriptor?
> 
> thanks,
> 
> Mimi
> 

Basicaly because the way kmod handles compressed (gz/xz) modules. The
way it's today would require major changes in the code or some kind of
memfd_create() + xattrs reassignement in order to finit_module() be used
correctly.

Considering it would take some time to be accepted or even to figure out
the correct way to tackle it, the current IMA module check code works
aside kernel module signature validation, which is fine for now for me,
but has the problem that this patch tries to solve in the
CONFIG_MODULE_SIG_FORCE check (ignoring module.sig_enforce cmdline
param).

> > -#ifndef CONFIG_MODULE_SIG_FORCE
> > -		if ((ima_appraise & IMA_APPRAISE_MODULES) &&
> > +		if (!sig_enforce && (ima_appraise & IMA_APPRAISE_MODULES) &&
> >  		    (ima_appraise & IMA_APPRAISE_ENFORCE))
> >  			return -EACCES;	/* INTEGRITY_UNKNOWN */
> > -#endif
> >  		return 0;	/* We rely on module signature checking */
> >  	}
> >  	return 0;
> 
> 

-- 
bmeneg 
PGP Key: http://bmeneg.com/pubkey.txt

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ