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? > > 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? > 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 > > > -- bmeneg PGP Key: http://bmeneg.com/pubkey.txt
Attachment:
signature.asc
Description: PGP signature
