linux-kernel - Re: Linux Firmware Signing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150902184604.GB8051@wotan.suse.de>
Date:	Wed, 2 Sep 2015 20:46:04 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	Kees Cook <keescook@...omium.org>,
	David Woodhouse <dwmw2@...radead.org>,
	David Howells <dhowells@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	"Roberts, William C" <william.c.roberts@...el.com>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	"james.l.morris@...cle.com" <james.l.morris@...cle.com>,
	"serge@...lyn.com" <serge@...lyn.com>,
	Vitaly Kuznetsov <vkuznets@...hat.com>,
	Paul Moore <paul@...l-moore.com>,
	Eric Paris <eparis@...isplace.org>,
	SE Linux <selinux@...ho.nsa.gov>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	"Schaufler, Casey" <casey.schaufler@...el.com>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Peter Jones <pjones@...hat.com>, Takashi Iwai <tiwai@...e.de>,
	Ming Lei <ming.lei@...onical.com>, Joey Lee <jlee@...e.de>,
	Vojtěch Pavlík <vojtech@...e.com>,
	Kyle McMartin <kyle@...nel.org>,
	Seth Forshee <seth.forshee@...onical.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Johannes Berg <johannes@...solutions.net>,
	Jay Schulist <jschlst@...ba.org>,
	Daniel Borkmann <dborkman@...hat.com>,
	Alexei Starovoitov <ast@...mgrid.com>
Subject: Re: 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/