[RFC PATCH 1/4] ima: define a new policy condition based on the filesystem name

Some filesystems, like fuse, don't export the filesystem magic number.

In addition, when files in the initramfs will be properly labeled with
file signatures, we will need the ablity to differentiate between
rootfs that require file signatures from those don't.

This patch defines a new IMA policy condition named "fsname", based on
the superblock's file_system_type (sb->s_type) name. This allows policy
rules to be expressed in terms of the filesystem name.

Example rules:
measure func=FILE_CHECK fsname=fuse
appraise func=BPRM_CHECK fsname=rootfs
appraise func=FILE_MMAP fsname=rootfs

Signed-off-by: Mimi Zohar <redacted>
---
 Documentation/ABI/testing/ima_policy |  2 +-
 security/integrity/ima/ima_policy.c  | 25 ++++++++++++++++++++++++-
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index 2028f2d093b2..aeb5c6326b9b 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy

@@ -21,7 +21,7 @@ Description:
 			audit | hash | dont_hash
 		condition:= base | lsm  [option]
 			base:	[[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
-				[euid=] [fowner=]]
+				[euid=] [fowner=] [fsname=]]
 			lsm:	[[subj_user=] [subj_role=] [subj_type=]
 				 [obj_user=] [obj_role=] [obj_type=]]
 			option:	[[appraise_type=]] [permit_directio]

diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 915f5572c6ff..54847e08e6c8 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c

@@ -33,6 +33,7 @@
 #define IMA_INMASK	0x0040
 #define IMA_EUID	0x0080
 #define IMA_PCR		0x0100
+#define IMA_FSNAME	0x0200
 
 #define UNKNOWN		0
 #define MEASURE		0x0001	/* same as IMA_MEASURE */

@@ -74,6 +75,7 @@ struct ima_rule_entry {
 		void *args_p;	/* audit value */
 		int type;	/* audit type */
 	} lsm[MAX_LSM_RULES];
