Received: by 10.223.176.46 with SMTP id f43csp1055630wra; Wed, 24 Jan 2018 09:54:24 -0800 (PST) X-Google-Smtp-Source: AH8x225NnynWudJsH+CKwiM1fTBXamfQYQsvjxnsYB7/fmyI00S0EtQAzme/DCVhvuPLRUHLzVCC X-Received: by 10.99.104.200 with SMTP id d191mr11323472pgc.98.1516816464239; Wed, 24 Jan 2018 09:54:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516816464; cv=none; d=google.com; s=arc-20160816; b=kbrMdYx4AFo+nEZxIj63vbUSthtlMAJtJUmT3eUVi83O51oY8hmqCQc3e4Pca9ZaK1 E4ODGZnC/mTM24EMCoI++i7P+tTQN1eevajQuxQgA3GcgVPZ6qIeWmAo4r1n3LIhUATq RkkqwX0DULxndFonveGe5Ecf58ni5HZDFwHwLRAVOfzQrkZUB9zPqb29t0z/miV32R11 oI5KcK+Ky2kIVbd038gkRpYl/SIdTcIG6Jptq+X1X5f0/DiDMl3AeUaUnzODvTrIld2G cBNbQHpjWjiX1H/mBEOEP9mtl3vnkJqxO4jxFp33Zx0N+NiVPZFCibhs/3Os6t/LPg74 u/XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=0JLOTJw8IynFevQyrezQIbvTbY2Sxo8nOQ+hEhAVsFg=; b=OVYBdruPWou+YkmZrEAQPh3g+u+lDQkOe5q306UmEvjQsWGXL45dT61tg1eBeTpcEw HSdgiL3hrtCTw1a1FTTEOAz+NW8OqnOgWRwkIYjd6GOga4GMgy2FNORf7Hq9cIkOhDfL TAc0i+XPsXidCcwyIXe6L6Lg1Ql/gOxRi0chIMHIckGompE5DbaRb+hfCxVAJ7smf8a5 DRkkixqpeE4AQA4PtogE9w8j1fSeDEeg/kAJk9qSB5FLwSLP/M5P7TL1pJdod7Y2ZlkU iwi8Z5LLZ3LFUrpl9Udv8SfaBVWXkFX1kIz23aIRB1XT/PKjLWEjr2lJf/8+hqv8B99V DT3A== 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 q188si398888pga.444.2018.01.24.09.54.10; Wed, 24 Jan 2018 09:54:24 -0800 (PST) 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 S965011AbeAXRxR (ORCPT + 99 others); Wed, 24 Jan 2018 12:53:17 -0500 Received: from h2.hallyn.com ([78.46.35.8]:47944 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964850AbeAXRxQ (ORCPT ); Wed, 24 Jan 2018 12:53:16 -0500 Received: by h2.hallyn.com (Postfix, from userid 1001) id 4D68B1200AD; Wed, 24 Jan 2018 11:53:14 -0600 (CST) Date: Wed, 24 Jan 2018 11:53:14 -0600 From: "Serge E. Hallyn" To: Seth Forshee Cc: Alban Crequy , alban@kinvolk.io, dongsu@kinvolk.io, iago@kinvolk.io, linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, miklos@szeredi.hu, viro@zeniv.linux.org.uk, zohar@linux.vnet.ibm.com, dmitry.kasatkin@gmail.com, james.l.morris@oracle.com, serge@hallyn.com, hch@infradead.org Subject: Re: [RFC PATCH v3 2/2] ima: force re-appraisal on filesystems with FS_IMA_NO_CACHE Message-ID: <20180124175314.GB29811@mail.hallyn.com> References: <20180122162452.8756-1-alban@kinvolk.io> <20180122162452.8756-3-alban@kinvolk.io> <20180122222422.GB18882@ubuntu-xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180122222422.GB18882@ubuntu-xps13> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Seth Forshee (seth.forshee@canonical.com): > On Mon, Jan 22, 2018 at 05:24:52PM +0100, Alban Crequy wrote: > > From: Alban Crequy > > > > This patch forces files to be re-measured, re-appraised and re-audited > > on file systems with the feature flag FS_IMA_NO_CACHE. In that way, > > cached integrity results won't be used. > > > > How to test this: > > > > The test I did was using a patched version of the memfs FUSE driver > > [1][2] and two very simple "hello-world" programs [4] (prog1 prints > > "hello world: 1" and prog2 prints "hello world: 2"). > > > > I copy prog1 and prog2 in the fuse-memfs mount point, execute them and > > check the sha1 hash in > > "/sys/kernel/security/ima/ascii_runtime_measurements". > > > > My patch on the memfs FUSE driver added a backdoor command to serve > > prog1 when the kernel asks for prog2 or vice-versa. In this way, I can > > exec prog1 and get it to print "hello world: 2" without ever replacing > > the file via the VFS, so the kernel is not aware of the change. > > > > The test was done using the branch "alban/fuse-flag-ima-nocache-v3" [3]. > > > > Step by step test procedure: > > > > 1. Mount the memfs FUSE using [2]: > > rm -f /tmp/memfs-switch* ; memfs -L DEBUG /mnt/memfs > > > > 2. Copy prog1 and prog2 using [4] > > cp prog1 /mnt/memfs/prog1 > > cp prog2 /mnt/memfs/prog2 > > > > 3. Lookup the files and let the FUSE driver to keep the handles open: > > dd if=/mnt/memfs/prog1 bs=1 | (read -n 1 x ; sleep 3600 ) & > > dd if=/mnt/memfs/prog2 bs=1 | (read -n 1 x ; sleep 3600 ) & > > > > 4. Check the 2 programs work correctly: > > $ /mnt/memfs/prog1 > > hello world: 1 > > $ /mnt/memfs/prog2 > > hello world: 2 > > > > 5. Check the measurements for prog1 and prog2: > > $ sudo cat /sys/kernel/security/ima/ascii_runtime_measurements \ > > | grep /mnt/memfs/prog > > 10 [...] ima-ng sha1:ac14c9268cd2[...] /mnt/memfs/prog1 > > 10 [...] ima-ng sha1:799cb5d1e06d[...] /mnt/memfs/prog2 > > > > 6. Use the backdoor command in my patched memfs to redirect file > > operations on file handle 3 to file handle 2: > > rm -f /tmp/memfs-switch* ; touch /tmp/memfs-switch-3-2 > > > > 7. Check how the FUSE driver serves different content for the files: > > $ /mnt/memfs/prog1 > > hello world: 2 > > $ /mnt/memfs/prog2 > > hello world: 2 > > > > 8. Check the measurements: > > sudo cat /sys/kernel/security/ima/ascii_runtime_measurements \ > > | grep /mnt/memfs/prog > > > > Without the patch, there are no new measurements, despite the FUSE > > driver having served different executables. > > > > With the patch, I can see additional measurements for prog1 and prog2 > > with the hashes reversed when the FUSE driver served the alternative > > content. > > > > [1] https://github.com/bbengfort/memfs > > [2] https://github.com/kinvolk/memfs/commits/alban/switch-files > > [3] https://github.com/kinvolk/linux/commits/alban/fuse-flag-ima-nocache-v3 > > [4] https://github.com/kinvolk/fuse-userns-patches/commit/cf1f5750cab0 > > > > Cc: linux-kernel@vger.kernel.org > > Cc: linux-integrity@vger.kernel.org > > Cc: linux-security-module@vger.kernel.org > > Cc: linux-fsdevel@vger.kernel.org > > Cc: Miklos Szeredi > > Cc: Alexander Viro > > Cc: Mimi Zohar > > Cc: Dmitry Kasatkin > > Cc: James Morris > > Cc: "Serge E. Hallyn" > > Cc: Seth Forshee > > Cc: Christoph Hellwig > > Tested-by: Dongsu Park > > Signed-off-by: Alban Crequy > > I like this approach as it doesn't require any IMA policy changes to be > effective. I'm not sure about the flag name (in my mind it would > describe the fs property and not be specifically giving instructions to > IMA), but if others are happy with it I won't complain. Purely internal name at least, so if we come up with a better name we can trivially change it.