All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "Bruno E. O. Meneguele" <brdeoliv@redhat.com>
Cc: linux-integrity@vger.kernel.org, lwang@redhat.com
Subject: Re: IMA appraisal against xz-compressed modules
Date: Thu, 19 Oct 2017 10:20:40 -0400	[thread overview]
Message-ID: <1508422840.3268.7.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171018194936.GA10984@glitch>

On Wed, 2017-10-18 at 17:49 -0200, Bruno E. O. Meneguele wrote:
> On 14-10, Mimi Zohar wrote:
> > On Thu, 2017-10-12 at 10:55 -0400, Bruno E. O. Meneguele wrote:
> > > Hi, 
> > > 
> > > recently, while playing around with IMA modules check support, I notice
> > > that when the kernel was compiled/installed with XZ-compressed modules
> > > the IMA kernel infra returns -EACCESS on modules initialization. Let me
> > > detail a bit more:
> > > 
> > > I created the policy file (/etc/ima/ima-policy) with
> > > 
> > > measure func=MODULE_CHECK uid=0
> > > (... and more, policy file is attached)
> > > 
> > > then rebooted the kernel (that was built with XZ-compressed modules) and
> > > a bunch of modules didn't load, e.g.:
> > > 
> > > without ima-policy:
> > > # lsmod | wc -l
> > > 32
> > > 
> > > with it:
> > > # lsmod | wc -l
> > > 14
> > > 
> > > these 14 modules were all loaded during initram booting phase, but if I
> > > rmmod some of them and try to modprobe (strace output):
> > > 
> > > init_module(0x55b9bcc9bba0, 17763, "") = -1 EACCES (Permission denied)
> > > 
> > > The point is that there is no violation, because the error occurs right
> > > after kmod calls init_module() and the call follows to ima_read_file()
> > > (kernel tree: security/integrity/ima/ima_main.c) which returns -EACCES,
> > > since there is no 'file' structure available (init_module uses memory
> > > region only and not file descriptor).
> > 
> > IMA hashes/signatures are stored as xattrs, which requires a file
> > descriptor.  IMA only supports the new kernel module syscall, which
> > provides the file descriptor.
> > 
> 
> Patches from Thiago Bauerman
> (http://www.spinics.net/lists/linux-integrity/msg00243.html) could help
> to solve this, don't they?

True.  Initially we're introducing appended signature support for
kernel images.  Afterwards, perhaps we'll be able to use it to close
other appraisal gaps (e.g bpf).

> > > I notice this behavior using Fedora 26 (using SELinux as sec framework)
> > > and up-to-date kernel, the question is: should IMA kernel mechanism
> > > support memory regions integrity measurements, maybe following the steps
> > > that MODULE_SIGNATURE takes (that check for module signature through its
> > > mmap region), allowing compressed modules to be loaded? Or kernels built
> > > with XZ/GZ-compressed modules was never meant to be supported? Is it a
> > > bug or a possible enhancement?
> > 
> > If the IMA policy requires kernel modules to be signed, an appended
> > signature is permitted as long as the kernel is configured with
> > CONFIG_MODULE_SIG_FORCE enabled.
> > 
> 
> Right, but it's also possible to note that CONFIG_MODULE_SIG_FORCE is
> handled on kernel/module.c and has a kernel cmdline param,
> module.sig_enforce, that is read in case CONFIG_MODULE_SIG_FORCE is not
> set. Wouldn't be better ima_read_file depend on this cmdline param
> instead directly on the CONFIG? That way kernels compiled without
> CONFIG_MODULE_SIG_FORCE set as default would have the option to enable
> the kernel param and use their normal policy (MODULE_CHECK).
> 
> What do you think?

I wasn't aware of the module_param.  Thank you for pointing it out.
 "sig_enforce" is currently defined as static.  Should it be defined
as __initdata?

Mimi

  reply	other threads:[~2017-10-19 14:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12 14:55 IMA appraisal against xz-compressed modules Bruno E. O. Meneguele
2017-10-15  3:11 ` Mimi Zohar
2017-10-18 19:49   ` Bruno E. O. Meneguele
2017-10-19 14:20     ` Mimi Zohar [this message]
2017-10-19 19:31       ` Bruno E. O. Meneguele
2017-10-19 20:13         ` Mimi Zohar
2017-10-20 19:36           ` Bruno E. O. Meneguele

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=1508422840.3268.7.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=brdeoliv@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=lwang@redhat.com \
    /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.