+	char *fsname;
 };
 
 /*

@@ -267,6 +269,9 @@ static bool ima_match_rules(struct ima_rule_entry *rule, struct inode *inode,
 	if ((rule->flags & IMA_FSMAGIC)
 	    && rule->fsmagic != inode->i_sb->s_magic)
 		return false;
+	if ((rule->flags & IMA_FSNAME)
+	    && strcmp(rule->fsname, inode->i_sb->s_type->name))
+		return false;
 	if ((rule->flags & IMA_FSUUID) &&
 	    !uuid_equal(&rule->fsuuid, &inode->i_sb->s_uuid))
 		return false;

@@ -528,7 +533,7 @@ enum {
 	Opt_audit, Opt_hash, Opt_dont_hash,
 	Opt_obj_user, Opt_obj_role, Opt_obj_type,
 	Opt_subj_user, Opt_subj_role, Opt_subj_type,
-	Opt_func, Opt_mask, Opt_fsmagic,
+	Opt_func, Opt_mask, Opt_fsmagic, Opt_fsname,
 	Opt_fsuuid, Opt_uid_eq, Opt_euid_eq, Opt_fowner_eq,
 	Opt_uid_gt, Opt_euid_gt, Opt_fowner_gt,
 	Opt_uid_lt, Opt_euid_lt, Opt_fowner_lt,

@@ -553,6 +558,7 @@ static match_table_t policy_tokens = {
 	{Opt_func, "func=%s"},
 	{Opt_mask, "mask=%s"},
 	{Opt_fsmagic, "fsmagic=%s"},
+	{Opt_fsname, "fsname=%s"},
 	{Opt_fsuuid, "fsuuid=%s"},
 	{Opt_uid_eq, "uid=%s"},
 	{Opt_euid_eq, "euid=%s"},

@@ -762,6 +768,17 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 			if (!result)
 				entry->flags |= IMA_FSMAGIC;
 			break;
+		case Opt_fsname:
+			ima_log_string(ab, "fsname", args[0].from);
+
+			entry->fsname = kstrdup(args[0].from, GFP_KERNEL);
+			if (!entry->fsname) {
+				result = -ENOMEM;
+				break;
+			}
+			result = 0;
+			entry->flags |= IMA_FSNAME;
+			break;
 		case Opt_fsuuid:
 			ima_log_string(ab, "fsuuid", args[0].from);
 

@@ -1090,6 +1107,12 @@ int ima_policy_show(struct seq_file *m, void *v)
 		seq_puts(m, " ");
 	}
 
+	if (entry->flags & IMA_FSNAME) {
+		snprintf(tbuf, sizeof(tbuf), "%s", entry->fsname);
+		seq_printf(m, pt(Opt_fsname), tbuf);
+		seq_puts(m, " ");
+	}
+
 	if (entry->flags & IMA_PCR) {
 		snprintf(tbuf, sizeof(tbuf), "%d", entry->pcr);
 		seq_printf(m, pt(Opt_pcr), tbuf);

-- 
2.7.5

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Files on FUSE can change at any point in time without notifying the
kernel.  This patch sets the new fs_type flag FS_UNTRUSTED to indicate
that the filesystem is untrusted.

(This patch is based on Alban Crequy's use of fs_flags.)

Signed-off-by: Mimi Zohar <redacted>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Seth Forshee <redacted>
Cc: Eric W. Biederman <redacted>
Cc: Dongsu Park <redacted>
Cc: Alban Crequy <redacted>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
---
 fs/fuse/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index 624f18bbfd2b..dad65a3c7388 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c

@@ -1205,7 +1205,7 @@ static void fuse_kill_sb_anon(struct super_block *sb)
 static struct file_system_type fuse_fs_type = {
 	.owner		= THIS_MODULE,
 	.name		= "fuse",
-	.fs_flags	= FS_HAS_SUBTYPE,
+	.fs_flags	= FS_HAS_SUBTYPE | FS_UNTRUSTED,
 	.mount		= fuse_mount,
 	.kill_sb	= fuse_kill_sb_anon,
 };

-- 
2.7.5

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
privileged, untrusted filesystems requires a custom policy.

(This patch is based on Alban Crequy's use of fs_flags and patch
 description.)

Signed-off-by: Mimi Zohar <redacted>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Seth Forshee <redacted>
Cc: Eric W. Biederman <redacted>
Cc: Dongsu Park <redacted>
Cc: Alban Crequy <redacted>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
---
 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)) {
+		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

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Verifying file signatures on untrusted filesystems is meaningless, as
the filesystem can change the file at any time.  This patch defines a
new policy option named "fail", which fails signature verification on
untrusted filesystems.

Like any other signature verification failure, the measurement is still
added to the measurement list and audited based on policy.

Signed-off-by: Mimi Zohar <redacted>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Seth Forshee <redacted>
Cc: Eric W. Biederman <redacted>
Cc: Dongsu Park <redacted>
Cc: Alban Crequy <redacted>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
---
 Documentation/ABI/testing/ima_policy  |  2 +-
 security/integrity/ima/ima_appraise.c |  8 ++++++--
 security/integrity/ima/ima_policy.c   | 12 +++++++++++-
 security/integrity/integrity.h        |  1 +
 4 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index aeb5c6326b9b..7c9529eb0f91 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy

@@ -24,7 +24,7 @@ Description:
 				[euid=] [fowner=] [fsname=]]
 			lsm:	[[subj_user=] [subj_role=] [subj_type=]
 				 [obj_user=] [obj_role=] [obj_type=]]
-			option:	[[appraise_type=]] [permit_directio]
+			option:	[[appraise_type=]] [permit_directio] [fail]
 
 		base: 	func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
 				[FIRMWARE_CHECK]

diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
index af8add31fe26..511448867f02 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c

@@ -292,9 +292,13 @@ int ima_appraise_measurement(enum ima_hooks func,
 	}
 
 out:
-	/* Fail untrusted and unpriviliged filesystems (eg FUSE) */
+	/*
+	 * Fail untrusted filesystems (eg. FUSE) that are either
+	 * unprivileged or based on policy.
+	 */
 	if ((inode->i_sb->s_type->fs_flags & FS_UNTRUSTED) &&
-	    (inode->i_sb->s_user_ns != &init_user_ns)) {
+	    ((inode->i_sb->s_user_ns != &init_user_ns) ||
+	     (iint->flags & IMA_FAIL_UNTRUSTED))) {
 		status = INTEGRITY_FAIL;
 		cause = "untrusted-filesystem";
 		integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode, filename,

diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 54847e08e6c8..1130c6deee41 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c

@@ -538,7 +538,7 @@ enum {
 	Opt_uid_gt, Opt_euid_gt, Opt_fowner_gt,
 	Opt_uid_lt, Opt_euid_lt, Opt_fowner_lt,
 	Opt_appraise_type, Opt_permit_directio,
-	Opt_pcr
+	Opt_pcr, Opt_fail
 };
 
 static match_table_t policy_tokens = {

@@ -572,6 +572,7 @@ static match_table_t policy_tokens = {
 	{Opt_appraise_type, "appraise_type=%s"},
 	{Opt_permit_directio, "permit_directio"},
 	{Opt_pcr, "pcr=%s"},
+	{Opt_fail, "fail"},
 	{Opt_err, NULL}
 };
 

@@ -912,6 +913,13 @@ static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 				entry->flags |= IMA_PCR;
 
 			break;
+		case Opt_fail:
+			if (entry->action != APPRAISE) {
+				result = -EINVAL;
+				break;
+			}
+			entry->flags |= IMA_FAIL_UNTRUSTED;
+			break;
 		case Opt_err:
 			ima_log_string(ab, "UNKNOWN", p);
 			result = -EINVAL;

@@ -1191,6 +1199,8 @@ int ima_policy_show(struct seq_file *m, void *v)
 		seq_puts(m, "appraise_type=imasig ");
 	if (entry->flags & IMA_PERMIT_DIRECTIO)
 		seq_puts(m, "permit_directio ");
+	if (entry->flags & IMA_FAIL_UNTRUSTED)
+		seq_puts(m, "fail ");
 	rcu_read_unlock();
 	seq_puts(m, "\n");
 	return 0;

diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
index 50a8e3365df7..5c052258fd73 100644
--- a/security/integrity/integrity.h
+++ b/security/integrity/integrity.h

@@ -35,6 +35,7 @@
 #define IMA_PERMIT_DIRECTIO	0x02000000
 #define IMA_NEW_FILE		0x04000000
 #define EVM_IMMUTABLE_DIGSIG	0x08000000
+#define IMA_FAIL_UNTRUSTED	0x10000000
 
 #define IMA_DO_MASK		(IMA_MEASURE | IMA_APPRAISE | IMA_AUDIT | \
 				 IMA_HASH | IMA_APPRAISE_SUBMASK)

-- 
2.7.5

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoting Mimi Zohar (zohar at 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?

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?

Good thing we can partially work around that by intercepting real
mount calls with Tycho's new patchset :)

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, 2018-02-14 at 08:49 -0600, Serge E. Hallyn wrote:

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

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.

Refer to the discussion with Linus -?http://kernsec.org/pipermail/linu
x-security-module-archive/2018-February/005200.html

quoted

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?

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?

thanks,

Mimi

quoted

(This patch is based on Alban Crequy's use of fs_flags and patch
 description.)

Signed-off-by: Mimi Zohar <redacted>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Seth Forshee <redacted>
Cc: Eric W. Biederman <redacted>
Cc: Dongsu Park <redacted>
Cc: Alban Crequy <redacted>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
---
 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)) {
+		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

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

On Wed, 2018-02-14 at 08:49 -0600, Serge E. Hallyn wrote:

quoted

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

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

quoted

quoted

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.

quoted

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

quoted

quoted

(This patch is based on Alban Crequy's use of fs_flags and patch
 description.)

Signed-off-by: Mimi Zohar <redacted>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Seth Forshee <redacted>
Cc: Eric W. Biederman <redacted>
Cc: Dongsu Park <redacted>
Cc: Alban Crequy <redacted>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
---
 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.

quoted

quoted

+		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

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, 2018-02-14 at 09:16 -0600, Serge E. Hallyn wrote:

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

On Wed, 2018-02-14 at 08:49 -0600, Serge E. Hallyn wrote:

quoted

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

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)

