[PATCH] Extended Attributes for Security Modules against 2.5.68

[PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley]

This patch against 2.5.68 implements changes to the LSM xattr-related
hooks and adds xattr handlers for ext[23] to support the use of extended
attributes by security modules for storing file security labels, as
described in my April 8th RFC posting.  Please apply, or let me know if
any changes are needed.  Thanks.

 fs/Kconfig               |   24 +++++++++++++++++++++
 fs/ext2/Makefile         |    4 +++
 fs/ext2/xattr.c          |   21 ++++++++++++++++--
 fs/ext2/xattr.h          |    2 +
 fs/ext2/xattr_security.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++
 fs/ext3/Makefile         |    4 +++
 fs/ext3/xattr.c          |   21 ++++++++++++++++--
 fs/ext3/xattr.h          |    2 +
 fs/ext3/xattr_security.c |   52 +++++++++++++++++++++++++++++++++++++++++++++++
 fs/xattr.c               |    7 +++---
 include/linux/security.h |   15 +++++++++++++
 security/dummy.c         |    6 +++++
 12 files changed, 200 insertions(+), 9 deletions(-)

Index: linux-2.5/fs/Kconfig
diff -u linux-2.5/fs/Kconfig:1.1.1.3 linux-2.5/fs/Kconfig:1.5
--- linux-2.5/fs/Kconfig:1.1.1.3	Tue Mar 25 09:36:05 2003
+++ linux-2.5/fs/Kconfig	Fri Apr 18 12:16:24 2003
@@ -73,6 +73,18 @@
 
 	  If you don't know what Access Control Lists are, say N
 
+config EXT2_FS_SECURITY
+	bool "Ext2 Security Labels"
+	depends on EXT2_FS_XATTR
+	help
+	  Security labels support alternative access control models
+	  implemented by security modules like SELinux.  This option
+	  enables an extended attribute handler for file security
+	  labels in the ext2 filesystem.
+
+	  If you are not using a security module that requires using
+	  extended attributes for file security labels, say N.
+
 config EXT3_FS
 	tristate "Ext3 journalling file system support"
 	help
@@ -130,6 +142,18 @@
 	  Linux website <http://acl.bestbits.at/>.
 
 	  If you don't know what Access Control Lists are, say N
+
+config EXT3_FS_SECURITY
+	bool "Ext3 Security Labels"
+	depends on EXT3_FS_XATTR
+	help
+	  Security labels support alternative access control models
+	  implemented by security modules like SELinux.  This option
+	  enables an extended attribute handler for file security
+	  labels in the ext3 filesystem.
+
+	  If you are not using a security module that requires using
+	  extended attributes for file security labels, say N.
 
 config JBD
 # CONFIG_JBD could be its own option (even modular), but until there are
Index: linux-2.5/fs/xattr.c
diff -u linux-2.5/fs/xattr.c:1.1.1.1 linux-2.5/fs/xattr.c:1.4
--- linux-2.5/fs/xattr.c:1.1.1.1	Wed Mar 12 10:55:12 2003
+++ linux-2.5/fs/xattr.c	Wed Mar 26 14:03:25 2003
@@ -79,15 +79,16 @@
 
 	error = -EOPNOTSUPP;
 	if (d->d_inode->i_op && d->d_inode->i_op->setxattr) {
+		down(&d->d_inode->i_sem);
 		error = security_inode_setxattr(d, kname, kvalue, size, flags);
 		if (error)
 			goto out;
-		down(&d->d_inode->i_sem);
 		error = d->d_inode->i_op->setxattr(d, kname, kvalue, size, flags);
+		if (!error)
+			security_inode_post_setxattr(d, kname, kvalue, size, flags);
+out:
 		up(&d->d_inode->i_sem);
 	}
-
-out:
 	xattr_free(kvalue, size);
 	return error;
 }
Index: linux-2.5/fs/ext2/Makefile
diff -u linux-2.5/fs/ext2/Makefile:1.1.1.1 linux-2.5/fs/ext2/Makefile:1.2
--- linux-2.5/fs/ext2/Makefile:1.1.1.1	Wed Mar 12 10:55:33 2003
+++ linux-2.5/fs/ext2/Makefile	Fri Apr 18 12:16:34 2003
@@ -14,3 +14,7 @@
 ifeq ($(CONFIG_EXT2_FS_POSIX_ACL),y)
 ext2-objs += acl.o
 endif
+
+ifeq ($(CONFIG_EXT2_FS_SECURITY),y)
+ext2-objs += xattr_security.o
+endif
Index: linux-2.5/fs/ext2/xattr.c
diff -u linux-2.5/fs/ext2/xattr.c:1.1.1.4 linux-2.5/fs/ext2/xattr.c:1.3
--- linux-2.5/fs/ext2/xattr.c:1.1.1.4	Mon Apr 21 10:15:47 2003
+++ linux-2.5/fs/ext2/xattr.c	Mon Apr 21 11:03:31 2003
@@ -1102,22 +1102,33 @@
 				  &ext2_xattr_trusted_handler);
 	if (err)
 		goto out;
+#ifdef CONFIG_EXT2_FS_SECURITY
+	err = ext2_xattr_register(EXT2_XATTR_INDEX_SECURITY,
+				  &ext2_xattr_security_handler);
+	if (err)
+		goto out1;
+#endif
 #ifdef CONFIG_EXT2_FS_POSIX_ACL
 	err = init_ext2_acl();
 	if (err)
-		goto out1;
+		goto out2;
 #endif
 	ext2_xattr_cache = mb_cache_create("ext2_xattr", NULL,
 		sizeof(struct mb_cache_entry) +
 		sizeof(struct mb_cache_entry_index), 1, 6);
 	if (!ext2_xattr_cache) {
 		err = -ENOMEM;
-		goto out2;
+		goto out3;
 	}
 	return 0;
