Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi

[Andy Lutomirski <luto@amacapital.net>]

On Mon, Aug 1, 2016 at 10:29 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Sun, Jul 31, 2016 at 11:20:08AM -0700, Andy Lutomirski wrote:
>> If IMA doesn't want or need to verify the purpose of the loaded file, fine.
>
> So other than origin you are indicating a proper LSM that would want to vet firmware
> should want purpose ? Is that right?

An security policy that wants to provide strong protection should
verify that whatever file is being loaded is being used for its
authorized purpose.  The wireless regulatory subsystem should only
load data signed by the wifi regulatory key, the iwlwifi driver should
only accept firmware signed by the system *for the purpose of being
used as iwlwifi firmware* (or perhaps signed by Intel), the nouveau
driver should accept files signed for the purpose of being used as
nvidia firmware and should reject things that are signed by Intel,
etc.

> If so I'd like to understand this suggestion
> a bit better given we already have. So we have:
>
> #define __kernel_read_file_id(id) \
>         id(UNKNOWN, unknown)            \
>         id(FIRMWARE, firmware)          \
>         id(FIRMWARE_PREALLOC_BUFFER, firmware)  \
>         id(MODULE, kernel-module)               \
>         id(KEXEC_IMAGE, kexec-image)            \
>         id(KEXEC_INITRAMFS, kexec-initramfs)    \
>         id(POLICY, security-policy)             \
>         id(MAX_ID, )
>
>
> #define __fid_enumify(ENUM, dummy) READING_ ## ENUM,
> #define __fid_stringify(dummy, str) #str,
>
> enum kernel_read_file_id {
>         __kernel_read_file_id(__fid_enumify)
> };
>
> extern int kernel_read_file_from_path(char *, void **, loff_t *, loff_t,
>                                       enum kernel_read_file_id);
>
> Are you saying FIRMWARE id is not sufficient ? What would be an example
> purpose be here for FIRMWARE ?

The string "iwlwifi-8265-21.ucode" would be a reasonable purpose, I
think.  It could make sense to split out the vendor, too:

.type = FIRMWARE,
.vendor = "Intel",
.purpose = "iwlwifi-8265-21.ucode",

then distro policy could know to accept a file signed by Intel
(because "Intel" would be mapped in some table to a public key), a
file signed by the distro key where the signature (using PKCS#7
auxiliarry data (or whatever it's called) or some other simpler
protocol) indicates that the signed object is "iwlwifi-8265-21.ucode",
or perhaps an IMA-verified file with an appropriate absolute path.

Mimi, I'm curious: I don't fully understand what is covered by IMA
policy.  How does the IMA kernel_read_file stuff deal with symlinks?
For example, if I symlink /lib/firmware/iwlwifi-8265-21.ucode to
/home/badguy/iwlwifi-8265-21.ucode, what happens?  What if I symlink
/lib/firmware/iwlwifi-8265-21.ucode to /home/badguy/something_else?
Or even /lib/modules/kernel/foo/bar.ko to /home/badguy/evil.ko?  The
interesting case is where the "badguy" user is duly authorized to
write to /home/badguy and holds whatever keys may be needed.

--Andy