From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751144AbdIJGru (ORCPT ); Sun, 10 Sep 2017 02:47:50 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:42440 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750994AbdIJGrt (ORCPT ); Sun, 10 Sep 2017 02:47:49 -0400 Subject: Re: [GIT PULL] Security subsystem updates for 4.14 From: Mimi Zohar To: Linus Torvalds , James Morris Cc: Linux Kernel Mailing List , LSM List Date: Sun, 10 Sep 2017 02:46:24 -0400 In-Reply-To: References: 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-MML: disable x-cbid: 17091006-0040-0000-0000-000003557DEA X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17091006-0041-0000-0000-00000CD5945F Message-Id: <1505025984.3224.35.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-10_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709100104 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-09-07 at 11:19 -0700, Linus Torvalds wrote: > On Mon, Sep 4, 2017 at 3:29 AM, James Morris wrote: > > > > IMA: > > - A new integrity_read file operation method, avoids races when > > calculating file hashes > > Honestly, this seems really odd. > > It documents that it needs to be called with i_rwsem held exclusively, > and even has a lockdep assert to that effect (well, not really: the > code claims "exclusive", but the lockdep assert does not), but I'm not > actually seeing anybody doing it. > > Quite the reverse, I just see integrity_read_file() doing filp_open() > on the pathname and passing it to integrity_kernel_read() with no > locking. > > It really looks like just pure garbage to me. I pulled, and I'm not > unpulling the whole thing. I don't think it's been tested, and I don't > think it can be right. > > Tell me why I'm wrong, or tell me why that garbage made it in in the > first place? I'm really sorry for the long delay in responding.  I've been on vacation the last week, mostly without cell phone and very limited wifi access.  True, there is a side case where integrity_read_file() is being called without first taking the i_rwsem.  This side case permits signed x509 certificates to be loaded onto the trusted IMA/EVM keyrings, without verifying the file signature stored as security.ima/security.evm xattrs.  Basically, the xattr signatures can not be verified until the keys are loaded.  The main use case is embedded systems which do not have an initramfs, but have a specially crafted init script.  It requires enabling CONFIG_IMA_LOAD_X509 or CONFIG_EVM_LOAD_X509.  The new VFS integrity_read() file operation method would not be called. The main use case for the new VFS integrity_read() file operation method is to calculate the file hash, as Christoph described. Mimi