Unprivileged fuse mounts hasn't been upstreamed yet, so we wouldn't be
breaking existing userspace.

quoted

Refer to the discussion with Linus -?http://kernsec.org/pipermail/linu
x-security-module-archive/2018-February/005200.html

quoted

quoted

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.

What happened to the requirement that systems should be "fail-safe"?
Ok, hard coding this rule probably is not a good idea. ?For those
wanting to take this liability on their systems, we can make this
configurable, like for privileged fuse mounts. ?Unlike for privileged
fuse mounts, the builtin policies, I think, should be fail safe and
include the "fail" rule for unprivileged fuse mounts.

quoted

The remaining patches are policy based.

quoted

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

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

On Wed, 2018-02-14 at 09:16 -0600, Serge E. Hallyn wrote:

quoted

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

On Wed, 2018-02-14 at 08:49 -0600, Serge E. Hallyn wrote:

quoted

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

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)

Unprivileged fuse mounts hasn't been upstreamed yet, so we wouldn't be
breaking existing userspace.

I don't think I'm being clear.

In your patch it looks like you mark unprivileged FUSE mounts as
INTEGRITY_FAIL.  I agree you should do that.  But you skip the
FS_UNTRUSTED check for privileged FUSE mounts.  I'm asking why
that's ok.

quoted

