From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4B730959 for ; Mon, 1 Aug 2016 18:00:19 +0000 (UTC) Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B805A30F for ; Mon, 1 Aug 2016 18:00:18 +0000 (UTC) Received: by mail-ua0-f181.google.com with SMTP id k90so111824097uak.0 for ; Mon, 01 Aug 2016 11:00:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160801172920.GU3296@wotan.suse.de> References: <20160728165728.GR4541@io.lakedaemon.net> <1469830256.23563.200.camel@linux.vnet.ibm.com> <20160730163626.GP3296@wotan.suse.de> <1469934481.23563.274.camel@linux.vnet.ibm.com> <1469979098.23563.300.camel@linux.vnet.ibm.com> <1469986138.23563.312.camel@linux.vnet.ibm.com> <20160801172920.GU3296@wotan.suse.de> From: Andy Lutomirski Date: Mon, 1 Aug 2016 10:59:57 -0700 Message-ID: To: "Luis R. Rodriguez" Content-Type: text/plain; charset=UTF-8 Cc: Jason Cooper , "ksummit-discuss@lists.linuxfoundation.org" , James Bottomley , Mark Brown , Andy Lutomirski Subject: Re: [Ksummit-discuss] Last minute nominations: mcgrof and toshi List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Aug 1, 2016 at 10:29 AM, Luis R. Rodriguez 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