From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:54510 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932168AbeB0QSK (ORCPT ); Tue, 27 Feb 2018 11:18:10 -0500 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1RGE32x188713 for ; Tue, 27 Feb 2018 11:18:09 -0500 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0b-001b2d01.pphosted.com with ESMTP id 2gd7fgaa4t-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 27 Feb 2018 11:18:09 -0500 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 Feb 2018 16:18:05 -0000 Subject: Re: [PATCH v2 0/4] ima: unverifiable file signatures From: Mimi Zohar To: "Eric W. Biederman" Cc: linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, Miklos Szeredi , Seth Forshee , Dongsu Park , Alban Crequy , "Serge E . Hallyn" Date: Tue, 27 Feb 2018 11:17:58 -0500 In-Reply-To: <87k1uzw5e6.fsf@xmission.com> References: <1519335184-17808-1-git-send-email-zohar@linux.vnet.ibm.com> <87k1uzw5e6.fsf@xmission.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <1519748278.3562.394.camel@linux.vnet.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, 2018-02-26 at 20:08 -0600, Eric W. Biederman wrote: > Mimi Zohar writes: > > > For local filesystems, the kernel prevents files being executed from > > being modified. With IMA-measurement enabled, the kernel also emits > > audit "time of measure, time of use" messages for files opened for > > read, and subsequently opened for write. > > > > Files on fuse are initially measured, appraised, and audited. Although > > the file data can change dynamically any time, making re-measuring, > > re-appraising, or re-auditing pointless, this patch set attempts to > > differentiate between unprivileged non-init root and privileged > > mounted fuse filesystems. > > > > This patch set addresses three different scenarios: > > - Unprivileged non-init root mounted fuse filesystems are untrusted. > > Signature verification should always fail and re-measuring, > > re-appraising, re-auditing files makes no sense. > > > > Always enabled. > > > > - For privileged mounted filesystems in a "secure" environment, with a > > correctly enforced security policy, which is willing to assume the > > inherent risk of specific fuse filesystems, it is reasonable to > > re-measure, re-appraise, and re-audit files. > > > > Enabled by default to prevent breaking existing systems. > > > > - Privileged mounted filesystems unwilling to assume the risks and > > prefers to fail safe. > > > > Enabled based on policy. > > I really like the way the flags work in this patchset. > > There is a lot of other nit-picking and bike-shedding I would like to > do. However those are details specific to IMA. So my opion really > doesn't count. > > Those two flags set as you have them in the last patch make it possible > to slightly alter details of when they get set, that are in the perview > of filesystems without having too big a debate over them. > > The changes I imagine most easily are: > In fuse_fill_super: > if (!fc->allow_other) > sb->s_iflags |= SB_I_UNTRUSTED_MOUNTER; Right, as described, above, as the 2nd senario. > > In sget_user_ns: > if (sb->s_user_ns != &init_user_ns) > sb->s_iflags |= SB_I_UNTRUSTED_MOUNTER; The filesystems would then only set SB_I_IMA_UNVERIFIABLE_SIGNATURE. > > My biggest nitpick is I would be inclined to flip the sense of the > unverifiable_sigs policy. By default not trust and trust only if > a special command line option was given. But I realize this could > run into backwards compatibility concerns. And it is IMA specific so > not really my call. The boot command line policy option forces the system to fail safe. Reversing the default to fail unverifiable_sigs and only allow them based on policy, would not be a simple command line option, but would require a per filesystem rule. I agree with you, but as we're not breaking existing userspace, our only option is to audit/log the concern, as suggested by Linus in other threads.  It would be nice if we could audit/log it once per each mount. > > But the important part is what winds up in the core of ima. Baring > typo's I think you have something we can all live with. > > So double check yourself and let's start getting this merged. Sure. Mimi