-out2:
+out3:
 #ifdef CONFIG_EXT2_FS_POSIX_ACL
 	exit_ext2_acl();
+out2:
+#endif
+#ifdef CONFIG_EXT2_FS_SECURITY
+	ext2_xattr_unregister(EXT2_XATTR_INDEX_SECURITY,
+			      &ext2_xattr_security_handler);
 out1:
 #endif
 	ext2_xattr_unregister(EXT2_XATTR_INDEX_TRUSTED,
@@ -1134,6 +1145,10 @@
 	mb_cache_destroy(ext2_xattr_cache);
 #ifdef CONFIG_EXT2_FS_POSIX_ACL
 	exit_ext2_acl();
+#endif
+#ifdef CONFIG_EXT2_FS_SECURITY
+	ext2_xattr_unregister(EXT2_XATTR_INDEX_SECURITY,
+			      &ext2_xattr_security_handler);
 #endif
 	ext2_xattr_unregister(EXT2_XATTR_INDEX_TRUSTED,
 			      &ext2_xattr_trusted_handler);
Index: linux-2.5/fs/ext2/xattr.h
diff -u linux-2.5/fs/ext2/xattr.h:1.1.1.1 linux-2.5/fs/ext2/xattr.h:1.2
--- linux-2.5/fs/ext2/xattr.h:1.1.1.1	Wed Mar 12 10:55:33 2003
+++ linux-2.5/fs/ext2/xattr.h	Fri Apr 18 12:16:34 2003
@@ -22,6 +22,7 @@
 #define EXT2_XATTR_INDEX_POSIX_ACL_ACCESS	2
 #define EXT2_XATTR_INDEX_POSIX_ACL_DEFAULT	3
 #define EXT2_XATTR_INDEX_TRUSTED		4
+#define EXT2_XATTR_INDEX_SECURITY	        5
 
 struct ext2_xattr_header {
 	__u32	h_magic;	/* magic number for identification */
@@ -134,4 +135,5 @@
 
 extern struct ext2_xattr_handler ext2_xattr_user_handler;
 extern struct ext2_xattr_handler ext2_xattr_trusted_handler;
+extern struct ext2_xattr_handler ext2_xattr_security_handler;
 
Index: linux-2.5/fs/ext2/xattr_security.c
diff -u /dev/null linux-2.5/fs/ext2/xattr_security.c:1.1
--- /dev/null	Mon Apr 21 11:26:50 2003
+++ linux-2.5/fs/ext2/xattr_security.c	Fri Apr 18 12:16:34 2003
@@ -0,0 +1,51 @@
+/*
+ * linux/fs/ext2/xattr_security.c
+ * Handler for storing security labels as extended attributes.
+ */
+
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/fs.h>
+#include <linux/smp_lock.h>
+#include <linux/ext2_fs.h>
+#include "xattr.h"
+
+#define XATTR_NAME_SECURITY "system.security"
+
+static size_t
+ext2_xattr_security_list(char *list, struct inode *inode,
+			const char *name, int name_len)
+{
+	const int size = sizeof(XATTR_NAME_SECURITY);
+
+	if (list)
+		memcpy(list, XATTR_NAME_SECURITY, size);
+	return size;
+}
+
+static int
+ext2_xattr_security_get(struct inode *inode, const char *name,
+		       void *buffer, size_t size)
+{
+	if (strcmp(name, "") != 0)
+		return -EINVAL;
+	return ext2_xattr_get(inode, EXT2_XATTR_INDEX_SECURITY, name,
+			      buffer, size);
+}
+
+static int
+ext2_xattr_security_set(struct inode *inode, const char *name,
+		       const void *value, size_t size, int flags)
+{
+	if (strcmp(name, "") != 0)
+		return -EINVAL;
+	return ext2_xattr_set(inode, EXT2_XATTR_INDEX_SECURITY, name,
+			      value, size, flags);
+}
+
+struct ext2_xattr_handler ext2_xattr_security_handler = {
+	.prefix	= XATTR_NAME_SECURITY,
+	.list	= ext2_xattr_security_list,
+	.get	= ext2_xattr_security_get,
+	.set	= ext2_xattr_security_set,
+};
Index: linux-2.5/fs/ext3/Makefile
diff -u linux-2.5/fs/ext3/Makefile:1.1.1.1 linux-2.5/fs/ext3/Makefile:1.2
--- linux-2.5/fs/ext3/Makefile:1.1.1.1	Wed Mar 12 10:55:31 2003
+++ linux-2.5/fs/ext3/Makefile	Wed Mar 26 14:03:26 2003
@@ -14,3 +14,7 @@
 ifeq ($(CONFIG_EXT3_FS_POSIX_ACL),y)
 ext3-objs += acl.o
 endif
+
+ifeq ($(CONFIG_EXT3_FS_SECURITY),y)
+ext3-objs += xattr_security.o
+endif
Index: linux-2.5/fs/ext3/xattr.c
diff -u linux-2.5/fs/ext3/xattr.c:1.1.1.4 linux-2.5/fs/ext3/xattr.c:1.3
--- linux-2.5/fs/ext3/xattr.c:1.1.1.4	Mon Apr 21 10:15:42 2003
+++ linux-2.5/fs/ext3/xattr.c	Mon Apr 21 11:03:31 2003
@@ -1142,22 +1142,33 @@
 				  &ext3_xattr_trusted_handler);
 	if (err)
 		goto out;
+#ifdef CONFIG_EXT3_FS_SECURITY
+	err = ext3_xattr_register(EXT3_XATTR_INDEX_SECURITY,
+				  &ext3_xattr_security_handler);
+	if (err)
+		goto out1;
+#endif
 #ifdef CONFIG_EXT3_FS_POSIX_ACL
 	err = init_ext3_acl();
 	if (err)
-		goto out1;
+		goto out2;
 #endif
 	ext3_xattr_cache = mb_cache_create("ext3_xattr", NULL,
 		sizeof(struct mb_cache_entry) +
 		sizeof(struct mb_cache_entry_index), 1, 6);
 	if (!ext3_xattr_cache) {
 		err = -ENOMEM;
-		goto out2;
+		goto out3;
 	}
 	return 0;
-out2:
+out3:
 #ifdef CONFIG_EXT3_FS_POSIX_ACL
 	exit_ext3_acl();
+out2:
+#endif
+#ifdef CONFIG_EXT3_FS_SECURITY
+	ext3_xattr_unregister(EXT3_XATTR_INDEX_SECURITY,
+			      &ext3_xattr_security_handler);
 out1:
 #endif
 	ext3_xattr_unregister(EXT3_XATTR_INDEX_TRUSTED,
@@ -1176,6 +1187,10 @@
 	ext3_xattr_cache = NULL;
 #ifdef CONFIG_EXT3_FS_POSIX_ACL
 	exit_ext3_acl();
+#endif
+#ifdef CONFIG_EXT3_FS_SECURITY
+	ext3_xattr_unregister(EXT3_XATTR_INDEX_SECURITY,
+			      &ext3_xattr_security_handler);
 #endif
 	ext3_xattr_unregister(EXT3_XATTR_INDEX_TRUSTED,
 			      &ext3_xattr_trusted_handler);
Index: linux-2.5/fs/ext3/xattr.h
diff -u linux-2.5/fs/ext3/xattr.h:1.1.1.1 linux-2.5/fs/ext3/xattr.h:1.2
--- linux-2.5/fs/ext3/xattr.h:1.1.1.1	Wed Mar 12 10:55:32 2003
+++ linux-2.5/fs/ext3/xattr.h	Wed Mar 26 14:03:26 2003
@@ -21,6 +21,7 @@
 #define EXT3_XATTR_INDEX_POSIX_ACL_ACCESS	2
 #define EXT3_XATTR_INDEX_POSIX_ACL_DEFAULT	3
 #define EXT3_XATTR_INDEX_TRUSTED		4
+#define EXT3_XATTR_INDEX_SECURITY	        5
 
 struct ext3_xattr_header {
 	__u32	h_magic;	/* magic number for identification */
@@ -141,3 +142,4 @@
 
 extern struct ext3_xattr_handler ext3_xattr_user_handler;
 extern struct ext3_xattr_handler ext3_xattr_trusted_handler;
+extern struct ext3_xattr_handler ext3_xattr_security_handler;
Index: linux-2.5/fs/ext3/xattr_security.c
diff -u /dev/null linux-2.5/fs/ext3/xattr_security.c:1.1
--- /dev/null	Mon Apr 21 11:26:50 2003
+++ linux-2.5/fs/ext3/xattr_security.c	Wed Mar 26 14:03:26 2003
@@ -0,0 +1,52 @@
+/*
+ * linux/fs/ext3/xattr_security.c
+ * Handler for storing security labels as extended attributes.
+ */
+
+#include <linux/module.h>
+#include <linux/string.h>
+#include <linux/fs.h>
+#include <linux/smp_lock.h>
+#include <linux/ext3_jbd.h>
+#include <linux/ext3_fs.h>
+#include "xattr.h"
+
+#define XATTR_NAME_SECURITY "system.security"
+
+static size_t
+ext3_xattr_security_list(char *list, struct inode *inode,
+		    const char *name, int name_len)
+{
+	const int size = sizeof(XATTR_NAME_SECURITY);
+
+	if (list) 
+		memcpy(list, XATTR_NAME_SECURITY, size);
+	return size;
+}
+
+static int
+ext3_xattr_security_get(struct inode *inode, const char *name,
+		       void *buffer, size_t size)
+{
+	if (strcmp(name, "") != 0)
+		return -EINVAL;
+	return ext3_xattr_get(inode, EXT3_XATTR_INDEX_SECURITY, name,
+			      buffer, size);
+}
+
+static int
+ext3_xattr_security_set(struct inode *inode, const char *name,
+		       const void *value, size_t size, int flags)
+{
+	if (strcmp(name, "") != 0)
+		return -EINVAL;
+	return ext3_xattr_set(inode, EXT3_XATTR_INDEX_SECURITY, name,
+			      value, size, flags);
+}
+
+struct ext3_xattr_handler ext3_xattr_security_handler = {
+	.prefix	= XATTR_NAME_SECURITY,
+	.list	= ext3_xattr_security_list,
+	.get	= ext3_xattr_security_get,
+	.set	= ext3_xattr_security_set,
+};
Index: linux-2.5/include/linux/security.h
diff -u linux-2.5/include/linux/security.h:1.1.1.2 linux-2.5/include/linux/security.h:1.16
--- linux-2.5/include/linux/security.h:1.1.1.2	Wed Mar 19 09:54:58 2003
+++ linux-2.5/include/linux/security.h	Fri Apr 18 11:17:19 2003
@@ -361,6 +361,9 @@
  * 	Check permission before setting the extended attributes
  * 	@value identified by @name for @dentry.
  * 	Return 0 if permission is granted.
+ * @inode_post_setxattr:
+ * 	Update inode security field after successful setxattr operation.
+ * 	@value identified by @name for @dentry.
  * @inode_getxattr:
  * 	Check permission before obtaining the extended attributes
  * 	identified by @name for @dentry.
@@ -1036,6 +1039,8 @@
         void (*inode_delete) (struct inode *inode);
 	int (*inode_setxattr) (struct dentry *dentry, char *name, void *value,
 			       size_t size, int flags);
+	void (*inode_post_setxattr) (struct dentry *dentry, char *name, void *value,
+				     size_t size, int flags);
 	int (*inode_getxattr) (struct dentry *dentry, char *name);
 	int (*inode_listxattr) (struct dentry *dentry);
 	int (*inode_removexattr) (struct dentry *dentry, char *name);
@@ -1464,6 +1472,12 @@
 	return security_ops->inode_setxattr (dentry, name, value, size, flags);
 }
 
+static inline void security_inode_post_setxattr (struct dentry *dentry, char *name,
+						void *value, size_t size, int flags)
+{
+	security_ops->inode_post_setxattr (dentry, name, value, size, flags);
+}
+
 static inline int security_inode_getxattr (struct dentry *dentry, char *name)
 {
 	return security_ops->inode_getxattr (dentry, name);
@@ -2063,6 +2087,10 @@
 	return 0;
 }
 
+static inline void security_inode_post_setxattr (struct dentry *dentry, char *name,
+						 void *value, size_t size, int flags)
+{ }
+
 static inline int security_inode_getxattr (struct dentry *dentry, char *name)
 {
 	return 0;
Index: linux-2.5/security/dummy.c
diff -u linux-2.5/security/dummy.c:1.1.1.2 linux-2.5/security/dummy.c:1.14
--- linux-2.5/security/dummy.c:1.1.1.2	Wed Mar 19 09:59:17 2003
+++ linux-2.5/security/dummy.c	Fri Apr 18 11:17:20 2003
@@ -334,6 +334,11 @@
 	return 0;
 }
 
+static void dummy_inode_post_setxattr (struct dentry *dentry, char *name, void *value,
+				       size_t size, int flags)
+{
+}
+
 static int dummy_inode_getxattr (struct dentry *dentry, char *name)
 {
 	return 0;
@@ -803,6 +818,7 @@
 	set_to_dummy_if_null(ops, inode_getattr);
 	set_to_dummy_if_null(ops, inode_delete);
 	set_to_dummy_if_null(ops, inode_setxattr);
+	set_to_dummy_if_null(ops, inode_post_setxattr);
 	set_to_dummy_if_null(ops, inode_getxattr);
 	set_to_dummy_if_null(ops, inode_listxattr);
 	set_to_dummy_if_null(ops, inode_removexattr);

  
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Christoph Hellwig]

On Wed, Apr 23, 2003 at 01:52:03PM -0400, Stephen Smalley wrote:
> This patch against 2.5.68 implements changes to the LSM xattr-related
> hooks and adds xattr handlers for ext[23] to support the use of extended
> attributes by security modules for storing file security labels, as
> described in my April 8th RFC posting.  Please apply, or let me know if
> any changes are needed.  Thanks.

First, please put the changes in the LSM API in a different patch from
the xattr changes, they're a different issue.

The other question is why do you name them system.security?  The name
sounds a bit too generic to me.  ACLs are certainly a security feature
and have different ATTRS, similar for the Posix capability and MAC
support in XFS.  As selinux is the flask implementation for Linux
what about system.flask_label?  (or system.selinux_label?)

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Chris Wright]

* Christoph Hellwig (hch@infradead.org) wrote:
> 
> The other question is why do you name them system.security?  The name
> sounds a bit too generic to me.  ACLs are certainly a security feature
> and have different ATTRS, similar for the Posix capability and MAC
> support in XFS.  As selinux is the flask implementation for Linux
> what about system.flask_label?  (or system.selinux_label?)

It's really a namespace issue for user apps trying to deal with xattrs.
Being able to display the xattrs associated with a file in sane way,
like getxattr(path, "system.security", ...).  Otherwise something like
listxattr() then gettxttr(... "system.security.[blah]" ...).  Total
freeform naming is a headache for userspace to deal with.  Esp. since we
don't want to teach all userland tools about each individual module/policy.

There were a couple proposals to use common root like "system.security."
(or the trusted namespace which was discussed in earlier threads).

Would you still prefer module specific naming?

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Christoph Hellwig]

