IMA appraisal against xz-compressed modules

IMA appraisal against xz-compressed modules

[Bruno E. O. Meneguele]

[-- Attachment #1: Type: multipart/signed, Size: 2149 bytes --]

Re: IMA appraisal against xz-compressed modules

[Mimi Zohar]

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.

> 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.

Mimi

> Well, thank you guys in advance.
> 
> /etc/ima/ima-policy:
> 
> # PROC_SUPER_MAGIC
> dont_measure fsmagic=0x9fa0
> # SYSFS_MAGIC
> dont_measure fsmagic=0x62656572
> # DEBUGFS_MAGIC
> dont_measure fsmagic=0x64626720
> # TMPFS_MAGIC
> dont_measure fsmagic=0x01021994
> # RAMFS_MAGIC
> dont_measure fsmagic=0x858458f6
> # SECURITYFS_MAGIC
> dont_measure fsmagic=0x73636673
> # MEASUREMENTS
> measure func=BPRM_CHECK
> measure func=FILE_MMAP mask=MAY_EXEC
> measure func=MODULE_CHECK uid=0
> 

Re: IMA appraisal against xz-compressed modules

[Bruno E. O. Meneguele]

[-- Attachment #1: Type: multipart/signed, Size: 3470 bytes --]

Re: IMA appraisal against xz-compressed modules

[Mimi Zohar]

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

Re: IMA appraisal against xz-compressed modules

[Bruno E. O. Meneguele]

[-- Attachment #1: Type: multipart/signed, Size: 3987 bytes --]

Re: IMA appraisal against xz-compressed modules

[Mimi Zohar]

On Thu, 2017-10-19 at 17:31 -0200, Bruno E. O. Meneguele wrote:
> On 19-10, Mimi Zohar wrote:
 
> > > 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?
> > 
> 
> Well, at first I thought it could stay as it is and just create a
> "getter" function, like "is_module_sig_enforced()", and use it on
> ima_main.c through module.h, since this code would be called to every
> module loaded in runtime.
> 
> If it's ok to you I can try to write a patch against integrity-next and
> see how it behaves.

Thanks!

Re: IMA appraisal against xz-compressed modules

[Bruno E. O. Meneguele]

[-- Attachment #1: Type: multipart/signed, Size: 1526 bytes --]