From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from h2.hallyn.com ([78.46.35.8]:59580 "EHLO mail.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030839AbeBNPQj (ORCPT ); Wed, 14 Feb 2018 10:16:39 -0500 Date: Wed, 14 Feb 2018 09:16:37 -0600 From: "Serge E. Hallyn" To: Mimi Zohar Cc: "Serge E. Hallyn" , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, Miklos Szeredi , Seth Forshee , "Eric W . Biederman" , Dongsu Park , Alban Crequy Subject: Re: [RFC PATCH 2/4] ima: fail signature verification on unprivileged & untrusted filesystems Message-ID: <20180214151637.GA2671@mail.hallyn.com> References: <1518615315-7162-1-git-send-email-zohar@linux.vnet.ibm.com> <1518615315-7162-2-git-send-email-zohar@linux.vnet.ibm.com> <20180214144903.GA1953@mail.hallyn.com> <1518620899.5667.10.camel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1518620899.5667.10.camel@linux.vnet.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Quoting Mimi Zohar (zohar@linux.vnet.ibm.com): > On Wed, 2018-02-14 at 08:49 -0600, Serge E. Hallyn wrote: > > Quoting Mimi Zohar (zohar@linux.vnet.ibm.com): > > > Files on untrusted filesystems, such as fuse, can change at any time, > > > making the measurement(s) and by extension signature verification > > > meaningless. > > > > > > FUSE can be mounted by unprivileged users either today with fusermount > > > installed with setuid, or soon with the upcoming patches to allow FUSE > > > mounts in a non-init user namespace. > > > > > > This patch always fails the file signature verification on unprivileged > > > and untrusted filesystems. To also fail file signature verification on > > > > Why only untrusted? Fuse could cause the same issue if it just > > messes up when mounted from init userns right? > > Right, whether it is an unprivileged mount or not, fuse can return > whatever it wants, whenever it wants. �IMA can calculate the file hash > based based on what it reads, but fuse can return whatever it wants on > subsequent reads. Ok but your patch seems to let privileged fuse mounts slide? (see below) > Refer to the discussion with Linus -�http://kernsec.org/pipermail/linu > x-security-module-archive/2018-February/005200.html > > > > privileged, untrusted filesystems requires a custom policy. > > > > (I'm not saying you shouldn't do this, but) does this mean that > > a container whose rootfs is fuse-mounted by the unprivileged user > > cannot possibly use IMA? > > How would you suggest to differentiate between your unprivileged fuse > mounts from unintended, unintended malicious ones? I wouldn't. > The remaining patches are policy based. > > > Good thing we can partially work around that by intercepting real > > mount calls with Tycho's new patchset :) > > Can you provide a little more details? It would allow a container runtime to intercept mount(2) and perform a real mount on the user's behalf. Assuming the runtime is privileged, of course, otherwise it would intercept and do a fuse mount which is no help here :) https://lkml.org/lkml/2018/2/4/28 > thanks, > > Mimi > > > > > > (This patch is based on Alban Crequy's use of fs_flags and patch > > > description.) > > > > > > Signed-off-by: Mimi Zohar > > > Cc: Miklos Szeredi > > > Cc: Seth Forshee > > > Cc: Eric W. Biederman > > > Cc: Dongsu Park > > > Cc: Alban Crequy > > > Cc: "Serge E. Hallyn" > > > --- > > > include/linux/fs.h | 1 + > > > security/integrity/ima/ima_appraise.c | 10 +++++++++- > > > 2 files changed, 10 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > > index 2a815560fda0..faffe4aab43d 100644 > > > --- a/include/linux/fs.h > > > +++ b/include/linux/fs.h > > > @@ -2069,6 +2069,7 @@ struct file_system_type { > > > #define FS_BINARY_MOUNTDATA 2 > > > #define FS_HAS_SUBTYPE 4 > > > #define FS_USERNS_MOUNT 8 /* Can be mounted by userns root */ > > > +#define FS_UNTRUSTED 16 /* Defined filesystem as untrusted */ > > > #define FS_RENAME_DOES_D_MOVE 32768 /* FS will handle d_move() during rename() internally. */ > > > struct dentry *(*mount) (struct file_system_type *, int, > > > const char *, void *); > > > diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c > > > index f2803a40ff82..af8add31fe26 100644 > > > --- a/security/integrity/ima/ima_appraise.c > > > +++ b/security/integrity/ima/ima_appraise.c > > > @@ -292,7 +292,14 @@ int ima_appraise_measurement(enum ima_hooks func, > > > } > > > > > > out: > > > - if (status != INTEGRITY_PASS) { > > > + /* Fail untrusted and unpriviliged filesystems (eg FUSE) */ > > > + if ((inode->i_sb->s_type->fs_flags & FS_UNTRUSTED) && > > > + (inode->i_sb->s_user_ns != &init_user_ns)) { ^ if inode->i_sb->s_user_ns == &init_user_ns you don't fail. > > > + status = INTEGRITY_FAIL; > > > + cause = "untrusted-filesystem"; > > > + integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode, filename, > > > + op, cause, rc, 0); > > > + } else if (status != INTEGRITY_PASS) { > > > if ((ima_appraise & IMA_APPRAISE_FIX) && > > > (!xattr_value || > > > xattr_value->type != EVM_IMA_XATTR_DIGSIG)) { > > > @@ -309,6 +316,7 @@ int ima_appraise_measurement(enum ima_hooks func, > > > } else { > > > ima_cache_flags(iint, func); > > > } > > > + > > > ima_set_cache_status(iint, func, status); > > > return status; > > > } > > > -- > > > 2.7.5 > >