On Wed, Apr 23, 2003 at 11:25:49AM -0700, Chris Wright wrote:
> It's really a namespace issue for user apps trying to deal with xattrs.

Yes.

> Being able to display the xattrs associated with a file in sane way,
> like getxattr(path, "system.security", ...).  Otherwise something like
> listxattr() then gettxttr(... "system.security.[blah]" ...).  Total
> freeform naming is a headache for userspace to deal with.  Esp. since we
> don't want to teach all userland tools about each individual module/policy.

Randomly userland shouldn't deal with these xattrs.  Remember you are
talking about the ondisk represenation of your labelling - nothing
but the labelling tools should ever touch it.

> There were a couple proposals to use common root like "system.security."
> (or the trusted namespace which was discussed in earlier threads).
> 
> Would you still prefer module specific naming?

Personally I give a damn about the actual naming.  Just make sure
that each name has a unique meaning associated with it.

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley]

On Wed, 2003-04-23 at 14:45, Christoph Hellwig wrote:
> Randomly userland shouldn't deal with these xattrs.  Remember you are
> talking about the ondisk represenation of your labelling - nothing
> but the labelling tools should ever touch it.

Not true.  ls should be able to display the security label.  find should
be able to locate files that have specific security labels.  cp should
be able to preserve the security label on copies.  logrotate should be
able to preserve the security label when rotating logs.  crond should be
able to check the security label on a crontab spool file to verify
consistency with the user's credentials with which the cron job will
run.  login/sshd need to set the security label on the user's terminal
device.  You'll find plenty of examples of patched userland in SELinux,
but none of these patches are specific to a particular set of security
attributes.  They just handle them as strings.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Christoph Hellwig]

