Skip site navigation (1)Skip section navigation (2)
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>