Date: Mon, 13 Aug 2012 19:59:02 +0300 From: Efstratios Karatzas <gpf.kira@gmail.com> To: soc-status@freebsd.org Subject: Kernel Level File Integrity Checker report #12 Message-ID: <CAHywV0hstL21XSdDriFqwRC26QgBbM029oZG115bP9H42c_D7Q@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
During week #12: Most of the work done last week was focused in execution control. * Turned the sys/kern/kern_exec.c hack into a MAC hook. Pefs kernel module defines a MAC policy upon k-loading and uses the mac_vnode_check_exec hook. The issue with this hook is that in case of an executable that requires an interpreter, both the script file and the interpreter will be checked for the schg flag. * As a possible fix for the above behavior, I introduced a new MAC hook "mac_vnode_check_exec_noscript" that will not be called for script files as it is placed further down in do_execve(), right after we've looped back for the interpreter. I should note that I'm not convinced that this is the best approach to the issue at hand. * Instead of just checking the loading of libraries at rtld-elf/rtld.c with a dirty hack, I moved the checks for mmap(2) to kernel space. We make use of the mac_vnode_check_mmap hook to check if there's an attempt to mmap a vnode with the PROT_EXEC flag turned on. We require that the schg flag be turned on in that case. * Since for some strange reason the mac_vnode_check_mprotect hook is not actively used in the kernel, I introduced a new MAC hook, mac_vnode_set_mmap_maxprot, to guard against an attempt to mmap(2) a vnode and mprotect(2) those pages at a latter point with the PROT_EXEC flag. This new hook sets the MAX_PROT flag so that in the case of a vnode without the schg flag, the user will never be able to set the PROT_EXEC flag with mprotect(2). * Rework how nameids are used by the codebase. Next on the TODO list: The only TODO left is introducing DSA signature verification for .pefs.checksum when we mount the filesystem. Which means porting a library that supports asymmetric cryptography to the FreeBSD kernel; probably not doable in this week. Besides that, some code cleaning and documentation are in order. -- Efstratios "GPF" Karatzas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHywV0hstL21XSdDriFqwRC26QgBbM029oZG115bP9H42c_D7Q>