On Wed, Apr 23, 2003 at 03:17:57PM -0400, Stephen Smalley wrote:
> On Wed, 2003-04-23 at 14:45, Christoph Hellwig wrote:
> > Randomly userland shouldn't deal with these xattrs.  Remember you are
> > talking about the ondisk represenation of your labelling - nothing
> > but the labelling tools should ever touch it.
> 
> Not true.  ls should be able to display the security label.  find should
> be able to locate files that have specific security labels.  cp should
> be able to preserve the security label on copies.  logrotate should be
> able to preserve the security label when rotating logs.  crond should be
> able to check the security label on a crontab spool file to verify
> consistency with the user's credentials with which the cron job will
> run.  login/sshd need to set the security label on the user's terminal
> device.  You'll find plenty of examples of patched userland in SELinux,
> but none of these patches are specific to a particular set of security
> attributes.  They just handle them as strings.

And all these should _not_ happen in the actual tools but in a
pluggable security module (something like pam).  Encoding any security
policy and especially a xattr name in those utils is bad.

And see, you start to contradict what you said before - with your
suggestion cron has to know what the label means, so your selinux
cron would do stupid things with say may Posix 1003.1e MAC filesystem.

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley]

On Wed, 2003-04-23 at 15:26, Christoph Hellwig wrote:
> And all these should _not_ happen in the actual tools but in a
> pluggable security module (something like pam).  Encoding any security
> policy and especially a xattr name in those utils is bad.

