On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:

On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez [off-list ref] wrote:

quoted

On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:

quoted

quoted

OK great, I think that instead of passing the actual routine name we should
instead pass an enum type for to the LSM, that'd be easier to parse and we'd
then have each case well documented. Each LSM then could add its own
documetnation for this and can switch on it. If we went with a name we'd have
to to use something like __func__ and then parse that, its not clear if we need
to get that specific.

Agreed.  IMA already defines an enumeration.

/* IMA policy related functions */
enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
                 FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };

We want something that is not only useful for IMA but any other LSM,
and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
be broad, perhaps its best we define then a generic set of enums to
which IMA can map them to then and let it decide. This would ensure
that the kernel defines each use caes for file inspection carefully,
documents and defines them and if an LSM wants to bunch a set together
it can do so easily with a switch statement to map set of generic
file checks in kernel to a group it already handles.

For instance at least in the short term we'd try to unify:

security_kernel_fw_from_file()
security_kernel_module_from_file()

to perhaps:

security_kernel_from_file()

As far, as far as I can tell, the only ones we'd be ready to start
grouping immediately or with small amount of work rather soon:

/**
 *
 * enum security_filecheck - known kernel security file checks types
 *
 * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
 * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel module
 * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
 *      file or a system data file read from /lib/firmware/* by firmware_class

I'd prefer a distinct category for firmware, as it carries an
implication that it is an executable blob of some sort (I know not all
are, though).

The ship has sailed in terms of folks using frimrware API for things
that are not-firmware per se. The first one I am aware of was the
EEPROM override for the p54 driver. The other similar one was CPU
microcode, but that's a bit more close to home with "firmware". We
could ask users on the new system data request API I am building
to describe the type of file being used, as I agree differentiating
this for security purposes might be important. So other than just
file type we could have sub type category, then we could have, 

SECURITY_FILECHECK_SYSDATA, and then:

SECURITY_FILE_SYSDATA_FW
SECURITY_FILE_SYSDATA_MICROCODE
SECURITY_FILE_SYSDATA_EEPROM
SECURITY_FILE_SYSDATA_POLICY (for 802.11 regulatory I suppose)

If we do this then we could juse have:

SECURITY_FILECHECK_KEXEC and on that have substypes:

SECURITY_FILE_KEXEC_KERNEL
SECURITY_FILE_KEXEC_INITRAMFS

Would that be desirable and help grow this to be easily extensible?

  Luis