On Thu, 2016-02-04 at 10:15 -0800, Kees Cook wrote: > On Wed, Feb 3, 2016 at 11:06 AM, Mimi Zohar <zohar at linux.vnet.ibm.com> wrote: > > For a while it was looked down upon to directly read files from Linux. > > These days there exists a few mechanisms in the kernel that do just this > > though to load a file into a local buffer. There are minor but important > > checks differences on each, we should take all the best practices from > > each of them, generalize them and make all places in the kernel that > > read a file use it.[1] > > > > One difference is the method for opening the file. In some cases we > > have a file, while in other cases we have a pathname or a file descriptor. > > > > Another difference is the security hook calls, or lack of them. In > > some versions there is a post file read hook, while in others there > > is a pre file read hook. > > > > This patch set attempts to resolve these differences. It does not attempt > > to merge the different methods of opening a file, but defines a single > > common kernel file read function with two wrappers. In addition, as none > > of the upstreamed LSMs define either a kernel_module_from_file or a > > kernel_fw_from_file hook, this patch set removes these hooks and the > > associated functions. The ima_module_check() and ima_fw_from_file() > > functions are renamed and called from the pre and post kernel_read_file > > security functions respectively. > > I'm very happy about the pre and post hooks; this solves the primary > problem I'd had when comparing the firmware and module hooks. Thanks! Thank you for reviewing the patches! > Once this series is in -next, I'll resend my rebased "loadpin" LSM. I was looking for this reference, when writing the patch description for modules, but couldn't remember it. Commit 2e72d51 "security: introduce kernel_module_from_file hook" patch description references Chrome OS. Thanks! Mimi