For many of the patched utilities, there would be no encoding of any
specific policy/module as long as you have a single attribute name,
since they are just handling the labels as strings.  It isn't clear that
PAM-like API is feasible for the wide range of different applications
that need to deal with security labels.  I don't see what value there is
in adding an extra level of indirection just to get the security label
of a file and display it, or to get it and use it to relabel a new copy
of the file to the same label.  

As a side note, please keep in mind that SELinux is itself a generic
framework for MAC policies, provides encapsulation of security labels,
and allows security models and attributes to be added or removed without
requiring changes outside of the security policy engine, which itself is
an encapsulated component of the SELinux module.

> And see, you start to contradict what you said before - with your
> suggestion cron has to know what the label means, so your selinux
> cron would do stupid things with say may Posix 1003.1e MAC filesystem.

Not exactly.  Our patch to crond uses a generic policy API that was
designed to support many different security models, so it doesn't have
to be specific to SELinux.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Christoph Hellwig]

On Wed, Apr 23, 2003 at 03:52:14PM -0400, Stephen Smalley wrote:
> For many of the patched utilities, there would be no encoding of any
> specific policy/module as long as you have a single attribute name,
> since they are just handling the labels as strings.

That assumes every label is a string.

> As a side note, please keep in mind that SELinux is itself a generic
> framework for MAC policies, provides encapsulation of security labels,
> and allows security models and attributes to be added or removed without
> requiring changes outside of the security policy engine, which itself is
> an encapsulated component of the SELinux module.

That doesn't matter at all for this question - if you have a selinux_label
attribute you can add your different policies with string labels to
it.  But don't mix it up with others. 

> Not exactly.  Our patch to crond uses a generic policy API that was
> designed to support many different security models, so it doesn't have
> to be specific to SELinux.

So it doesn't hardcode your xattr?  That's what I suggested..

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley]

On Wed, 2003-04-23 at 16:20, Christoph Hellwig wrote:
> That doesn't matter at all for this question - if you have a selinux_label
> attribute you can add your different policies with string labels to
> it.  But don't mix it up with others.

Ok, so you still favor using a distinct attribute name for SELinux
attributes.  Andreas Gruenbacher had suggested during the earlier thread
that we use something like the xattr_trusted.c attribute handler, so
that a single xattr handler would cover all security modules but each
security module could have its own attribute name (security.selinux,
security.dte, security.capabilities, etc).  As I explained during that
thread, I don't think we want to use the trusted attribute handler
itself due to its permission checking model, but it would be easy to
make the xattr_security.c handler more like xattr_trusted.c in terms of
allowing arbitrary extensions of a "security." prefix.  Is that more to
your liking, or do you truly want a separate handler for each security
module?  I see the latter as undesirable as it requires each security
module to separately reserve a name and an index in each filesystem.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Christoph Hellwig]

On Thu, Apr 24, 2003 at 08:55:46AM -0400, Stephen Smalley wrote:
> attributes.  Andreas Gruenbacher had suggested during the earlier thread
> that we use something like the xattr_trusted.c attribute handler, so
> that a single xattr handler would cover all security modules but each
> security module could have its own attribute name (security.selinux,
> security.dte, security.capabilities, etc).  As I explained during that
> thread, I don't think we want to use the trusted attribute handler
> itself due to its permission checking model,

Hmm, what would you think of changing the xattr_trusted security
model to fit your needs?  It's so far unused outside XFS and there's
maybe a chance changing it.

> but it would be easy to
> make the xattr_security.c handler more like xattr_trusted.c in terms of
> allowing arbitrary extensions of a "security." prefix.  Is that more to
> your liking, or do you truly want a separate handler for each security
> module?

It's fine with me.

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley]

On Thu, 2003-04-24 at 09:03, Christoph Hellwig wrote:
> Hmm, what would you think of changing the xattr_trusted security
> model to fit your needs?  It's so far unused outside XFS and there's
> maybe a chance changing it.

It would require removing the capable(CAP_SYS_ADMIN) checks from the
xattr_trusted.c handler and implementing them in the capabilities
security module (and corresponding superuser tests in the dummy security
module) via the inode_setxattr and inode_getxattr hook functions.  This
would then permit security modules to implement their own permission
checking logic for getxattr and setxattr calls for their attributes, and
it would allow security modules to internally call the getxattr and
setxattr inode operations without being subjected to these checks in
order to manage the attributes.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Chris Wright]

