Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752799AbdGLOfH (ORCPT ); Wed, 12 Jul 2017 10:35:07 -0400 Received: from fieldses.org ([173.255.197.46]:33294 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750899AbdGLOfF (ORCPT ); Wed, 12 Jul 2017 10:35:05 -0400 Date: Wed, 12 Jul 2017 10:35:04 -0400 From: Bruce Fields To: Mimi Zohar Cc: jlayton@redhat.com, Jeff Layton , "Serge E. Hallyn" , Dmitry Kasatkin , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel Subject: Re: [PATCH v2] integrity: track mtime in addition to i_version for assessment Message-ID: <20170712143504.GB31196@fieldses.org> References: <20170707140530.30452-1-jlayton@kernel.org> <1499446642.4967.3.camel@poochiereds.net> <1499448249.3130.143.camel@linux.vnet.ibm.com> <1499449777.4852.3.camel@redhat.com> <1499457558.3130.173.camel@linux.vnet.ibm.com> <1499459718.4852.8.camel@redhat.com> <1499688612.6034.111.camel@linux.vnet.ibm.com> <1499822252.26839.5.camel@redhat.com> <1499862021.3904.23.camel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1499862021.3904.23.camel@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1918 Lines: 45 On Wed, Jul 12, 2017 at 08:20:21AM -0400, Mimi Zohar wrote: > Right, currently the only way of knowing is by looking at the IMA > measurement list to see if modified files are re-measured or, as you > said, by looking at the code. Who's actually using this, and do they do any kind of checks, or document the filesystem-specific limitations? --b. > > I started working on adding logging/audit messages, but have not yet > posted them.  A very preliminary set of patches is available from > https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity. > git/next-log-iversion-experimental. > > 2745b7be961a ima: indicate possibly missing file measurements or verification > 0c81a8c56153 security: define new LSM sb_post_new_mount hook > > Mimi > > > > > ext4 only provides a working i_version counter when you mount with "-o > > i_version", so it's trivial to tell there. xfs and btrfs also have > > functional i_version counter implementations, but there is no such > > mount option for them (it's always on there). NFSv4 and AFS can provide > > one too (as they're supplied by the server). > > > > Suppose I want to use IMA on something else (say, ubifs). How do I know > > whether I'm only going to get "initial file integrity verification and > > measurement" or whether it'll be updated after being written? > > > > Now, I happen to know that ubifs does _not_ support the i_version > > counter because I can poke through the kernel sources and tell, but how > > is Joe Random Linux User to know this? > > > > Does that not matter for some reason? Is there a whitelist of > > filesystems being maintained in some userland package? > > > > Sorry if it seems like I'm being dense here, but I really just don't > > understand how we can allow this code to be so cavalier about using the > > i_version counter without taking steps to ensure that it actually does > > a damned thing at all. > >