Re: [PATCH 0/1] KEYS: Measure keys in trusted keyring

[Mimi Zohar <zohar@linux.ibm.com>]

On Thu, 2019-09-19 at 09:18 -0400, Sasha Levin wrote:
> We do not restrict end use of the kernel; this is one of the main
> reasons that the kernel is licensed under GPLv2 rather than GPLv3.
> Please see https://lwn.net/Articles/200422/ .

That's from a licensing perspective.  Linus has full control of what
is upstreamed.

> 
> We'd love to work with you on the technical aspects of this code to make
> it acceptable to the IMA maintainers, but this work can't just be NACKed
> based on a perceived end use of it.

Perhaps if more people/companies thought about how technology could be
abused, before creating it, we, as a society, wouldn't be where we are
today.

On 9/1 I commented on this patch set from a technical perspective,
saying:

IMA measures, appraises, and audits files based on policy[1].  If
you're going to measure keys, all of the code should be within the IMA
subdirectory.  The only code outside of the IMA subdirectory is either
an LSM or IMA hook.  If an LSM hook already exists, use it.  If an LSM
hook doesn't exist and the location is generic that other LSMs would
be interested, define a new LSM hook, otherwise define a new IMA hook.

For example, to measure /boot/cmdline, the rule is "measure
func=KEXEC_CMDLINE template=ima-buf".  A similar rule for measuring
keys would look something like "measure func=KEYS template=ima-buf
pcr=<number>".

Remember "ifdef's" don't belong in C code[2].  Normally a stub
function is defined in an include file to avoid ifdefs.

Mimi

[1] Documentation/ABI/testing/ima_policy
[2] Refer to Documentation/process/coding-style.rst section "21)
Conditional Compilation".