* Stephen Smalley (sds@epoch.ncsc.mil) wrote:
> On Thu, 2003-04-24 at 09:03, Christoph Hellwig wrote:
> > Hmm, what would you think of changing the xattr_trusted security
> > model to fit your needs?  It's so far unused outside XFS and there's
> > maybe a chance changing it.
> 
> It would require removing the capable(CAP_SYS_ADMIN) checks from the
> xattr_trusted.c handler and implementing them in the capabilities
> security module (and corresponding superuser tests in the dummy security
> module) via the inode_setxattr and inode_getxattr hook functions.  This
> would then permit security modules to implement their own permission
> checking logic for getxattr and setxattr calls for their attributes, and
> it would allow security modules to internally call the getxattr and
> setxattr inode operations without being subjected to these checks in
> order to manage the attributes.

Or perhaps introducing some of the CAP_MAC_* bits.  In either case, it'd
be nice to reuse xattr_trusted if possible, IMHO.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley]

On Thu, 2003-04-24 at 14:36, Chris Wright wrote:
> Or perhaps introducing some of the CAP_MAC_* bits.

I don't think that would help.  As I mentioned during the earlier
discussion with Andreas, you want to be able to allow the security
module to call the inode getxattr and setxattr operations without
restriction for internal management of the security labels, while
applying access controls to user processes invoking the [gs]etxattr
system calls.  Hence, you don't want the permission check implemented in
the handler; it is better to handle the checking entirely via the LSM
hooks in the [gs]etxattr calls and allow unrestricted internal use of
the inode [gs]etxattr operations by the module.  Capability checks are
also too coarse-grained; you want to be able to perform a permission
check based on the process and the inode attributes, not just a
process-based check.

If the intent of the trusted namespace is for attributes that can be
managed by superuser processes (this is my impression), then I think it
would be better to create a separate namespace and handler for security
modules for clarity.  Or at least for MAC modules.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Andreas Dilger]

On Apr 24, 2003  15:02 -0400, Stephen Smalley wrote:
> I don't think that would help.  As I mentioned during the earlier
> discussion with Andreas, you want to be able to allow the security
> module to call the inode getxattr and setxattr operations without
> restriction for internal management of the security labels, while
> applying access controls to user processes invoking the [gs]etxattr
> system calls.  Hence, you don't want the permission check implemented in
> the handler; it is better to handle the checking entirely via the LSM
> hooks in the [gs]etxattr calls and allow unrestricted internal use of
> the inode [gs]etxattr operations by the module.  Capability checks are
> also too coarse-grained; you want to be able to perform a permission
> check based on the process and the inode attributes, not just a
> process-based check.
> 
> If the intent of the trusted namespace is for attributes that can be
> managed by superuser processes (this is my impression), then I think it
> would be better to create a separate namespace and handler for security
> modules for clarity.  Or at least for MAC modules.

Wasn't part of the LSM setup done in a way that there would be "default"
handlers for the hooks for normal PID/capability checking in the absence
of another LSM module?  I thought that was one of the reasons LSM hooks
were accepted into the kernel, since this would allow even the default
file/process permission checks to be compiled out for, say, embedded
systems that only run as root anyways.

Couldn't that be used to do the trusted-namespace- means-CAP_SYS_ADMIN
checks, but it can be replaced by other LSM security modules if desired?

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley]

On Thu, 2003-04-24 at 15:40, Andreas Dilger wrote:
> Couldn't that be used to do the trusted-namespace- means-CAP_SYS_ADMIN
> checks, but it can be replaced by other LSM security modules if desired?

If we move the CAP_SYS_ADMIN checks from the trusted xattr handlers to
the corresponding hook functions in the capabilities module, then we can
replace those checks with our own permission checking for user process
access to trusted.selinux and avoid any restrictions when the SELinux
module internally performs getxattr and setxattr inode operations to
manage the security labels.  This isn't difficult to implement, but
implies a change in meaning for the trusted namespace.  As I understand
it, that namespace is intended for attributes that can be managed by
superuser processes.  Using that namespace for SELinux means that it
will also be used for attributes managed and used internally by the
security module for access control purposes.  I'm not sure that you want
to mix them; it would be similar to putting ACLs in the trusted
namespace.
 
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Chris Wright]

* Andreas Dilger (adilger@clusterfs.com) wrote:
> 
> Couldn't that be used to do the trusted-namespace- means-CAP_SYS_ADMIN
> checks, but it can be replaced by other LSM security modules if desired?

I think that's what Stephen is saying.  The issue is, the "trusted."
handler uses CAP_SYS_ADMIN internally, after any other LSM check has
already occurred.  And the capable() check is too simple to know things
like which inode's xattr is in question at the moment or which namespace.
So Stephen was suggesting moving it out of the handler and putting it
in core code.

cheers,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Chris Wright]

* Stephen Smalley (sds@epoch.ncsc.mil) wrote:
> On Thu, 2003-04-24 at 14:36, Chris Wright wrote:
> > Or perhaps introducing some of the CAP_MAC_* bits.
> 
> I don't think that would help.  As I mentioned during the earlier
> discussion with Andreas, you want to be able to allow the security
> module to call the inode getxattr and setxattr operations without
> restriction for internal management of the security labels, while
> applying access controls to user processes invoking the [gs]etxattr
> system calls.  Hence, you don't want the permission check implemented in
> the handler; it is better to handle the checking entirely via the LSM
> hooks in the [gs]etxattr calls and allow unrestricted internal use of
> the inode [gs]etxattr operations by the module.  Capability checks are

Yes, this makes sense to me.

