From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B9BCC433E0 for ; Tue, 7 Jul 2020 15:38:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 361B220738 for ; Tue, 7 Jul 2020 15:38:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728620AbgGGPh7 (ORCPT ); Tue, 7 Jul 2020 11:37:59 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:63502 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728194AbgGGPh7 (ORCPT ); Tue, 7 Jul 2020 11:37:59 -0400 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 067FVOBd141554; Tue, 7 Jul 2020 11:37:28 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 324ffe5v90-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jul 2020 11:37:28 -0400 Received: from m0098416.ppops.net (m0098416.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 067FVRd3141899; Tue, 7 Jul 2020 11:37:27 -0400 Received: from ppma02fra.de.ibm.com (47.49.7a9f.ip4.static.sl-reverse.com [159.122.73.71]) by mx0b-001b2d01.pphosted.com with ESMTP id 324ffe5v7e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jul 2020 11:37:27 -0400 Received: from pps.filterd (ppma02fra.de.ibm.com [127.0.0.1]) by ppma02fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 067F6pLA031946; Tue, 7 Jul 2020 15:37:25 GMT Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by ppma02fra.de.ibm.com with ESMTP id 322hd83nbt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jul 2020 15:37:25 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 067Fa8Q062390518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Jul 2020 15:36:08 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9816EA4054; Tue, 7 Jul 2020 15:36:08 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1D379A405F; Tue, 7 Jul 2020 15:36:05 +0000 (GMT) Received: from localhost.localdomain (unknown [9.85.200.130]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 7 Jul 2020 15:36:04 +0000 (GMT) Message-ID: <1594136164.23056.76.camel@linux.ibm.com> Subject: Re: [PATCH 0/4] Fix misused kernel_read_file() enums From: Mimi Zohar To: Kees Cook , James Morris Cc: Luis Chamberlain , Scott Branden , Greg Kroah-Hartman , "Rafael J. Wysocki" , Alexander Viro , Jessica Yu , Dmitry Kasatkin , "Serge E. Hallyn" , Casey Schaufler , "Eric W. Biederman" , Peter Zijlstra , Matthew Garrett , David Howells , Mauro Carvalho Chehab , Randy Dunlap , "Joel Fernandes (Google)" , KP Singh , Dave Olsthoorn , Hans de Goede , Peter Jones , Andrew Morton , Stephen Boyd , Paul Moore , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org Date: Tue, 07 Jul 2020 11:36:04 -0400 In-Reply-To: <20200707081926.3688096-1-keescook@chromium.org> References: <20200707081926.3688096-1-keescook@chromium.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-07-07_08:2020-07-07,2020-07-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 clxscore=1011 impostorscore=0 cotscore=-2147483648 malwarescore=0 mlxscore=0 adultscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 bulkscore=0 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007070113 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kees, On Tue, 2020-07-07 at 01:19 -0700, Kees Cook wrote: > Hi, > > In looking for closely at the additions that got made to the > kernel_read_file() enums, I noticed that FIRMWARE_PREALLOC_BUFFER > and FIRMWARE_EFI_EMBEDDED were added, but they are not appropriate > *kinds* of files for the LSM to reason about. They are a "how" and > "where", respectively. Remove these improper aliases and refactor the > code to adapt to the changes. Thank you for adding the missing calls and the firmware pre allocated buffer comment update. > > Additionally adds in missing calls to security_kernel_post_read_file() > in the platform firmware fallback path (to match the sysfs firmware > fallback path) and in module loading. I considered entirely removing > security_kernel_post_read_file() hook since it is technically unused, > but IMA probably wants to be able to measure EFI-stored firmware images, > so I wired it up and matched it for modules, in case anyone wants to > move the module signature checks out of the module core and into an LSM > to avoid the current layering violations. IMa has always verified kernel module signatures.  Recently appended kernel module signature support was added to IMA.  The same appended signature format is also being used to sign and verify the kexec kernel image. With IMA's new kernel module appended signature support and patch 4/4 in this series, IMA won't be limit to the finit_module syscall, but could support the init_module syscall as well. > > This touches several trees, and I suspect it would be best to go through > James's LSM tree. Sure. thanks! Mimi