ima: define new policy condition based on the filesystem name
Subsystems (5)
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
@@ -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
@@ -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
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.
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
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!
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