> also too coarse-grained; you want to be able to perform a permission
> check based on the process and the inode attributes, not just a
> process-based check.

Of course, good point.  I thought I might regret throwing CAP_ into the
picture ;-)

> If the intent of the trusted namespace is for attributes that can be
> managed by superuser processes (this is my impression), then I think it
> would be better to create a separate namespace and handler for security
> modules for clarity.  Or at least for MAC modules.

Yes, there was also some mention of the permission issue w.r.t. HSM and
(i vaguely recall) an xattr interface proposed that noted if the request was
internal from the kernel (skip the capable check) or on behalf of user.
If this were carried through, it could suffice, no?

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley]

On Thu, 2003-04-24 at 15:47, Chris Wright wrote:
> Yes, there was also some mention of the permission issue w.r.t. HSM and
> (i vaguely recall) an xattr interface proposed that noted if the request was
> internal from the kernel (skip the capable check) or on behalf of user.
> If this were carried through, it could suffice, no?

You still wouldn't want the security check implemented in the xattr
handler (even for calls on behalf of user processes), because it will
differ depending on the security module and may require the full
contextual information (process and inode).  Effectively, you would have
to just implement a call from the xattr handler to the security module,
and we already have hook calls from the [gs]etxattr system call code to
the security module to support such permission checking for user
processes.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[richard offer]

* frm hch@infradead.org "04/23/03 20:26:15 +0100" | sed '1,$s/^/* /'
*
* 
* And all these should _not_ happen in the actual tools but in a
* pluggable security module (something like pam).  

I proposed something along those lines back in 2001 at the USENIX security
conference LSM BOF---I called it PACM. 

But it seemed that no-one else was interested in policy independent
userland interfaces or applications (X, sendmail) making policy decisions.


richard.

-- 
-----------------------------------------------------------------------
Richard Offer                     Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Andreas Dilger]

On Apr 23, 2003  11:25 -0700, Chris Wright wrote:
> * Christoph Hellwig (hch@infradead.org) wrote:
> > The other question is why do you name them system.security?  The name
> > sounds a bit too generic to me.  ACLs are certainly a security feature
> > and have different ATTRS, similar for the Posix capability and MAC
> > support in XFS.  As selinux is the flask implementation for Linux
> > what about system.flask_label?  (or system.selinux_label?)
> 
> It's really a namespace issue for user apps trying to deal with xattrs.
> Being able to display the xattrs associated with a file in sane way,
> like getxattr(path, "system.security", ...).  Otherwise something like
> listxattr() then gettxttr(... "system.security.[blah]" ...).  Total
> freeform naming is a headache for userspace to deal with.  Esp. since we
> don't want to teach all userland tools about each individual module/policy.

Well, with the exception of backup/restore (which will just treat this
EA data as opaque and doesn't really care whether the names are fixed
or not), the tools DO need to understand each individual module
or policy in order to make any sense of the data.  Otherwise, all you
can do is print out some binary blob which is no use to anyone.

So, either the tools look for "system.security", and then have to
understand an internal magic for each module to know what to do with
the data, or it looks for "system.<modulename>" for only module names
that it actually understands.

The only reason to use a common "system.security" is if the actual data
stored therein was usable by more than a single security module.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley]

On Wed, 2003-04-23 at 14:54, Andreas Dilger wrote:
> Well, with the exception of backup/restore (which will just treat this
> EA data as opaque and doesn't really care whether the names are fixed
> or not), the tools DO need to understand each individual module
> or policy in order to make any sense of the data.  Otherwise, all you
> can do is print out some binary blob which is no use to anyone.

You are assuming that the ondisk representation is a binary blob.  If
you store a string representation as your security label, then your
userspace tools can operate on it cleanly without caring what it
actually means.  SELinux includes patched versions of many of the user
utilities that can get or set file security labels, and it doesn't
matter whether the security label consists of a MLS range or a TE domain
or a RBAC role or any combination of them.

For MAC, you want to preserve meaningful security information on the
filesystem partition itself (and in any backups), not some arbitrary
integer that might be remapped at any time to a completely different
meaning or that might mean something quite different if you mount the
disk on some other system.  A human-readable string representation is
preferable here.

> So, either the tools look for "system.security", and then have to
> understand an internal magic for each module to know what to do with
> the data, or it looks for "system.<modulename>" for only module names
> that it actually understands.

Again, if you are using a string representation, then most of your
userland can simply display it or take input from the user and pass it
down without caring about the meaning of the string.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Chris Wright]

* Andreas Dilger (adilger@clusterfs.com) wrote:
> 
> Well, with the exception of backup/restore (which will just treat this
> EA data as opaque and doesn't really care whether the names are fixed
> or not), the tools DO need to understand each individual module
> or policy in order to make any sense of the data.  Otherwise, all you
> can do is print out some binary blob which is no use to anyone.

I was imagining strings, not binary blobs, sorry for the confusion.

> So, either the tools look for "system.security", and then have to
> understand an internal magic for each module to know what to do with
> the data, or it looks for "system.<modulename>" for only module names
> that it actually understands.

Or simply print the strings associated with the label.

> The only reason to use a common "system.security" is if the actual data
> stored therein was usable by more than a single security module.

Or, as mentioned, if you care to print out the label with standard
fileutils.

cheers,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

On Wed, 23 Apr 2003 12:15:17 PDT, Chris Wright <chris@wirex.com>  said:
> * Andreas Dilger (adilger@clusterfs.com) wrote:

> > The only reason to use a common "system.security" is if the actual data
> > stored therein was usable by more than a single security module.
> 
> Or, as mentioned, if you care to print out the label with standard
> fileutils.

The requirement that things like ls, find, cp and so on know where to look
for these things trumps any "purity of labels" arguments.

