lkml.org 
[lkml]   [2015]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux Firmware Signing
On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > 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
* @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel file
* used by kexec
* @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an initramfs
* used by kexec

* The kernel reads files directly from the filesystem for a series of
* operations. The list of files the kernel reads from the filesystem are
* limited and each type of file consumed may have a different format and
* security vetting procedures. The kernel enables LSMs to vet for these files
* through a shared LSM hook prior to consumption. This list documents the
* different special kernel file types read by the kernel, it enables LSMs
* to vet for each differently if needed.
enum security_filecheck {
SECURITY_FILECHECK_UNSPEC,
SECURITY_FILECHECK_MODULE,
SECURITY_FILECHECK_SYSDATA,
SECURITY_FILECHECK_KEXEC_KERNEL,
SECURITY_FILECHECK_KEXEC_INITRAMFS,
};

Provided the MOK thing or alternative gets addressed we could also soon add
something for SELinux policy files but that needs to be discussed further
it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
this would likely need further discussion, its why I didn't list it above.

Luis


\
 
 \ /
  Last update: 2015-09-02 21:01    [W:0.136 / U:0.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site