Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4025145imm; Thu, 17 May 2018 20:38:02 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoN3yumjEsl8x/RlLBz4vr80mVACBICnnO41mPZ81FICJ3vNBZ9Q5PkNS7j2VxR+FfEABdk X-Received: by 2002:a63:7b15:: with SMTP id w21-v6mr365974pgc.268.1526614682115; Thu, 17 May 2018 20:38:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526614682; cv=none; d=google.com; s=arc-20160816; b=t+qxdBkKU9kuemXB9q7/upKR15m1cb6zOI8ndJkGyTO3Tw7MwEk8AyIX/rQrebjYOh yTAdW/EgO0l6js49X4RTVEZ2jzsioMPmXPsr6SV5R4tH8Yxvs/Cuoq7fthApep8KBfbx q0L87REQkBVfwbD//MOGpBnr6aR+Vy+/qlI2TlmX7JkJECFY3dmjOI74J6GLQqohRXKP 3Oqk9SZLyrR8sUQoP54Q8+QlMOxFyIhlTtPTEX82qH+PTqeGI2I+xDy5qJkAkYNRwM6l SfJNBtNvinXHx6eiCpCsLJdN2IpmL01UhEGDH0y5jr3zLVBtUXUSZfeodpBCsVq91Dni zJtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from :arc-authentication-results; bh=9nqH7RTif9Tb8wQ1Z1eDbP42Cooa1+0NGFQs5nNJUDA=; b=WfGqSXbomop1dMQHmgDaBH9+igxi4u8UxqY18KNI3me7lEfvgLV2o0X6oBuj3zd363 fgd6R1kWWOpKY2ofUgKVr/5DImXi1UQsA88ZSgAB2OgYHF79faysxA1hgq51Pbo+lcP4 PoKnNiyAqg1u61oTENShAWRtznDInJMAaDdlfBO7962uNwkgMJBSgcDWvBTbZ5fQ6Ft+ Lx//ZAD+2zNiyMQ5Pv9xKn0H1o0eHqFH1fMbAHxqWyjpUPb1Te8K+58afgITec+REYLd of2ETu6t/4yrXw1DZKfB1eA1qpk3B81gRwQZuv4hOGMzoMv70OEJ5TBsyf8bt/w7HsG2 /nfA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c86-v6si6652926pfl.319.2018.05.17.20.37.46; Thu, 17 May 2018 20:38:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752080AbeERDhg (ORCPT + 99 others); Thu, 17 May 2018 23:37:36 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:48325 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751698AbeERDhe (ORCPT ); Thu, 17 May 2018 23:37:34 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fJWCv-0006sY-Lz; Thu, 17 May 2018 21:37:29 -0600 Received: from [97.90.247.198] (helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fJWCu-00015t-Sx; Thu, 17 May 2018 21:37:29 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Casey Schaufler Cc: Mimi Zohar , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Howells , "Luis R . Rodriguez" , kexec@lists.infradead.org, Andres Rodriguez , Greg Kroah-Hartman , Ard Biesheuvel , Kees Cook References: <1526568530-9144-1-git-send-email-zohar@linux.vnet.ibm.com> <1526568530-9144-4-git-send-email-zohar@linux.vnet.ibm.com> <74c096ca-1ad1-799e-df3d-7b1b099333a7@schaufler-ca.com> Date: Thu, 17 May 2018 22:37:23 -0500 In-Reply-To: <74c096ca-1ad1-799e-df3d-7b1b099333a7@schaufler-ca.com> (Casey Schaufler's message of "Thu, 17 May 2018 17:24:36 -0700") Message-ID: <87y3ghhbws.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1fJWCu-00015t-Sx;;;mid=<87y3ghhbws.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=97.90.247.198;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18PowzMLgO4QJviA6fk2tNgB80cxd0ZtgI= X-SA-Exim-Connect-IP: 97.90.247.198 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa06.xmission.com X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,T_TooManySym_02, T_TooManySym_03,T_XMDrugObfuBody_08,XMGappySubj_01,XMSolicitRefs_0,XMSubLong autolearn=disabled version=3.4.1 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.5 XMGappySubj_01 Very gappy subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_03 6+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.1 XMSolicitRefs_0 Weightloss drug * 1.0 T_XMDrugObfuBody_08 obfuscated drug references X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Casey Schaufler X-Spam-Relay-Country: X-Spam-Timing: total 263 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 8 (3.2%), b_tie_ro: 6 (2.3%), parse: 1.00 (0.4%), extract_message_metadata: 17 (6.3%), get_uri_detail_list: 1.97 (0.7%), tests_pri_-1000: 7 (2.6%), tests_pri_-950: 1.23 (0.5%), tests_pri_-900: 1.01 (0.4%), tests_pri_-400: 21 (8.1%), check_bayes: 20 (7.7%), b_tokenize: 7 (2.6%), b_tok_get_all: 7 (2.5%), b_comp_prob: 2.0 (0.8%), b_tok_touch_all: 2.6 (1.0%), b_finish: 0.57 (0.2%), tests_pri_0: 198 (75.2%), check_dkim_signature: 0.46 (0.2%), check_dkim_adsp: 2.6 (1.0%), tests_pri_500: 6 (2.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Casey Schaufler writes: > On 5/17/2018 7:48 AM, Mimi Zohar wrote: >> In order for LSMs and IMA-appraisal to differentiate between the original >> and new syscalls (eg. kexec, kernel modules, firmware), both the original >> and new syscalls must call an LSM hook. >> >> Commit 2e72d51b4ac3 ("security: introduce kernel_module_from_file hook") >> introduced calling security_kernel_module_from_file() in both the original >> and new syscalls. Commit a1db74209483 ("module: replace >> copy_module_from_fd with kernel version") replaced these LSM calls with >> security_kernel_read_file(). >> >> Commit e40ba6d56b41 ("firmware: replace call to fw_read_file_contents() >> with kernel version") and commit b804defe4297 ("kexec: replace call to >> copy_file_from_fd() with kernel version") replaced their own version of >> reading a file from the kernel with the generic >> kernel_read_file_from_path/fd() versions, which call the pre and post >> security_kernel_read_file LSM hooks. >> >> Missing are LSM calls in the original kexec syscall and firmware sysfs >> fallback method. From a technical perspective there is no justification >> for defining a new LSM hook, as the existing security_kernel_read_file() >> works just fine. The original syscalls, however, do not read a file, so >> the security hook name is inappropriate. Instead of defining a new LSM >> hook, this patch defines security_kernel_read_blob() as a wrapper for >> the existing LSM security_kernel_file_read() hook. > > What a marvelous opportunity to bikeshed! > > I really dislike adding another security_ interface just because > the name isn't quite right. Especially a wrapper, which is just > code and execution overhead. Why not change security_kernel_read_file() > to security_kernel_read_blob() everywhere and be done? Nacked-by: "Eric W. Biederman" Nack on this sharing nonsense. These two interfaces do not share any code in their implementations other than the if statement to distinguish between the two cases. Casey you are wrong. We need something different here. Mimi a wrapper does not cut it. The code is not shared. Despite using a single function call today. If we want comprehensible and maintainable code in the security modules we need to split these two pieces of functionality apart. Eric