Skip to contentSkip to conversation

ima: define new policy condition based on the filesystem name

PATCH In review Mimi Zohar 2 participants 5 messages Jan 15, 2018 – Feb 5, 2018

Subsystems (5)
lore
Share & tools
lore

Mimi Zohar

author
#0 lore raw

PATCH 1/1 ima: define new policy condition based on the filesystem name

Some filesystems do not export the filesystem's magic number, as it is considered internal, private data. In other cases, the policy rule needs to identify a specifically mounted filesystem (eg. rootfs).

This patch defines a new IMA policy condition named "fsname", based on the superblock's file_system_type (sb->s_type) name.

By defining a policy rule in terms of the filesystem magic number and the superblock filesystem name, files on the rootfs filesystem are only appraised, when rootfs is a tmpfs filesystem, which supports xattrs.

Sample rules:
measure func=FILE_CHECK fsname=xfs
appraise fsmagic=0x01021994 fsname=rootfs

---
 Documentation/ABI/testing/ima_policy |  2 +-
 security/integrity/ima/ima_policy.c  | 25 ++++++++++++++++++++++++-
 2 files changed, 25 insertions(+), 2 deletions(-)
Documentation/ABI/testing/ima_policy +1 -1
index b0e8143c681f..281b88d17a37 100644
@@ -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] [force]
security/integrity/ima/ima_policy.c +24 -1
index 878ae1a06e1e..ceffb98d79ca 100644
@@ -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"},
@@ -763,6 +769,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);
 
@@ -1094,6 +1111,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);
Signature · 6 lines
2.7.4

--
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
#1 lore raw
Quoted 3 lines · Mimi Zohar

Some filesystems do not export the filesystem's magic number, as it is considered internal, private data. In other cases, the policy rule needs to identify a specifically mounted filesystem (eg. rootfs).

No, it doesn't. Policies based on a file system type are complete and
utterly bogus. rootfs should not be treated any different from other
file systems.

author
#2 lore raw
Quoted 8 lines · Christoph Hellwig
Quoted 3 lines · Mimi Zohar

Some filesystems do not export the filesystem's magic number, as it is considered internal, private data. In other cases, the policy rule needs to identify a specifically mounted filesystem (eg. rootfs).

No, it doesn't. Policies based on a file system type are complete and
utterly bogus. rootfs should not be treated any different from other
file systems.

rootfs IS different than other filesystems, as other filesystems uniquely identify the underlying filesystem type.  rootfs can be a ramfs or tmpfs filesystem.  Only tmpfs supports xattrs.

Mimi

#3 lore raw
Quoted 3 lines · Mimi Zohar

rootfs IS different than other filesystems, as other filesystems uniquely identify the underlying filesystem type. �rootfs can be a ramfs or tmpfs filesystem. �Only tmpfs supports xattrs.

Tons of filesystems only have xattrs optionally. Check for goddamn xattrs if that is the requirement and not a name that has absolutely zero meaning for functionality. That is the whole point!

author
#4 lore raw
Quoted 8 lines · Christoph Hellwig
Quoted 3 lines · Mimi Zohar

rootfs IS different than other filesystems, as other filesystems uniquely identify the underlying filesystem type. ?rootfs can be a ramfs or tmpfs filesystem. ?Only tmpfs supports xattrs.

Tons of filesystems only have xattrs optionally. Check for goddamn xattrs if that is the requirement and not a name that has absolutely zero meaning for functionality. That is the whole point!

I should have said the main reason for defining a rootfs policy rule is not to differentiate it from ramfs, but the ability to require file signatures.

Up to now, CPIO did not support xattrs. ?With Taras' proposed CPIO xattr patch set, the initramfs can now be properly labeled with file signatures. ?Since only some systems will include file signatures in the initramfs, we need to be able to differentiate between those that require file signatures from those that don't.

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