quoted

Refer to the discussion with Linus -?http://kernsec.org/pipermail/linu
x-security-module-archive/2018-February/005200.html

quoted

quoted

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.

What happened to the requirement that systems should be "fail-safe"?

My point was - I was asking whether there was any way to have IMA be
meaningful with such containers, not saying I had any ideas, and
certainly not saying that just because you can't detect it means you
should allow it in all cases.  It's too bad that it has this effect,
but I agree with your patch.

I only didn't ack it because you're skipping the check for privileged
mounts which seems wrong.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, 2018-02-14 at 09:42 -0600, Serge E. Hallyn wrote:

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

On Wed, 2018-02-14 at 09:16 -0600, Serge E. Hallyn wrote:

quoted

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

On Wed, 2018-02-14 at 08:49 -0600, Serge E. Hallyn wrote:

quoted

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

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)

Unprivileged fuse mounts hasn't been upstreamed yet, so we wouldn't be
breaking existing userspace.

I don't think I'm being clear.

In your patch it looks like you mark unprivileged FUSE mounts as
INTEGRITY_FAIL.  I agree you should do that.  But you skip the
FS_UNTRUSTED check for privileged FUSE mounts.  I'm asking why
that's ok.

quoted

quoted

quoted

Refer to the discussion with Linus -?http://kernsec.org/pipermail/linu
x-security-module-archive/2018-February/005200.html

quoted

quoted

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.

What happened to the requirement that systems should be "fail-safe"?

My point was - I was asking whether there was any way to have IMA be
meaningful with such containers, not saying I had any ideas, and
certainly not saying that just because you can't detect it means you
should allow it in all cases.  It's too bad that it has this effect,
but I agree with your patch.

I only didn't ack it because you're skipping the check for privileged
mounts which seems wrong.

Oh!  That is based on Linus' "request" not to break userspace.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

On Wed, 2018-02-14 at 09:42 -0600, Serge E. Hallyn wrote:

quoted

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

On Wed, 2018-02-14 at 09:16 -0600, Serge E. Hallyn wrote:

quoted

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

On Wed, 2018-02-14 at 08:49 -0600, Serge E. Hallyn wrote:

quoted

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

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)

Unprivileged fuse mounts hasn't been upstreamed yet, so we wouldn't be
breaking existing userspace.

I don't think I'm being clear.

In your patch it looks like you mark unprivileged FUSE mounts as
INTEGRITY_FAIL.  I agree you should do that.  But you skip the
FS_UNTRUSTED check for privileged FUSE mounts.  I'm asking why
that's ok.

quoted

quoted

quoted

Refer to the discussion with Linus -?http://kernsec.org/pipermail/linu
x-security-module-archive/2018-February/005200.html

quoted

quoted

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.

What happened to the requirement that systems should be "fail-safe"?

My point was - I was asking whether there was any way to have IMA be
meaningful with such containers, not saying I had any ideas, and
certainly not saying that just because you can't detect it means you
should allow it in all cases.  It's too bad that it has this effect,
but I agree with your patch.

I only didn't ack it because you're skipping the check for privileged
mounts which seems wrong.

Oh!  That is based on Linus' "request" not to break userspace.

Oh, yeah, I guess that would do it :)  It seems so wrong that it's
probably worth putting a comment above that exception.

So probably not worth much but

Acked-by: Serge Hallyn <serge@hallyn.com>

thanks,
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html