In addition, a case can be made that different modules *should* use the
same name - because that way when you're re-labelling a file system for
a new security module, you can actually *detect* old crufty conflicting
labels added by some previous module.

"Warning: file %s was already labelled with attribute %s"

If you do as Chris suggests, you can't implement this in a clean manner.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Chris Wright]

* Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu) wrote:
> 
> The requirement that things like ls, find, cp and so on know where to look
> for these things trumps any "purity of labels" arguments.

Sorry, I don't follow you.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On Wed, 23 Apr 2003 12:40:51 PDT, Chris Wright said:
> * Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu) wrote:
> > 
> > The requirement that things like ls, find, cp and so on know where to look
> > for these things trumps any "purity of labels" arguments.
> 
> Sorry, I don't follow you.

Wrong Chris.  I meant Christoph Hellig's argument that each module should have
its own unique xattr, where other modules/tools wouldn't necessarily have
a reason to look, so you end up having to do a 'foreach xattr { guess if
this is really what we're looking for}' loop.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley]

On Wed, 2003-04-23 at 14:17, Christoph Hellwig wrote:
> First, please put the changes in the LSM API in a different patch from
> the xattr changes, they're a different issue.

I don't mind splitting them into a separate patch (and offered to do so
in the earlier posting against 2.5.67), but I don't agree that they are
a different issue.  The changes to the LSM xattr-related hooks are part
of supporting the use of extended attributes by security modules for
file security labels; the changes permit the security module to update
the inode security structure upon successful setxattr calls, and to
provide atomicity for the check and update of the security label.

> The other question is why do you name them system.security?  The name
> sounds a bit too generic to me.  ACLs are certainly a security feature
> and have different ATTRS, similar for the Posix capability and MAC
> support in XFS.  As selinux is the flask implementation for Linux
> what about system.flask_label?  (or system.selinux_label?)

The idea of using separate attribute names for each security module was
already discussed at length when I posted the original RFC, and I've
already made the case that this is not desirable.  Please see the
earlier discussion.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Christoph Hellwig]

On Wed, Apr 23, 2003 at 02:35:59PM -0400, Stephen Smalley wrote:
> The idea of using separate attribute names for each security module was
> already discussed at length when I posted the original RFC, and I've
> already made the case that this is not desirable.  Please see the
> earlier discussion.

No.  It's not acceptable that the same ondisk structure has a different
meaning depending on loaded modules.  If the xattrs have a different
meaning they _must_ have a different name.

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen Smalley]

On Wed, 2003-04-23 at 14:42, Christoph Hellwig wrote:
> No.  It's not acceptable that the same ondisk structure has a different
> meaning depending on loaded modules.  If the xattrs have a different
> meaning they _must_ have a different name.

Again, I'd suggest that you read the original discussion thread.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Christoph Hellwig]

On Wed, Apr 23, 2003 at 02:59:27PM -0400, Stephen Smalley wrote:
> On Wed, 2003-04-23 at 14:42, Christoph Hellwig wrote:
> > No.  It's not acceptable that the same ondisk structure has a different
> > meaning depending on loaded modules.  If the xattrs have a different
> > meaning they _must_ have a different name.
> 
> Again, I'd suggest that you read the original discussion thread.

Again I did read it and your design doesn't get any better by just
reposting it.

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Jakob Oestergaard]

On Wed, Apr 23, 2003 at 07:42:54PM +0100, Christoph Hellwig wrote:
> On Wed, Apr 23, 2003 at 02:35:59PM -0400, Stephen Smalley wrote:
> > The idea of using separate attribute names for each security module was
> > already discussed at length when I posted the original RFC, and I've
> > already made the case that this is not desirable.  Please see the
> > earlier discussion.
> 
> No.  It's not acceptable that the same ondisk structure has a different
> meaning depending on loaded modules.  If the xattrs have a different
> meaning they _must_ have a different name.

A .xyz file in my filesystem may mean one thing to application X, and
another thing to application Y - and quite possibly only application X
is able to make sense of the information in my .xyz file, even though
both applications use the .xyz suffix for their files.

We accept this ambiguity in file systems.

(We accept a similar possibility for ambiguity for UDP/TCP ports,
process names, etc. etc. etc.)

Even if I don't have application X installed, I can still backup and
restore my .xyz file.   Because the tools use a common interface.

Why do extended attributes have to be different?  (And who will maintain
the authorative registry over allocated xattr names?)

In my little mind it makes sense to have security information one
specific and well defined place.  Then, depending on the kernel security
model, it can either make sense of the information, or it can not.

If I insert a disk with MLS labelled files in a TE system, I cannot
expect the system to magically enforce the MLS policy - but my tools
will still work.  I think that sounds beneficial.   In fact, for
disaster recovery, it sounds pretty damn convenient in my ears.

Tell me what I am missing here, please.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: [PATCH] Extended Attributes for Security Modules against 2.5.68

[Stephen C. Tweedie]

Hi,

On Wed, 2003-04-23 at 19:42, Christoph Hellwig wrote:
> On Wed, Apr 23, 2003 at 02:35:59PM -0400, Stephen Smalley wrote:
> > The idea of using separate attribute names for each security module was
> > already discussed at length when I posted the original RFC, and I've
> > already made the case that this is not desirable.  Please see the
> > earlier discussion.
> 
> No.  It's not acceptable that the same ondisk structure has a different
> meaning depending on loaded modules.  If the xattrs have a different
> meaning they _must_ have a different name.

I'm not convinced --- I don't see much value in trying to preserve MAC
semantics over load/unload of different security modules, so for sanity
the important thing is just to be able to detect whether a security
xattr "belongs" to the current module or not.  That can be done with a
simple prefix in the xattr value itself.  Trying to make multiple MAC
labels coexist in different xattrs seems to have little use.

--Stephen