All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 13:45 ` Nicolas Belouin
  0 siblings, 0 replies; 42+ messages in thread
From: Nicolas Belouin @ 2017-10-21 13:45 UTC (permalink / raw)
  To: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4, linux-kernel, linux-f2fs-devel, linux-fsdevel,
	linux-mtd, jfs-discussion, ocfs2-devel, linux-unionfs,
	reiserfs-devel, linux-security-module, selinux, linux-api,
	kernel-hardening
  Cc: Nicolas Belouin

with CAP_SYS_ADMIN being bloated, the usefulness of using it to
flag a process to be entrusted for e.g reading and writing trusted
xattr is near zero.
CAP_TRUSTED aims to provide userland with a way to mark a process as
entrusted to do specific (not specially admin-centered) actions. It
would for example allow a process to red/write the trusted xattrs.

Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
---
 include/uapi/linux/capability.h     | 6 +++++-
 security/selinux/include/classmap.h | 5 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index ce230aa6d928..27e457b93c84 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
 
 #define CAP_SYS_MOUNT		38
 
-#define CAP_LAST_CAP         CAP_SYS_MOUNT
+/* Allow read/write trusted xattr */
+
+#define CAP_TRUSTED		39
+
+#define CAP_LAST_CAP         CAP_TRUSTED
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index a873dce97fd5..f5dc8e109f5a 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -24,9 +24,10 @@
 	    "audit_control", "setfcap"
 
 #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
-		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
+		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
+		"trusted"
 
-#if CAP_LAST_CAP > CAP_SYS_MOUNT
+#if CAP_LAST_CAP > CAP_TRUSTED
 #error New capability defined, please update COMMON_CAP2_PERMS.
 #endif
 
-- 
2.14.2

^ permalink raw reply related	[flat|nested] 42+ messages in thread
* [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 13:45 ` Nicolas Belouin
  0 siblings, 0 replies; 42+ messages in thread
From: Nicolas Belouin @ 2017-10-21 13:45 UTC (permalink / raw)
  To: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4, linux-kernel, linux-f2fs-devel, linux-fsdevel,
	linux-mtd
  Cc: Nicolas Belouin

with CAP_SYS_ADMIN being bloated, the usefulness of using it to
flag a process to be entrusted for e.g reading and writing trusted
xattr is near zero.
CAP_TRUSTED aims to provide userland with a way to mark a process as
entrusted to do specific (not specially admin-centered) actions. It
would for example allow a process to red/write the trusted xattrs.

Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
---
 include/uapi/linux/capability.h     | 6 +++++-
 security/selinux/include/classmap.h | 5 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index ce230aa6d928..27e457b93c84 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
 
 #define CAP_SYS_MOUNT		38
 
-#define CAP_LAST_CAP         CAP_SYS_MOUNT
+/* Allow read/write trusted xattr */
+
+#define CAP_TRUSTED		39
+
+#define CAP_LAST_CAP         CAP_TRUSTED
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index a873dce97fd5..f5dc8e109f5a 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -24,9 +24,10 @@
 	    "audit_control", "setfcap"
 
 #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
-		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
+		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
+		"trusted"
 
-#if CAP_LAST_CAP > CAP_SYS_MOUNT
+#if CAP_LAST_CAP > CAP_TRUSTED
 #error New capability defined, please update COMMON_CAP2_PERMS.
 #endif
 
-- 
2.14.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 42+ messages in thread
* [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 13:45 ` Nicolas Belouin
  0 siblings, 0 replies; 42+ messages in thread
From: Nicolas Belouin @ 2017-10-21 13:45 UTC (permalink / raw)
  To: linux-security-module

with CAP_SYS_ADMIN being bloated, the usefulness of using it to
flag a process to be entrusted for e.g reading and writing trusted
xattr is near zero.
CAP_TRUSTED aims to provide userland with a way to mark a process as
entrusted to do specific (not specially admin-centered) actions. It
would for example allow a process to red/write the trusted xattrs.

Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
---
 include/uapi/linux/capability.h     | 6 +++++-
 security/selinux/include/classmap.h | 5 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index ce230aa6d928..27e457b93c84 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
 
 #define CAP_SYS_MOUNT		38
 
-#define CAP_LAST_CAP         CAP_SYS_MOUNT
+/* Allow read/write trusted xattr */
+
+#define CAP_TRUSTED		39
+
+#define CAP_LAST_CAP         CAP_TRUSTED
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index a873dce97fd5..f5dc8e109f5a 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -24,9 +24,10 @@
 	    "audit_control", "setfcap"
 
 #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
-		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
+		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
+		"trusted"
 
-#if CAP_LAST_CAP > CAP_SYS_MOUNT
+#if CAP_LAST_CAP > CAP_TRUSTED
 #error New capability defined, please update COMMON_CAP2_PERMS.
 #endif
 
-- 
2.14.2

--
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

^ permalink raw reply related	[flat|nested] 42+ messages in thread
* [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 13:45 ` Nicolas Belouin
  0 siblings, 0 replies; 42+ messages in thread
From: Nicolas Belouin @ 2017-10-21 13:45 UTC (permalink / raw)
  To: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4, linux-kernel, linux-f2fs-devel, linux-fsdevel,
	linux-mtd, jfs-discussion, ocfs2-devel, linux-unionfs,
	reiserfs-devel, linux-security-module, selinux, linux-api,
	kernel-hardening
  Cc: Nicolas Belouin

with CAP_SYS_ADMIN being bloated, the usefulness of using it to
flag a process to be entrusted for e.g reading and writing trusted
xattr is near zero.
CAP_TRUSTED aims to provide userland with a way to mark a process as
entrusted to do specific (not specially admin-centered) actions. It
would for example allow a process to red/write the trusted xattrs.

Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
---
 include/uapi/linux/capability.h     | 6 +++++-
 security/selinux/include/classmap.h | 5 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index ce230aa6d928..27e457b93c84 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
 
 #define CAP_SYS_MOUNT		38
 
-#define CAP_LAST_CAP         CAP_SYS_MOUNT
+/* Allow read/write trusted xattr */
+
+#define CAP_TRUSTED		39
+
+#define CAP_LAST_CAP         CAP_TRUSTED
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index a873dce97fd5..f5dc8e109f5a 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -24,9 +24,10 @@
 	    "audit_control", "setfcap"
 
 #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
-		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
+		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
+		"trusted"
 
-#if CAP_LAST_CAP > CAP_SYS_MOUNT
+#if CAP_LAST_CAP > CAP_TRUSTED
 #error New capability defined, please update COMMON_CAP2_PERMS.
 #endif
 
-- 
2.14.2

^ permalink raw reply related	[flat|nested] 42+ messages in thread
* [RFC PATCH 2/2] fs: Grant CAP_TRUSTED rw access to trusted xattrs
  2017-10-21 13:45 ` Nicolas Belouin
                   ` (4 preceding siblings ...)
  (?)
@ 2017-10-21 13:45 ` Nicolas Belouin
  -1 siblings, 0 replies; 42+ messages in thread
From: Nicolas Belouin @ 2017-10-21 13:45 UTC (permalink / raw)
  To: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4
  Cc: Nicolas Belouin

The trusted xattrs read/write access is the perfect use case for
CAP_TRUSTED.

Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
---
 fs/ext2/xattr_trusted.c     |  2 +-
 fs/ext4/xattr_trusted.c     |  2 +-
 fs/f2fs/xattr.c             |  6 +++---
 fs/hfsplus/xattr.c          |  2 +-
 fs/jffs2/xattr_trusted.c    |  2 +-
 fs/jfs/xattr.c              |  3 ++-
 fs/ocfs2/xattr.c            |  2 +-
 fs/overlayfs/inode.c        |  3 ++-
 fs/reiserfs/xattr_trusted.c | 11 ++++++++---
 fs/squashfs/xattr.c         |  2 +-
 fs/ubifs/xattr.c            |  3 ++-
 fs/xattr.c                  |  4 ++--
 12 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/fs/ext2/xattr_trusted.c b/fs/ext2/xattr_trusted.c
index 65049b71af13..8006c24f8ee0 100644
--- a/fs/ext2/xattr_trusted.c
+++ b/fs/ext2/xattr_trusted.c
@@ -11,7 +11,7 @@
 static bool
 ext2_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/ext4/xattr_trusted.c b/fs/ext4/xattr_trusted.c
index c7765c735714..9849d1e0ebb9 100644
--- a/fs/ext4/xattr_trusted.c
+++ b/fs/ext4/xattr_trusted.c
@@ -15,7 +15,7 @@
 static bool
 ext4_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 7c65540148f8..ef572464deca 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -37,7 +37,7 @@ static int f2fs_xattr_generic_get(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -62,7 +62,7 @@ static int f2fs_xattr_generic_set(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -83,7 +83,7 @@ static bool f2fs_xattr_user_list(struct dentry *dentry)
 
 static bool f2fs_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int f2fs_xattr_advise_get(const struct xattr_handler *handler,
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index ae03a19196ef..0ec6d02ee7e9 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -606,7 +606,7 @@ static inline int can_list(const char *xattr_name)
 
 	return !strncmp(xattr_name, XATTR_TRUSTED_PREFIX,
 			XATTR_TRUSTED_PREFIX_LEN) ||
-				capable(CAP_SYS_ADMIN);
+				capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static ssize_t hfsplus_listxattr_finder_info(struct dentry *dentry,
diff --git a/fs/jffs2/xattr_trusted.c b/fs/jffs2/xattr_trusted.c
index 5d6030826c52..3c7ae98e4525 100644
--- a/fs/jffs2/xattr_trusted.c
+++ b/fs/jffs2/xattr_trusted.c
@@ -35,7 +35,7 @@ static int jffs2_trusted_setxattr(const struct xattr_handler *handler,
 
 static bool jffs2_trusted_listxattr(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 const struct xattr_handler jffs2_trusted_xattr_handler = {
diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c
index 1c46573a96ed..e4f44f5133a1 100644
--- a/fs/jfs/xattr.c
+++ b/fs/jfs/xattr.c
@@ -859,7 +859,8 @@ ssize_t __jfs_getxattr(struct inode *inode, const char *name, void *data,
 static inline int can_list(struct jfs_ea *ea)
 {
 	return (!strncmp(ea->name, XATTR_TRUSTED_PREFIX,
-			 XATTR_TRUSTED_PREFIX_LEN) || capable(CAP_SYS_ADMIN));
+			 XATTR_TRUSTED_PREFIX_LEN) ||
+		capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t jfs_listxattr(struct dentry * dentry, char *data, size_t buf_size)
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 5fdf269ba82e..2b3994d192c6 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -906,7 +906,7 @@ static int ocfs2_xattr_list_entry(struct super_block *sb,
 		break;
 
 	case OCFS2_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return 0;
 		break;
 	}
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index a619addecafc..c627003d3a74 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -264,7 +264,8 @@ static bool ovl_can_list(const char *s)
 		return true;
 
 	/* Never list trusted.overlay, list other trusted for superuser only */
-	return !ovl_is_private_xattr(s) && capable(CAP_SYS_ADMIN);
+	return !ovl_is_private_xattr(s) &&
+		(capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t ovl_listxattr(struct dentry *dentry, char *list, size_t size)
diff --git a/fs/reiserfs/xattr_trusted.c b/fs/reiserfs/xattr_trusted.c
index f15a5f9e84ce..6f3fa0db8272 100644
--- a/fs/reiserfs/xattr_trusted.c
+++ b/fs/reiserfs/xattr_trusted.c
@@ -7,11 +7,16 @@
 #include "xattr.h"
 #include <linux/uaccess.h>
 
+inline bool trusted_capable(void)
+{
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
+}
+
 static int
 trusted_get(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, void *buffer, size_t size)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_get(inode, xattr_full_name(handler, name),
@@ -23,7 +28,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, const void *buffer,
 	    size_t size, int flags)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_set(inode,
@@ -33,7 +38,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 
 static bool trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN) && !IS_PRIVATE(d_inode(dentry));
+	return trusted_capable() && !IS_PRIVATE(d_inode(dentry));
 }
 
 const struct xattr_handler reiserfs_xattr_trusted_handler = {
diff --git a/fs/squashfs/xattr.c b/fs/squashfs/xattr.c
index 1548b3784548..e0a285ab1f7e 100644
--- a/fs/squashfs/xattr.c
+++ b/fs/squashfs/xattr.c
@@ -237,7 +237,7 @@ static const struct xattr_handler squashfs_xattr_user_handler = {
  */
 static bool squashfs_trusted_xattr_handler_list(struct dentry *d)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static const struct xattr_handler squashfs_xattr_trusted_handler = {
diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
index c13eae819cbc..f3aa8be72a66 100644
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -406,7 +406,8 @@ static bool xattr_visible(const char *name)
 
 	/* Show trusted namespace only for "power" users */
 	if (strncmp(name, XATTR_TRUSTED_PREFIX,
-		    XATTR_TRUSTED_PREFIX_LEN) == 0 && !capable(CAP_SYS_ADMIN))
+		    XATTR_TRUSTED_PREFIX_LEN) == 0 &&
+	    !capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 		return false;
 
 	return true;
diff --git a/fs/xattr.c b/fs/xattr.c
index 61cd28ba25f3..d9e9a0083dbb 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -113,7 +113,7 @@ xattr_permission(struct inode *inode, const char *name, int mask)
 	 * The trusted.* namespace can only be accessed by privileged users.
 	 */
 	if (!strncmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN)) {
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return (mask & MAY_WRITE) ? -EPERM : -ENODATA;
 		return 0;
 	}
@@ -945,7 +945,7 @@ static int xattr_list_one(char **buffer, ssize_t *remaining_size,
 ssize_t simple_xattr_list(struct inode *inode, struct simple_xattrs *xattrs,
 			  char *buffer, size_t size)
 {
-	bool trusted = capable(CAP_SYS_ADMIN);
+	bool trusted = capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 	struct simple_xattr *xattr;
 	ssize_t remaining_size = size;
 	int err = 0;
-- 
2.14.2

^ permalink raw reply related	[flat|nested] 42+ messages in thread
* [RFC PATCH 2/2] fs: Grant CAP_TRUSTED rw access to trusted xattrs
  2017-10-21 13:45 ` Nicolas Belouin
  (?)
  (?)
@ 2017-10-21 13:45   ` Nicolas Belouin
  -1 siblings, 0 replies; 42+ messages in thread
From: Nicolas Belouin @ 2017-10-21 13:45 UTC (permalink / raw)
  To: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4, linux-kernel, linux-f2fs-devel, linux-fsdevel,
	linux-mtd, jfs-discussion, ocfs2-devel, linux-unionfs,
	reiserfs-devel, linux-security-module, selinux, linux-api,
	kernel-hardening
  Cc: Nicolas Belouin

The trusted xattrs read/write access is the perfect use case for
CAP_TRUSTED.

Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
---
 fs/ext2/xattr_trusted.c     |  2 +-
 fs/ext4/xattr_trusted.c     |  2 +-
 fs/f2fs/xattr.c             |  6 +++---
 fs/hfsplus/xattr.c          |  2 +-
 fs/jffs2/xattr_trusted.c    |  2 +-
 fs/jfs/xattr.c              |  3 ++-
 fs/ocfs2/xattr.c            |  2 +-
 fs/overlayfs/inode.c        |  3 ++-
 fs/reiserfs/xattr_trusted.c | 11 ++++++++---
 fs/squashfs/xattr.c         |  2 +-
 fs/ubifs/xattr.c            |  3 ++-
 fs/xattr.c                  |  4 ++--
 12 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/fs/ext2/xattr_trusted.c b/fs/ext2/xattr_trusted.c
index 65049b71af13..8006c24f8ee0 100644
--- a/fs/ext2/xattr_trusted.c
+++ b/fs/ext2/xattr_trusted.c
@@ -11,7 +11,7 @@
 static bool
 ext2_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/ext4/xattr_trusted.c b/fs/ext4/xattr_trusted.c
index c7765c735714..9849d1e0ebb9 100644
--- a/fs/ext4/xattr_trusted.c
+++ b/fs/ext4/xattr_trusted.c
@@ -15,7 +15,7 @@
 static bool
 ext4_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 7c65540148f8..ef572464deca 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -37,7 +37,7 @@ static int f2fs_xattr_generic_get(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -62,7 +62,7 @@ static int f2fs_xattr_generic_set(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -83,7 +83,7 @@ static bool f2fs_xattr_user_list(struct dentry *dentry)
 
 static bool f2fs_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int f2fs_xattr_advise_get(const struct xattr_handler *handler,
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index ae03a19196ef..0ec6d02ee7e9 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -606,7 +606,7 @@ static inline int can_list(const char *xattr_name)
 
 	return !strncmp(xattr_name, XATTR_TRUSTED_PREFIX,
 			XATTR_TRUSTED_PREFIX_LEN) ||
-				capable(CAP_SYS_ADMIN);
+				capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static ssize_t hfsplus_listxattr_finder_info(struct dentry *dentry,
diff --git a/fs/jffs2/xattr_trusted.c b/fs/jffs2/xattr_trusted.c
index 5d6030826c52..3c7ae98e4525 100644
--- a/fs/jffs2/xattr_trusted.c
+++ b/fs/jffs2/xattr_trusted.c
@@ -35,7 +35,7 @@ static int jffs2_trusted_setxattr(const struct xattr_handler *handler,
 
 static bool jffs2_trusted_listxattr(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 const struct xattr_handler jffs2_trusted_xattr_handler = {
diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c
index 1c46573a96ed..e4f44f5133a1 100644
--- a/fs/jfs/xattr.c
+++ b/fs/jfs/xattr.c
@@ -859,7 +859,8 @@ ssize_t __jfs_getxattr(struct inode *inode, const char *name, void *data,
 static inline int can_list(struct jfs_ea *ea)
 {
 	return (!strncmp(ea->name, XATTR_TRUSTED_PREFIX,
-			 XATTR_TRUSTED_PREFIX_LEN) || capable(CAP_SYS_ADMIN));
+			 XATTR_TRUSTED_PREFIX_LEN) ||
+		capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t jfs_listxattr(struct dentry * dentry, char *data, size_t buf_size)
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 5fdf269ba82e..2b3994d192c6 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -906,7 +906,7 @@ static int ocfs2_xattr_list_entry(struct super_block *sb,
 		break;
 
 	case OCFS2_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return 0;
 		break;
 	}
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index a619addecafc..c627003d3a74 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -264,7 +264,8 @@ static bool ovl_can_list(const char *s)
 		return true;
 
 	/* Never list trusted.overlay, list other trusted for superuser only */
-	return !ovl_is_private_xattr(s) && capable(CAP_SYS_ADMIN);
+	return !ovl_is_private_xattr(s) &&
+		(capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t ovl_listxattr(struct dentry *dentry, char *list, size_t size)
diff --git a/fs/reiserfs/xattr_trusted.c b/fs/reiserfs/xattr_trusted.c
index f15a5f9e84ce..6f3fa0db8272 100644
--- a/fs/reiserfs/xattr_trusted.c
+++ b/fs/reiserfs/xattr_trusted.c
@@ -7,11 +7,16 @@
 #include "xattr.h"
 #include <linux/uaccess.h>
 
+inline bool trusted_capable(void)
+{
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
+}
+
 static int
 trusted_get(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, void *buffer, size_t size)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_get(inode, xattr_full_name(handler, name),
@@ -23,7 +28,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, const void *buffer,
 	    size_t size, int flags)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_set(inode,
@@ -33,7 +38,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 
 static bool trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN) && !IS_PRIVATE(d_inode(dentry));
+	return trusted_capable() && !IS_PRIVATE(d_inode(dentry));
 }
 
 const struct xattr_handler reiserfs_xattr_trusted_handler = {
diff --git a/fs/squashfs/xattr.c b/fs/squashfs/xattr.c
index 1548b3784548..e0a285ab1f7e 100644
--- a/fs/squashfs/xattr.c
+++ b/fs/squashfs/xattr.c
@@ -237,7 +237,7 @@ static const struct xattr_handler squashfs_xattr_user_handler = {
  */
 static bool squashfs_trusted_xattr_handler_list(struct dentry *d)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static const struct xattr_handler squashfs_xattr_trusted_handler = {
diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
index c13eae819cbc..f3aa8be72a66 100644
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -406,7 +406,8 @@ static bool xattr_visible(const char *name)
 
 	/* Show trusted namespace only for "power" users */
 	if (strncmp(name, XATTR_TRUSTED_PREFIX,
-		    XATTR_TRUSTED_PREFIX_LEN) == 0 && !capable(CAP_SYS_ADMIN))
+		    XATTR_TRUSTED_PREFIX_LEN) == 0 &&
+	    !capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 		return false;
 
 	return true;
diff --git a/fs/xattr.c b/fs/xattr.c
index 61cd28ba25f3..d9e9a0083dbb 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -113,7 +113,7 @@ xattr_permission(struct inode *inode, const char *name, int mask)
 	 * The trusted.* namespace can only be accessed by privileged users.
 	 */
 	if (!strncmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN)) {
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return (mask & MAY_WRITE) ? -EPERM : -ENODATA;
 		return 0;
 	}
@@ -945,7 +945,7 @@ static int xattr_list_one(char **buffer, ssize_t *remaining_size,
 ssize_t simple_xattr_list(struct inode *inode, struct simple_xattrs *xattrs,
 			  char *buffer, size_t size)
 {
-	bool trusted = capable(CAP_SYS_ADMIN);
+	bool trusted = capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 	struct simple_xattr *xattr;
 	ssize_t remaining_size = size;
 	int err = 0;
-- 
2.14.2

^ permalink raw reply related	[flat|nested] 42+ messages in thread
* [RFC PATCH 2/2] fs: Grant CAP_TRUSTED rw access to trusted xattrs
@ 2017-10-21 13:45   ` Nicolas Belouin
  0 siblings, 0 replies; 42+ messages in thread
From: Nicolas Belouin @ 2017-10-21 13:45 UTC (permalink / raw)
  To: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4, linux-kernel, linux-f2fs-devel, linux-fsdevel,
	linux-mtd
  Cc: Nicolas Belouin

The trusted xattrs read/write access is the perfect use case for
CAP_TRUSTED.

Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
---
 fs/ext2/xattr_trusted.c     |  2 +-
 fs/ext4/xattr_trusted.c     |  2 +-
 fs/f2fs/xattr.c             |  6 +++---
 fs/hfsplus/xattr.c          |  2 +-
 fs/jffs2/xattr_trusted.c    |  2 +-
 fs/jfs/xattr.c              |  3 ++-
 fs/ocfs2/xattr.c            |  2 +-
 fs/overlayfs/inode.c        |  3 ++-
 fs/reiserfs/xattr_trusted.c | 11 ++++++++---
 fs/squashfs/xattr.c         |  2 +-
 fs/ubifs/xattr.c            |  3 ++-
 fs/xattr.c                  |  4 ++--
 12 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/fs/ext2/xattr_trusted.c b/fs/ext2/xattr_trusted.c
index 65049b71af13..8006c24f8ee0 100644
--- a/fs/ext2/xattr_trusted.c
+++ b/fs/ext2/xattr_trusted.c
@@ -11,7 +11,7 @@
 static bool
 ext2_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/ext4/xattr_trusted.c b/fs/ext4/xattr_trusted.c
index c7765c735714..9849d1e0ebb9 100644
--- a/fs/ext4/xattr_trusted.c
+++ b/fs/ext4/xattr_trusted.c
@@ -15,7 +15,7 @@
 static bool
 ext4_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 7c65540148f8..ef572464deca 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -37,7 +37,7 @@ static int f2fs_xattr_generic_get(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -62,7 +62,7 @@ static int f2fs_xattr_generic_set(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -83,7 +83,7 @@ static bool f2fs_xattr_user_list(struct dentry *dentry)
 
 static bool f2fs_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int f2fs_xattr_advise_get(const struct xattr_handler *handler,
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index ae03a19196ef..0ec6d02ee7e9 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -606,7 +606,7 @@ static inline int can_list(const char *xattr_name)
 
 	return !strncmp(xattr_name, XATTR_TRUSTED_PREFIX,
 			XATTR_TRUSTED_PREFIX_LEN) ||
-				capable(CAP_SYS_ADMIN);
+				capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static ssize_t hfsplus_listxattr_finder_info(struct dentry *dentry,
diff --git a/fs/jffs2/xattr_trusted.c b/fs/jffs2/xattr_trusted.c
index 5d6030826c52..3c7ae98e4525 100644
--- a/fs/jffs2/xattr_trusted.c
+++ b/fs/jffs2/xattr_trusted.c
@@ -35,7 +35,7 @@ static int jffs2_trusted_setxattr(const struct xattr_handler *handler,
 
 static bool jffs2_trusted_listxattr(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 const struct xattr_handler jffs2_trusted_xattr_handler = {
diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c
index 1c46573a96ed..e4f44f5133a1 100644
--- a/fs/jfs/xattr.c
+++ b/fs/jfs/xattr.c
@@ -859,7 +859,8 @@ ssize_t __jfs_getxattr(struct inode *inode, const char *name, void *data,
 static inline int can_list(struct jfs_ea *ea)
 {
 	return (!strncmp(ea->name, XATTR_TRUSTED_PREFIX,
-			 XATTR_TRUSTED_PREFIX_LEN) || capable(CAP_SYS_ADMIN));
+			 XATTR_TRUSTED_PREFIX_LEN) ||
+		capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t jfs_listxattr(struct dentry * dentry, char *data, size_t buf_size)
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 5fdf269ba82e..2b3994d192c6 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -906,7 +906,7 @@ static int ocfs2_xattr_list_entry(struct super_block *sb,
 		break;
 
 	case OCFS2_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return 0;
 		break;
 	}
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index a619addecafc..c627003d3a74 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -264,7 +264,8 @@ static bool ovl_can_list(const char *s)
 		return true;
 
 	/* Never list trusted.overlay, list other trusted for superuser only */
-	return !ovl_is_private_xattr(s) && capable(CAP_SYS_ADMIN);
+	return !ovl_is_private_xattr(s) &&
+		(capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t ovl_listxattr(struct dentry *dentry, char *list, size_t size)
diff --git a/fs/reiserfs/xattr_trusted.c b/fs/reiserfs/xattr_trusted.c
index f15a5f9e84ce..6f3fa0db8272 100644
--- a/fs/reiserfs/xattr_trusted.c
+++ b/fs/reiserfs/xattr_trusted.c
@@ -7,11 +7,16 @@
 #include "xattr.h"
 #include <linux/uaccess.h>
 
+inline bool trusted_capable(void)
+{
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
+}
+
 static int
 trusted_get(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, void *buffer, size_t size)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_get(inode, xattr_full_name(handler, name),
@@ -23,7 +28,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, const void *buffer,
 	    size_t size, int flags)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_set(inode,
@@ -33,7 +38,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 
 static bool trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN) && !IS_PRIVATE(d_inode(dentry));
+	return trusted_capable() && !IS_PRIVATE(d_inode(dentry));
 }
 
 const struct xattr_handler reiserfs_xattr_trusted_handler = {
diff --git a/fs/squashfs/xattr.c b/fs/squashfs/xattr.c
index 1548b3784548..e0a285ab1f7e 100644
--- a/fs/squashfs/xattr.c
+++ b/fs/squashfs/xattr.c
@@ -237,7 +237,7 @@ static const struct xattr_handler squashfs_xattr_user_handler = {
  */
 static bool squashfs_trusted_xattr_handler_list(struct dentry *d)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static const struct xattr_handler squashfs_xattr_trusted_handler = {
diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
index c13eae819cbc..f3aa8be72a66 100644
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -406,7 +406,8 @@ static bool xattr_visible(const char *name)
 
 	/* Show trusted namespace only for "power" users */
 	if (strncmp(name, XATTR_TRUSTED_PREFIX,
-		    XATTR_TRUSTED_PREFIX_LEN) == 0 && !capable(CAP_SYS_ADMIN))
+		    XATTR_TRUSTED_PREFIX_LEN) == 0 &&
+	    !capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 		return false;
 
 	return true;
diff --git a/fs/xattr.c b/fs/xattr.c
index 61cd28ba25f3..d9e9a0083dbb 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -113,7 +113,7 @@ xattr_permission(struct inode *inode, const char *name, int mask)
 	 * The trusted.* namespace can only be accessed by privileged users.
 	 */
 	if (!strncmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN)) {
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return (mask & MAY_WRITE) ? -EPERM : -ENODATA;
 		return 0;
 	}
@@ -945,7 +945,7 @@ static int xattr_list_one(char **buffer, ssize_t *remaining_size,
 ssize_t simple_xattr_list(struct inode *inode, struct simple_xattrs *xattrs,
 			  char *buffer, size_t size)
 {
-	bool trusted = capable(CAP_SYS_ADMIN);
+	bool trusted = capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 	struct simple_xattr *xattr;
 	ssize_t remaining_size = size;
 	int err = 0;
-- 
2.14.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 42+ messages in thread
* [RFC PATCH 2/2] fs: Grant CAP_TRUSTED rw access to trusted xattrs
       [not found] ` <20171021134558.21195-1-nicolas-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>
@ 2017-10-21 13:45   ` Nicolas Belouin
  2017-10-21 17:25   ` [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED Casey Schaufler
  2017-10-21 17:25   ` Casey Schaufler
  2 siblings, 0 replies; 42+ messages in thread
From: Nicolas Belouin @ 2017-10-21 13:45 UTC (permalink / raw)
  To: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4-u79uwXL29TZUIDd8j+nm9g
  Cc: Nicolas Belouin

The trusted xattrs read/write access is the perfect use case for
CAP_TRUSTED.

Signed-off-by: Nicolas Belouin <nicolas-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>
---
 fs/ext2/xattr_trusted.c     |  2 +-
 fs/ext4/xattr_trusted.c     |  2 +-
 fs/f2fs/xattr.c             |  6 +++---
 fs/hfsplus/xattr.c          |  2 +-
 fs/jffs2/xattr_trusted.c    |  2 +-
 fs/jfs/xattr.c              |  3 ++-
 fs/ocfs2/xattr.c            |  2 +-
 fs/overlayfs/inode.c        |  3 ++-
 fs/reiserfs/xattr_trusted.c | 11 ++++++++---
 fs/squashfs/xattr.c         |  2 +-
 fs/ubifs/xattr.c            |  3 ++-
 fs/xattr.c                  |  4 ++--
 12 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/fs/ext2/xattr_trusted.c b/fs/ext2/xattr_trusted.c
index 65049b71af13..8006c24f8ee0 100644
--- a/fs/ext2/xattr_trusted.c
+++ b/fs/ext2/xattr_trusted.c
@@ -11,7 +11,7 @@
 static bool
 ext2_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/ext4/xattr_trusted.c b/fs/ext4/xattr_trusted.c
index c7765c735714..9849d1e0ebb9 100644
--- a/fs/ext4/xattr_trusted.c
+++ b/fs/ext4/xattr_trusted.c
@@ -15,7 +15,7 @@
 static bool
 ext4_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 7c65540148f8..ef572464deca 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -37,7 +37,7 @@ static int f2fs_xattr_generic_get(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -62,7 +62,7 @@ static int f2fs_xattr_generic_set(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -83,7 +83,7 @@ static bool f2fs_xattr_user_list(struct dentry *dentry)
 
 static bool f2fs_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int f2fs_xattr_advise_get(const struct xattr_handler *handler,
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index ae03a19196ef..0ec6d02ee7e9 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -606,7 +606,7 @@ static inline int can_list(const char *xattr_name)
 
 	return !strncmp(xattr_name, XATTR_TRUSTED_PREFIX,
 			XATTR_TRUSTED_PREFIX_LEN) ||
-				capable(CAP_SYS_ADMIN);
+				capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static ssize_t hfsplus_listxattr_finder_info(struct dentry *dentry,
diff --git a/fs/jffs2/xattr_trusted.c b/fs/jffs2/xattr_trusted.c
index 5d6030826c52..3c7ae98e4525 100644
--- a/fs/jffs2/xattr_trusted.c
+++ b/fs/jffs2/xattr_trusted.c
@@ -35,7 +35,7 @@ static int jffs2_trusted_setxattr(const struct xattr_handler *handler,
 
 static bool jffs2_trusted_listxattr(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 const struct xattr_handler jffs2_trusted_xattr_handler = {
diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c
index 1c46573a96ed..e4f44f5133a1 100644
--- a/fs/jfs/xattr.c
+++ b/fs/jfs/xattr.c
@@ -859,7 +859,8 @@ ssize_t __jfs_getxattr(struct inode *inode, const char *name, void *data,
 static inline int can_list(struct jfs_ea *ea)
 {
 	return (!strncmp(ea->name, XATTR_TRUSTED_PREFIX,
-			 XATTR_TRUSTED_PREFIX_LEN) || capable(CAP_SYS_ADMIN));
+			 XATTR_TRUSTED_PREFIX_LEN) ||
+		capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t jfs_listxattr(struct dentry * dentry, char *data, size_t buf_size)
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 5fdf269ba82e..2b3994d192c6 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -906,7 +906,7 @@ static int ocfs2_xattr_list_entry(struct super_block *sb,
 		break;
 
 	case OCFS2_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return 0;
 		break;
 	}
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index a619addecafc..c627003d3a74 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -264,7 +264,8 @@ static bool ovl_can_list(const char *s)
 		return true;
 
 	/* Never list trusted.overlay, list other trusted for superuser only */
-	return !ovl_is_private_xattr(s) && capable(CAP_SYS_ADMIN);
+	return !ovl_is_private_xattr(s) &&
+		(capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t ovl_listxattr(struct dentry *dentry, char *list, size_t size)
diff --git a/fs/reiserfs/xattr_trusted.c b/fs/reiserfs/xattr_trusted.c
index f15a5f9e84ce..6f3fa0db8272 100644
--- a/fs/reiserfs/xattr_trusted.c
+++ b/fs/reiserfs/xattr_trusted.c
@@ -7,11 +7,16 @@
 #include "xattr.h"
 #include <linux/uaccess.h>
 
+inline bool trusted_capable(void)
+{
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
+}
+
 static int
 trusted_get(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, void *buffer, size_t size)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_get(inode, xattr_full_name(handler, name),
@@ -23,7 +28,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, const void *buffer,
 	    size_t size, int flags)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_set(inode,
@@ -33,7 +38,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 
 static bool trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN) && !IS_PRIVATE(d_inode(dentry));
+	return trusted_capable() && !IS_PRIVATE(d_inode(dentry));
 }
 
 const struct xattr_handler reiserfs_xattr_trusted_handler = {
diff --git a/fs/squashfs/xattr.c b/fs/squashfs/xattr.c
index 1548b3784548..e0a285ab1f7e 100644
--- a/fs/squashfs/xattr.c
+++ b/fs/squashfs/xattr.c
@@ -237,7 +237,7 @@ static const struct xattr_handler squashfs_xattr_user_handler = {
  */
 static bool squashfs_trusted_xattr_handler_list(struct dentry *d)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static const struct xattr_handler squashfs_xattr_trusted_handler = {
diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
index c13eae819cbc..f3aa8be72a66 100644
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -406,7 +406,8 @@ static bool xattr_visible(const char *name)
 
 	/* Show trusted namespace only for "power" users */
 	if (strncmp(name, XATTR_TRUSTED_PREFIX,
-		    XATTR_TRUSTED_PREFIX_LEN) == 0 && !capable(CAP_SYS_ADMIN))
+		    XATTR_TRUSTED_PREFIX_LEN) == 0 &&
+	    !capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 		return false;
 
 	return true;
diff --git a/fs/xattr.c b/fs/xattr.c
index 61cd28ba25f3..d9e9a0083dbb 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -113,7 +113,7 @@ xattr_permission(struct inode *inode, const char *name, int mask)
 	 * The trusted.* namespace can only be accessed by privileged users.
 	 */
 	if (!strncmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN)) {
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return (mask & MAY_WRITE) ? -EPERM : -ENODATA;
 		return 0;
 	}
@@ -945,7 +945,7 @@ static int xattr_list_one(char **buffer, ssize_t *remaining_size,
 ssize_t simple_xattr_list(struct inode *inode, struct simple_xattrs *xattrs,
 			  char *buffer, size_t size)
 {
-	bool trusted = capable(CAP_SYS_ADMIN);
+	bool trusted = capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 	struct simple_xattr *xattr;
 	ssize_t remaining_size = size;
 	int err = 0;
-- 
2.14.2

^ permalink raw reply related	[flat|nested] 42+ messages in thread
* [RFC PATCH 2/2] fs: Grant CAP_TRUSTED rw access to trusted xattrs
@ 2017-10-21 13:45   ` Nicolas Belouin
  0 siblings, 0 replies; 42+ messages in thread
From: Nicolas Belouin @ 2017-10-21 13:45 UTC (permalink / raw)
  To: linux-security-module

The trusted xattrs read/write access is the perfect use case for
CAP_TRUSTED.

Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
---
 fs/ext2/xattr_trusted.c     |  2 +-
 fs/ext4/xattr_trusted.c     |  2 +-
 fs/f2fs/xattr.c             |  6 +++---
 fs/hfsplus/xattr.c          |  2 +-
 fs/jffs2/xattr_trusted.c    |  2 +-
 fs/jfs/xattr.c              |  3 ++-
 fs/ocfs2/xattr.c            |  2 +-
 fs/overlayfs/inode.c        |  3 ++-
 fs/reiserfs/xattr_trusted.c | 11 ++++++++---
 fs/squashfs/xattr.c         |  2 +-
 fs/ubifs/xattr.c            |  3 ++-
 fs/xattr.c                  |  4 ++--
 12 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/fs/ext2/xattr_trusted.c b/fs/ext2/xattr_trusted.c
index 65049b71af13..8006c24f8ee0 100644
--- a/fs/ext2/xattr_trusted.c
+++ b/fs/ext2/xattr_trusted.c
@@ -11,7 +11,7 @@
 static bool
 ext2_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/ext4/xattr_trusted.c b/fs/ext4/xattr_trusted.c
index c7765c735714..9849d1e0ebb9 100644
--- a/fs/ext4/xattr_trusted.c
+++ b/fs/ext4/xattr_trusted.c
@@ -15,7 +15,7 @@
 static bool
 ext4_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 7c65540148f8..ef572464deca 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -37,7 +37,7 @@ static int f2fs_xattr_generic_get(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -62,7 +62,7 @@ static int f2fs_xattr_generic_set(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -83,7 +83,7 @@ static bool f2fs_xattr_user_list(struct dentry *dentry)
 
 static bool f2fs_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int f2fs_xattr_advise_get(const struct xattr_handler *handler,
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index ae03a19196ef..0ec6d02ee7e9 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -606,7 +606,7 @@ static inline int can_list(const char *xattr_name)
 
 	return !strncmp(xattr_name, XATTR_TRUSTED_PREFIX,
 			XATTR_TRUSTED_PREFIX_LEN) ||
-				capable(CAP_SYS_ADMIN);
+				capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static ssize_t hfsplus_listxattr_finder_info(struct dentry *dentry,
diff --git a/fs/jffs2/xattr_trusted.c b/fs/jffs2/xattr_trusted.c
index 5d6030826c52..3c7ae98e4525 100644
--- a/fs/jffs2/xattr_trusted.c
+++ b/fs/jffs2/xattr_trusted.c
@@ -35,7 +35,7 @@ static int jffs2_trusted_setxattr(const struct xattr_handler *handler,
 
 static bool jffs2_trusted_listxattr(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 const struct xattr_handler jffs2_trusted_xattr_handler = {
diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c
index 1c46573a96ed..e4f44f5133a1 100644
--- a/fs/jfs/xattr.c
+++ b/fs/jfs/xattr.c
@@ -859,7 +859,8 @@ ssize_t __jfs_getxattr(struct inode *inode, const char *name, void *data,
 static inline int can_list(struct jfs_ea *ea)
 {
 	return (!strncmp(ea->name, XATTR_TRUSTED_PREFIX,
-			 XATTR_TRUSTED_PREFIX_LEN) || capable(CAP_SYS_ADMIN));
+			 XATTR_TRUSTED_PREFIX_LEN) ||
+		capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t jfs_listxattr(struct dentry * dentry, char *data, size_t buf_size)
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 5fdf269ba82e..2b3994d192c6 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -906,7 +906,7 @@ static int ocfs2_xattr_list_entry(struct super_block *sb,
 		break;
 
 	case OCFS2_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return 0;
 		break;
 	}
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index a619addecafc..c627003d3a74 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -264,7 +264,8 @@ static bool ovl_can_list(const char *s)
 		return true;
 
 	/* Never list trusted.overlay, list other trusted for superuser only */
-	return !ovl_is_private_xattr(s) && capable(CAP_SYS_ADMIN);
+	return !ovl_is_private_xattr(s) &&
+		(capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t ovl_listxattr(struct dentry *dentry, char *list, size_t size)
diff --git a/fs/reiserfs/xattr_trusted.c b/fs/reiserfs/xattr_trusted.c
index f15a5f9e84ce..6f3fa0db8272 100644
--- a/fs/reiserfs/xattr_trusted.c
+++ b/fs/reiserfs/xattr_trusted.c
@@ -7,11 +7,16 @@
 #include "xattr.h"
 #include <linux/uaccess.h>
 
+inline bool trusted_capable(void)
+{
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
+}
+
 static int
 trusted_get(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, void *buffer, size_t size)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_get(inode, xattr_full_name(handler, name),
@@ -23,7 +28,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, const void *buffer,
 	    size_t size, int flags)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_set(inode,
@@ -33,7 +38,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 
 static bool trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN) && !IS_PRIVATE(d_inode(dentry));
+	return trusted_capable() && !IS_PRIVATE(d_inode(dentry));
 }
 
 const struct xattr_handler reiserfs_xattr_trusted_handler = {
diff --git a/fs/squashfs/xattr.c b/fs/squashfs/xattr.c
index 1548b3784548..e0a285ab1f7e 100644
--- a/fs/squashfs/xattr.c
+++ b/fs/squashfs/xattr.c
@@ -237,7 +237,7 @@ static const struct xattr_handler squashfs_xattr_user_handler = {
  */
 static bool squashfs_trusted_xattr_handler_list(struct dentry *d)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static const struct xattr_handler squashfs_xattr_trusted_handler = {
diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
index c13eae819cbc..f3aa8be72a66 100644
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -406,7 +406,8 @@ static bool xattr_visible(const char *name)
 
 	/* Show trusted namespace only for "power" users */
 	if (strncmp(name, XATTR_TRUSTED_PREFIX,
-		    XATTR_TRUSTED_PREFIX_LEN) == 0 && !capable(CAP_SYS_ADMIN))
+		    XATTR_TRUSTED_PREFIX_LEN) == 0 &&
+	    !capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 		return false;
 
 	return true;
diff --git a/fs/xattr.c b/fs/xattr.c
index 61cd28ba25f3..d9e9a0083dbb 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -113,7 +113,7 @@ xattr_permission(struct inode *inode, const char *name, int mask)
 	 * The trusted.* namespace can only be accessed by privileged users.
 	 */
 	if (!strncmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN)) {
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return (mask & MAY_WRITE) ? -EPERM : -ENODATA;
 		return 0;
 	}
@@ -945,7 +945,7 @@ static int xattr_list_one(char **buffer, ssize_t *remaining_size,
 ssize_t simple_xattr_list(struct inode *inode, struct simple_xattrs *xattrs,
 			  char *buffer, size_t size)
 {
-	bool trusted = capable(CAP_SYS_ADMIN);
+	bool trusted = capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 	struct simple_xattr *xattr;
 	ssize_t remaining_size = size;
 	int err = 0;
-- 
2.14.2

--
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

^ permalink raw reply related	[flat|nested] 42+ messages in thread
* [kernel-hardening] [RFC PATCH 2/2] fs: Grant CAP_TRUSTED rw access to trusted xattrs
@ 2017-10-21 13:45   ` Nicolas Belouin
  0 siblings, 0 replies; 42+ messages in thread
From: Nicolas Belouin @ 2017-10-21 13:45 UTC (permalink / raw)
  To: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4, linux-kernel, linux-f2fs-devel, linux-fsdevel,
	linux-mtd, jfs-discussion, ocfs2-devel, linux-unionfs,
	reiserfs-devel, linux-security-module, selinux, linux-api,
	kernel-hardening
  Cc: Nicolas Belouin

The trusted xattrs read/write access is the perfect use case for
CAP_TRUSTED.

Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
---
 fs/ext2/xattr_trusted.c     |  2 +-
 fs/ext4/xattr_trusted.c     |  2 +-
 fs/f2fs/xattr.c             |  6 +++---
 fs/hfsplus/xattr.c          |  2 +-
 fs/jffs2/xattr_trusted.c    |  2 +-
 fs/jfs/xattr.c              |  3 ++-
 fs/ocfs2/xattr.c            |  2 +-
 fs/overlayfs/inode.c        |  3 ++-
 fs/reiserfs/xattr_trusted.c | 11 ++++++++---
 fs/squashfs/xattr.c         |  2 +-
 fs/ubifs/xattr.c            |  3 ++-
 fs/xattr.c                  |  4 ++--
 12 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/fs/ext2/xattr_trusted.c b/fs/ext2/xattr_trusted.c
index 65049b71af13..8006c24f8ee0 100644
--- a/fs/ext2/xattr_trusted.c
+++ b/fs/ext2/xattr_trusted.c
@@ -11,7 +11,7 @@
 static bool
 ext2_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/ext4/xattr_trusted.c b/fs/ext4/xattr_trusted.c
index c7765c735714..9849d1e0ebb9 100644
--- a/fs/ext4/xattr_trusted.c
+++ b/fs/ext4/xattr_trusted.c
@@ -15,7 +15,7 @@
 static bool
 ext4_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 7c65540148f8..ef572464deca 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -37,7 +37,7 @@ static int f2fs_xattr_generic_get(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -62,7 +62,7 @@ static int f2fs_xattr_generic_set(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -83,7 +83,7 @@ static bool f2fs_xattr_user_list(struct dentry *dentry)
 
 static bool f2fs_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int f2fs_xattr_advise_get(const struct xattr_handler *handler,
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index ae03a19196ef..0ec6d02ee7e9 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -606,7 +606,7 @@ static inline int can_list(const char *xattr_name)
 
 	return !strncmp(xattr_name, XATTR_TRUSTED_PREFIX,
 			XATTR_TRUSTED_PREFIX_LEN) ||
-				capable(CAP_SYS_ADMIN);
+				capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static ssize_t hfsplus_listxattr_finder_info(struct dentry *dentry,
diff --git a/fs/jffs2/xattr_trusted.c b/fs/jffs2/xattr_trusted.c
index 5d6030826c52..3c7ae98e4525 100644
--- a/fs/jffs2/xattr_trusted.c
+++ b/fs/jffs2/xattr_trusted.c
@@ -35,7 +35,7 @@ static int jffs2_trusted_setxattr(const struct xattr_handler *handler,
 
 static bool jffs2_trusted_listxattr(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 const struct xattr_handler jffs2_trusted_xattr_handler = {
diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c
index 1c46573a96ed..e4f44f5133a1 100644
--- a/fs/jfs/xattr.c
+++ b/fs/jfs/xattr.c
@@ -859,7 +859,8 @@ ssize_t __jfs_getxattr(struct inode *inode, const char *name, void *data,
 static inline int can_list(struct jfs_ea *ea)
 {
 	return (!strncmp(ea->name, XATTR_TRUSTED_PREFIX,
-			 XATTR_TRUSTED_PREFIX_LEN) || capable(CAP_SYS_ADMIN));
+			 XATTR_TRUSTED_PREFIX_LEN) ||
+		capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t jfs_listxattr(struct dentry * dentry, char *data, size_t buf_size)
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 5fdf269ba82e..2b3994d192c6 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -906,7 +906,7 @@ static int ocfs2_xattr_list_entry(struct super_block *sb,
 		break;
 
 	case OCFS2_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return 0;
 		break;
 	}
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index a619addecafc..c627003d3a74 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -264,7 +264,8 @@ static bool ovl_can_list(const char *s)
 		return true;
 
 	/* Never list trusted.overlay, list other trusted for superuser only */
-	return !ovl_is_private_xattr(s) && capable(CAP_SYS_ADMIN);
+	return !ovl_is_private_xattr(s) &&
+		(capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t ovl_listxattr(struct dentry *dentry, char *list, size_t size)
diff --git a/fs/reiserfs/xattr_trusted.c b/fs/reiserfs/xattr_trusted.c
index f15a5f9e84ce..6f3fa0db8272 100644
--- a/fs/reiserfs/xattr_trusted.c
+++ b/fs/reiserfs/xattr_trusted.c
@@ -7,11 +7,16 @@
 #include "xattr.h"
 #include <linux/uaccess.h>
 
+inline bool trusted_capable(void)
+{
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
+}
+
 static int
 trusted_get(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, void *buffer, size_t size)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_get(inode, xattr_full_name(handler, name),
@@ -23,7 +28,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, const void *buffer,
 	    size_t size, int flags)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_set(inode,
@@ -33,7 +38,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 
 static bool trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN) && !IS_PRIVATE(d_inode(dentry));
+	return trusted_capable() && !IS_PRIVATE(d_inode(dentry));
 }
 
 const struct xattr_handler reiserfs_xattr_trusted_handler = {
diff --git a/fs/squashfs/xattr.c b/fs/squashfs/xattr.c
index 1548b3784548..e0a285ab1f7e 100644
--- a/fs/squashfs/xattr.c
+++ b/fs/squashfs/xattr.c
@@ -237,7 +237,7 @@ static const struct xattr_handler squashfs_xattr_user_handler = {
  */
 static bool squashfs_trusted_xattr_handler_list(struct dentry *d)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static const struct xattr_handler squashfs_xattr_trusted_handler = {
diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
index c13eae819cbc..f3aa8be72a66 100644
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -406,7 +406,8 @@ static bool xattr_visible(const char *name)
 
 	/* Show trusted namespace only for "power" users */
 	if (strncmp(name, XATTR_TRUSTED_PREFIX,
-		    XATTR_TRUSTED_PREFIX_LEN) == 0 && !capable(CAP_SYS_ADMIN))
+		    XATTR_TRUSTED_PREFIX_LEN) == 0 &&
+	    !capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 		return false;
 
 	return true;
diff --git a/fs/xattr.c b/fs/xattr.c
index 61cd28ba25f3..d9e9a0083dbb 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -113,7 +113,7 @@ xattr_permission(struct inode *inode, const char *name, int mask)
 	 * The trusted.* namespace can only be accessed by privileged users.
 	 */
 	if (!strncmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN)) {
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return (mask & MAY_WRITE) ? -EPERM : -ENODATA;
 		return 0;
 	}
@@ -945,7 +945,7 @@ static int xattr_list_one(char **buffer, ssize_t *remaining_size,
 ssize_t simple_xattr_list(struct inode *inode, struct simple_xattrs *xattrs,
 			  char *buffer, size_t size)
 {
-	bool trusted = capable(CAP_SYS_ADMIN);
+	bool trusted = capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 	struct simple_xattr *xattr;
 	ssize_t remaining_size = size;
 	int err = 0;
-- 
2.14.2

^ permalink raw reply related	[flat|nested] 42+ messages in thread
* [RFC PATCH 2/2] fs: Grant CAP_TRUSTED rw access to trusted xattrs
  2017-10-21 13:45 ` Nicolas Belouin
                   ` (2 preceding siblings ...)
  (?)
@ 2017-10-21 13:45 ` Nicolas Belouin
  -1 siblings, 0 replies; 42+ messages in thread
From: Nicolas Belouin @ 2017-10-21 13:45 UTC (permalink / raw)
  To: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4
  Cc: Nicolas Belouin

The trusted xattrs read/write access is the perfect use case for
CAP_TRUSTED.

Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
---
 fs/ext2/xattr_trusted.c     |  2 +-
 fs/ext4/xattr_trusted.c     |  2 +-
 fs/f2fs/xattr.c             |  6 +++---
 fs/hfsplus/xattr.c          |  2 +-
 fs/jffs2/xattr_trusted.c    |  2 +-
 fs/jfs/xattr.c              |  3 ++-
 fs/ocfs2/xattr.c            |  2 +-
 fs/overlayfs/inode.c        |  3 ++-
 fs/reiserfs/xattr_trusted.c | 11 ++++++++---
 fs/squashfs/xattr.c         |  2 +-
 fs/ubifs/xattr.c            |  3 ++-
 fs/xattr.c                  |  4 ++--
 12 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/fs/ext2/xattr_trusted.c b/fs/ext2/xattr_trusted.c
index 65049b71af13..8006c24f8ee0 100644
--- a/fs/ext2/xattr_trusted.c
+++ b/fs/ext2/xattr_trusted.c
@@ -11,7 +11,7 @@
 static bool
 ext2_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/ext4/xattr_trusted.c b/fs/ext4/xattr_trusted.c
index c7765c735714..9849d1e0ebb9 100644
--- a/fs/ext4/xattr_trusted.c
+++ b/fs/ext4/xattr_trusted.c
@@ -15,7 +15,7 @@
 static bool
 ext4_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int
diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index 7c65540148f8..ef572464deca 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -37,7 +37,7 @@ static int f2fs_xattr_generic_get(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -62,7 +62,7 @@ static int f2fs_xattr_generic_set(const struct xattr_handler *handler,
 			return -EOPNOTSUPP;
 		break;
 	case F2FS_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return -EPERM;
 		break;
 	case F2FS_XATTR_INDEX_SECURITY:
@@ -83,7 +83,7 @@ static bool f2fs_xattr_user_list(struct dentry *dentry)
 
 static bool f2fs_xattr_trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static int f2fs_xattr_advise_get(const struct xattr_handler *handler,
diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c
index ae03a19196ef..0ec6d02ee7e9 100644
--- a/fs/hfsplus/xattr.c
+++ b/fs/hfsplus/xattr.c
@@ -606,7 +606,7 @@ static inline int can_list(const char *xattr_name)
 
 	return !strncmp(xattr_name, XATTR_TRUSTED_PREFIX,
 			XATTR_TRUSTED_PREFIX_LEN) ||
-				capable(CAP_SYS_ADMIN);
+				capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static ssize_t hfsplus_listxattr_finder_info(struct dentry *dentry,
diff --git a/fs/jffs2/xattr_trusted.c b/fs/jffs2/xattr_trusted.c
index 5d6030826c52..3c7ae98e4525 100644
--- a/fs/jffs2/xattr_trusted.c
+++ b/fs/jffs2/xattr_trusted.c
@@ -35,7 +35,7 @@ static int jffs2_trusted_setxattr(const struct xattr_handler *handler,
 
 static bool jffs2_trusted_listxattr(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 const struct xattr_handler jffs2_trusted_xattr_handler = {
diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c
index 1c46573a96ed..e4f44f5133a1 100644
--- a/fs/jfs/xattr.c
+++ b/fs/jfs/xattr.c
@@ -859,7 +859,8 @@ ssize_t __jfs_getxattr(struct inode *inode, const char *name, void *data,
 static inline int can_list(struct jfs_ea *ea)
 {
 	return (!strncmp(ea->name, XATTR_TRUSTED_PREFIX,
-			 XATTR_TRUSTED_PREFIX_LEN) || capable(CAP_SYS_ADMIN));
+			 XATTR_TRUSTED_PREFIX_LEN) ||
+		capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t jfs_listxattr(struct dentry * dentry, char *data, size_t buf_size)
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 5fdf269ba82e..2b3994d192c6 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -906,7 +906,7 @@ static int ocfs2_xattr_list_entry(struct super_block *sb,
 		break;
 
 	case OCFS2_XATTR_INDEX_TRUSTED:
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return 0;
 		break;
 	}
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index a619addecafc..c627003d3a74 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -264,7 +264,8 @@ static bool ovl_can_list(const char *s)
 		return true;
 
 	/* Never list trusted.overlay, list other trusted for superuser only */
-	return !ovl_is_private_xattr(s) && capable(CAP_SYS_ADMIN);
+	return !ovl_is_private_xattr(s) &&
+		(capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED));
 }
 
 ssize_t ovl_listxattr(struct dentry *dentry, char *list, size_t size)
diff --git a/fs/reiserfs/xattr_trusted.c b/fs/reiserfs/xattr_trusted.c
index f15a5f9e84ce..6f3fa0db8272 100644
--- a/fs/reiserfs/xattr_trusted.c
+++ b/fs/reiserfs/xattr_trusted.c
@@ -7,11 +7,16 @@
 #include "xattr.h"
 #include <linux/uaccess.h>
 
+inline bool trusted_capable(void)
+{
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
+}
+
 static int
 trusted_get(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, void *buffer, size_t size)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_get(inode, xattr_full_name(handler, name),
@@ -23,7 +28,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 	    struct inode *inode, const char *name, const void *buffer,
 	    size_t size, int flags)
 {
-	if (!capable(CAP_SYS_ADMIN) || IS_PRIVATE(inode))
+	if (!trusted_capable() || IS_PRIVATE(inode))
 		return -EPERM;
 
 	return reiserfs_xattr_set(inode,
@@ -33,7 +38,7 @@ trusted_set(const struct xattr_handler *handler, struct dentry *unused,
 
 static bool trusted_list(struct dentry *dentry)
 {
-	return capable(CAP_SYS_ADMIN) && !IS_PRIVATE(d_inode(dentry));
+	return trusted_capable() && !IS_PRIVATE(d_inode(dentry));
 }
 
 const struct xattr_handler reiserfs_xattr_trusted_handler = {
diff --git a/fs/squashfs/xattr.c b/fs/squashfs/xattr.c
index 1548b3784548..e0a285ab1f7e 100644
--- a/fs/squashfs/xattr.c
+++ b/fs/squashfs/xattr.c
@@ -237,7 +237,7 @@ static const struct xattr_handler squashfs_xattr_user_handler = {
  */
 static bool squashfs_trusted_xattr_handler_list(struct dentry *d)
 {
-	return capable(CAP_SYS_ADMIN);
+	return capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 }
 
 static const struct xattr_handler squashfs_xattr_trusted_handler = {
diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
index c13eae819cbc..f3aa8be72a66 100644
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -406,7 +406,8 @@ static bool xattr_visible(const char *name)
 
 	/* Show trusted namespace only for "power" users */
 	if (strncmp(name, XATTR_TRUSTED_PREFIX,
-		    XATTR_TRUSTED_PREFIX_LEN) == 0 && !capable(CAP_SYS_ADMIN))
+		    XATTR_TRUSTED_PREFIX_LEN) == 0 &&
+	    !capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 		return false;
 
 	return true;
diff --git a/fs/xattr.c b/fs/xattr.c
index 61cd28ba25f3..d9e9a0083dbb 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -113,7 +113,7 @@ xattr_permission(struct inode *inode, const char *name, int mask)
 	 * The trusted.* namespace can only be accessed by privileged users.
 	 */
 	if (!strncmp(name, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN)) {
-		if (!capable(CAP_SYS_ADMIN))
+		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_TRUSTED))
 			return (mask & MAY_WRITE) ? -EPERM : -ENODATA;
 		return 0;
 	}
@@ -945,7 +945,7 @@ static int xattr_list_one(char **buffer, ssize_t *remaining_size,
 ssize_t simple_xattr_list(struct inode *inode, struct simple_xattrs *xattrs,
 			  char *buffer, size_t size)
 {
-	bool trusted = capable(CAP_SYS_ADMIN);
+	bool trusted = capable(CAP_SYS_ADMIN) || capable(CAP_TRUSTED);
 	struct simple_xattr *xattr;
 	ssize_t remaining_size = size;
 	int err = 0;
-- 
2.14.2


^ permalink raw reply related	[flat|nested] 42+ messages in thread
* Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 13:45 ` Nicolas Belouin
  (?)
  (?)
@ 2017-10-21 16:03   ` Serge E. Hallyn
  -1 siblings, 0 replies; 42+ messages in thread
From: Serge E. Hallyn @ 2017-10-21 16:03 UTC (permalink / raw)
  To: Nicolas Belouin
  Cc: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4

Quoting Nicolas Belouin (nicolas@belouin.fr):
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

You say "for example".  Are you intending to add more uses?  If so, what
are they?  If not, how about renaming it CAP_TRUSTED_XATTR?

What all does allowing writes to trusted xattrs give you?  There are
the overlayfs whiteouts, what else?

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 16:03   ` Serge E. Hallyn
  0 siblings, 0 replies; 42+ messages in thread
From: Serge E. Hallyn @ 2017-10-21 16:03 UTC (permalink / raw)
  To: Nicolas Belouin
  Cc: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4, linux-kernel, linux-f2fs-devel, linux-fsdevel,
	linux-mtd, jfs-discussion, ocfs2-devel, linux-unionfs,
	reiserfs-devel, linux-security-module, selinux, linux-api,
	kernel-hardening

Quoting Nicolas Belouin (nicolas@belouin.fr):
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

You say "for example".  Are you intending to add more uses?  If so, what
are they?  If not, how about renaming it CAP_TRUSTED_XATTR?

What all does allowing writes to trusted xattrs give you?  There are
the overlayfs whiteouts, what else?

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 16:03   ` Serge E. Hallyn
  0 siblings, 0 replies; 42+ messages in thread
From: Serge E. Hallyn @ 2017-10-21 16:03 UTC (permalink / raw)
  To: linux-security-module

Quoting Nicolas Belouin (nicolas at belouin.fr):
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

You say "for example".  Are you intending to add more uses?  If so, what
are they?  If not, how about renaming it CAP_TRUSTED_XATTR?

What all does allowing writes to trusted xattrs give you?  There are
the overlayfs whiteouts, what else?
--
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

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [kernel-hardening] Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 16:03   ` Serge E. Hallyn
  0 siblings, 0 replies; 42+ messages in thread
From: Serge E. Hallyn @ 2017-10-21 16:03 UTC (permalink / raw)
  To: Nicolas Belouin
  Cc: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James Morris,
	linux-ext4, linux-kernel, linux-f2fs-devel, linux-fsdevel,
	linux-mtd, jfs-discussion, ocfs2-devel, linux-unionfs,
	reiserfs-devel, linux-security-module, selinux, linux-api,
	kernel-hardening

Quoting Nicolas Belouin (nicolas@belouin.fr):
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

You say "for example".  Are you intending to add more uses?  If so, what
are they?  If not, how about renaming it CAP_TRUSTED_XATTR?

What all does allowing writes to trusted xattrs give you?  There are
the overlayfs whiteouts, what else?

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 13:45 ` Nicolas Belouin
  (?)
  (?)
@ 2017-10-21 17:25   ` Casey Schaufler
  -1 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: Nicolas Belouin, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James Morris

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 17:25   ` Casey Schaufler
  0 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: Nicolas Belouin, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James Morris, linux-ext4, linux-kernel,
	linux-f2fs-devel, linux-fsdevel, linux-mtd, jfs-discussion,
	ocfs2-devel, linux-unionfs, reiserfs-devel,
	linux-security-module, selinux, linux-api, kernel-hardening

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 13:45 ` Nicolas Belouin
                   ` (13 preceding siblings ...)
  (?)
@ 2017-10-21 17:25 ` Casey Schaufler
  -1 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: Nicolas Belouin, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James Morris

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 13:45 ` Nicolas Belouin
                   ` (8 preceding siblings ...)
  (?)
@ 2017-10-21 17:25 ` Casey Schaufler
  -1 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: Nicolas Belouin, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James Morris, linux-ext4, linux-kernel,
	linux-f2fs-devel, linux-fsdevel

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 13:45 ` Nicolas Belouin
                   ` (6 preceding siblings ...)
  (?)
@ 2017-10-21 17:25 ` Casey Schaufler
  -1 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: Nicolas Belouin, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James Morris, linux-ext4, linux-kernel,
	linux-f2fs-devel, linux-fsdevel

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 13:45 ` Nicolas Belouin
                   ` (9 preceding siblings ...)
  (?)
@ 2017-10-21 17:25 ` Casey Schaufler
  -1 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: Nicolas Belouin, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James Morris, linux-ext4, linux-kernel,
	linux-f2fs-devel, linux-fsdevel

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 13:45 ` Nicolas Belouin
                   ` (10 preceding siblings ...)
  (?)
@ 2017-10-21 17:25 ` Casey Schaufler
  -1 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: Nicolas Belouin, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James Morris, linux-ext4, linux-kernel,
	linux-f2fs-devel, linux-fsdevel

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 17:25   ` Casey Schaufler
  0 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: Nicolas Belouin, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James Morris

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
       [not found] ` <20171021134558.21195-1-nicolas-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>
  2017-10-21 13:45   ` [RFC PATCH 2/2] fs: Grant CAP_TRUSTED rw access to trusted xattrs Nicolas Belouin
  2017-10-21 17:25   ` [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED Casey Schaufler
@ 2017-10-21 17:25   ` Casey Schaufler
  2 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: Nicolas Belouin, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James Morris

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 17:25   ` Casey Schaufler
  0 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: linux-security-module

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  

--
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

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
       [not found] ` <20171021134558.21195-1-nicolas-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>
  2017-10-21 13:45   ` [RFC PATCH 2/2] fs: Grant CAP_TRUSTED rw access to trusted xattrs Nicolas Belouin
@ 2017-10-21 17:25   ` Casey Schaufler
  2017-10-21 17:25   ` Casey Schaufler
  2 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: Nicolas Belouin, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James Morris, linux-ex

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 13:45 ` Nicolas Belouin
                   ` (7 preceding siblings ...)
  (?)
@ 2017-10-21 17:25 ` Casey Schaufler
  -1 siblings, 0 replies; 42+ messages in thread
From: Casey Schaufler @ 2017-10-21 17:25 UTC (permalink / raw)
  To: Nicolas Belouin, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James Morris

On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
> flag a process to be entrusted for e.g reading and writing trusted
> xattr is near zero.
> CAP_TRUSTED aims to provide userland with a way to mark a process as
> entrusted to do specific (not specially admin-centered) actions. It
> would for example allow a process to red/write the trusted xattrs.

Please explain how this is different from CAP_MAC_ADMIN in
any existing use case. If it is significantly different, how
would the two interact?

> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
> ---
>  include/uapi/linux/capability.h     | 6 +++++-
>  security/selinux/include/classmap.h | 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index ce230aa6d928..27e457b93c84 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>  
>  #define CAP_SYS_MOUNT		38
>  
> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
> +/* Allow read/write trusted xattr */
> +
> +#define CAP_TRUSTED		39
> +
> +#define CAP_LAST_CAP         CAP_TRUSTED
>  
>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index a873dce97fd5..f5dc8e109f5a 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -24,9 +24,10 @@
>  	    "audit_control", "setfcap"
>  
>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
> +		"trusted"
>  
> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
> +#if CAP_LAST_CAP > CAP_TRUSTED
>  #error New capability defined, please update COMMON_CAP2_PERMS.
>  #endif
>  


^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 17:25   ` Casey Schaufler
                     ` (5 preceding siblings ...)
  (?)
@ 2017-10-21 19:04   ` nicolas
  -1 siblings, 0 replies; 42+ messages in thread
From: nicolas @ 2017-10-21 19:04 UTC (permalink / raw)
  To: Casey Schaufler, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James.Morris

<james.l.morris@oracle.com>,linux-ext4@vger.kernel.org,linux-kernel@vger.kernel.org,linux-f2fs-devel@lists.sourceforge.net,linux-fsdevel@vger.kernel.org,linux-mtd@lists.infradead.org,jfs-discussion@lists.sourceforge.net,ocfs2-devel@oss.oracle.com,linux-unionfs@vger.kernel.org,reiserfs-devel@vger.kernel.org,linux-security-module@vger.kernel.org,selinux@tycho.nsa.gov,linux-api@vger.kernel.org,kernel-hardening@lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <E5A1BDA4-A309-4118-84D5-72780F619EBA@belouin.fr>



On October 21, 2017 7:25:21 PM GMT+02:00, Casey Schaufler <casey@schaufler-ca.com> wrote:
>On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>Please explain how this is different from CAP_MAC_ADMIN in
>any existing use case. If it is significantly different, how
>would the two interact?

>From my point of view, CAP_MAC_ADMIN allows one to read/write security xattrs, those are meant to describe security policies. As far as I know of, trusted xattrs are intended for a privileged process to read or write arbitrary data. I don't have any real world example in mind that use trusted xattrs, but I'll try to find one.

>
>> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
>> ---
>>  include/uapi/linux/capability.h     | 6 +++++-
>>  security/selinux/include/classmap.h | 5 +++--
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/uapi/linux/capability.h
>b/include/uapi/linux/capability.h
>> index ce230aa6d928..27e457b93c84 100644
>> --- a/include/uapi/linux/capability.h
>> +++ b/include/uapi/linux/capability.h
>> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>>  
>>  #define CAP_SYS_MOUNT		38
>>  
>> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
>> +/* Allow read/write trusted xattr */
>> +
>> +#define CAP_TRUSTED		39
>> +
>> +#define CAP_LAST_CAP         CAP_TRUSTED
>>  
>>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>>  
>> diff --git a/security/selinux/include/classmap.h
>b/security/selinux/include/classmap.h
>> index a873dce97fd5..f5dc8e109f5a 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -24,9 +24,10 @@
>>  	    "audit_control", "setfcap"
>>  
>>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
>> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
>> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
>> +		"trusted"
>>  
>> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
>> +#if CAP_LAST_CAP > CAP_TRUSTED
>>  #error New capability defined, please update COMMON_CAP2_PERMS.
>>  #endif
>>  

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 17:25   ` Casey Schaufler
  (?)
@ 2017-10-21 19:04     ` nicolas at belouin.fr
  -1 siblings, 0 replies; 42+ messages in thread
From: nicolas @ 2017-10-21 19:04 UTC (permalink / raw)
  To: Casey Schaufler, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James.Morris

<james.l.morris@oracle.com>,linux-ext4@vger.kernel.org,linux-kernel@vger.kernel.org,linux-f2fs-devel@lists.sourceforge.net,linux-fsdevel@vger.kernel.org,linux-mtd@lists.infradead.org,jfs-discussion@lists.sourceforge.net,ocfs2-devel@oss.oracle.com,linux-unionfs@vger.kernel.org,reiserfs-devel@vger.kernel.org,linux-security-module@vger.kernel.org,selinux@tycho.nsa.gov,linux-api@vger.kernel.org,kernel-hardening@lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <E5A1BDA4-A309-4118-84D5-72780F619EBA@belouin.fr>



On October 21, 2017 7:25:21 PM GMT+02:00, Casey Schaufler <casey@schaufler-ca.com> wrote:
>On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>Please explain how this is different from CAP_MAC_ADMIN in
>any existing use case. If it is significantly different, how
>would the two interact?

>From my point of view, CAP_MAC_ADMIN allows one to read/write security xattrs, those are meant to describe security policies. As far as I know of, trusted xattrs are intended for a privileged process to read or write arbitrary data. I don't have any real world example in mind that use trusted xattrs, but I'll try to find one.

>
>> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
>> ---
>>  include/uapi/linux/capability.h     | 6 +++++-
>>  security/selinux/include/classmap.h | 5 +++--
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/uapi/linux/capability.h
>b/include/uapi/linux/capability.h
>> index ce230aa6d928..27e457b93c84 100644
>> --- a/include/uapi/linux/capability.h
>> +++ b/include/uapi/linux/capability.h
>> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>>  
>>  #define CAP_SYS_MOUNT		38
>>  
>> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
>> +/* Allow read/write trusted xattr */
>> +
>> +#define CAP_TRUSTED		39
>> +
>> +#define CAP_LAST_CAP         CAP_TRUSTED
>>  
>>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>>  
>> diff --git a/security/selinux/include/classmap.h
>b/security/selinux/include/classmap.h
>> index a873dce97fd5..f5dc8e109f5a 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -24,9 +24,10 @@
>>  	    "audit_control", "setfcap"
>>  
>>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
>> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
>> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
>> +		"trusted"
>>  
>> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
>> +#if CAP_LAST_CAP > CAP_TRUSTED
>>  #error New capability defined, please update COMMON_CAP2_PERMS.
>>  #endif
>>  

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 17:25   ` Casey Schaufler
                     ` (3 preceding siblings ...)
  (?)
@ 2017-10-21 19:04   ` nicolas
  -1 siblings, 0 replies; 42+ messages in thread
From: nicolas @ 2017-10-21 19:04 UTC (permalink / raw)
  To: Casey Schaufler, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James.Morris

<james.l.morris@oracle.com>,linux-ext4@vger.kernel.org,linux-kernel@vger.kernel.org,linux-f2fs-devel@lists.sourceforge.net,linux-fsdevel@vger.kernel.org,linux-mtd@lists.infradead.org,jfs-discussion@lists.sourceforge.net,ocfs2-devel@oss.oracle.com,linux-unionfs@vger.kernel.org,reiserfs-devel@vger.kernel.org,linux-security-module@vger.kernel.org,selinux@tycho.nsa.gov,linux-api@vger.kernel.org,kernel-hardening@lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <E5A1BDA4-A309-4118-84D5-72780F619EBA@belouin.fr>



On October 21, 2017 7:25:21 PM GMT+02:00, Casey Schaufler <casey@schaufler-ca.com> wrote:
>On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>Please explain how this is different from CAP_MAC_ADMIN in
>any existing use case. If it is significantly different, how
>would the two interact?

>From my point of view, CAP_MAC_ADMIN allows one to read/write security xattrs, those are meant to describe security policies. As far as I know of, trusted xattrs are intended for a privileged process to read or write arbitrary data. I don't have any real world example in mind that use trusted xattrs, but I'll try to find one.

>
>> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
>> ---
>>  include/uapi/linux/capability.h     | 6 +++++-
>>  security/selinux/include/classmap.h | 5 +++--
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/uapi/linux/capability.h
>b/include/uapi/linux/capability.h
>> index ce230aa6d928..27e457b93c84 100644
>> --- a/include/uapi/linux/capability.h
>> +++ b/include/uapi/linux/capability.h
>> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>>  
>>  #define CAP_SYS_MOUNT		38
>>  
>> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
>> +/* Allow read/write trusted xattr */
>> +
>> +#define CAP_TRUSTED		39
>> +
>> +#define CAP_LAST_CAP         CAP_TRUSTED
>>  
>>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>>  
>> diff --git a/security/selinux/include/classmap.h
>b/security/selinux/include/classmap.h
>> index a873dce97fd5..f5dc8e109f5a 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -24,9 +24,10 @@
>>  	    "audit_control", "setfcap"
>>  
>>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
>> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
>> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
>> +		"trusted"
>>  
>> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
>> +#if CAP_LAST_CAP > CAP_TRUSTED
>>  #error New capability defined, please update COMMON_CAP2_PERMS.
>>  #endif
>>  

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 17:25   ` Casey Schaufler
                     ` (7 preceding siblings ...)
  (?)
@ 2017-10-21 19:04   ` nicolas
  -1 siblings, 0 replies; 42+ messages in thread
From: nicolas @ 2017-10-21 19:04 UTC (permalink / raw)
  To: Casey Schaufler, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James.Morris

<james.l.morris@oracle.com>,linux-ext4@vger.kernel.org,linux-kernel@vger.kernel.org,linux-f2fs-devel@lists.sourceforge.net,linux-fsdevel@vger.kernel.org,linux-mtd@lists.infradead.org,jfs-discussion@lists.sourceforge.net,ocfs2-devel@oss.oracle.com,linux-unionfs@vger.kernel.org,reiserfs-devel@vger.kernel.org,linux-security-module@vger.kernel.org,selinux@tycho.nsa.gov,linux-api@vger.kernel.org,kernel-hardening@lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <E5A1BDA4-A309-4118-84D5-72780F619EBA@belouin.fr>



On October 21, 2017 7:25:21 PM GMT+02:00, Casey Schaufler <casey@schaufler-ca.com> wrote:
>On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>Please explain how this is different from CAP_MAC_ADMIN in
>any existing use case. If it is significantly different, how
>would the two interact?

>From my point of view, CAP_MAC_ADMIN allows one to read/write security xattrs, those are meant to describe security policies. As far as I know of, trusted xattrs are intended for a privileged process to read or write arbitrary data. I don't have any real world example in mind that use trusted xattrs, but I'll try to find one.

>
>> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
>> ---
>>  include/uapi/linux/capability.h     | 6 +++++-
>>  security/selinux/include/classmap.h | 5 +++--
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/uapi/linux/capability.h
>b/include/uapi/linux/capability.h
>> index ce230aa6d928..27e457b93c84 100644
>> --- a/include/uapi/linux/capability.h
>> +++ b/include/uapi/linux/capability.h
>> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>>  
>>  #define CAP_SYS_MOUNT		38
>>  
>> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
>> +/* Allow read/write trusted xattr */
>> +
>> +#define CAP_TRUSTED		39
>> +
>> +#define CAP_LAST_CAP         CAP_TRUSTED
>>  
>>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>>  
>> diff --git a/security/selinux/include/classmap.h
>b/security/selinux/include/classmap.h
>> index a873dce97fd5..f5dc8e109f5a 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -24,9 +24,10 @@
>>  	    "audit_control", "setfcap"
>>  
>>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
>> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
>> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
>> +		"trusted"
>>  
>> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
>> +#if CAP_LAST_CAP > CAP_TRUSTED
>>  #error New capability defined, please update COMMON_CAP2_PERMS.
>>  #endif
>>  

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
       [not found]   ` <d3e1c911-138d-082a-b941-651217d0faf8-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
@ 2017-10-21 19:04     ` nicolas-6zwZCx3K5ONGWvitb5QawA
  0 siblings, 0 replies; 42+ messages in thread
From: nicolas-6zwZCx3K5ONGWvitb5QawA @ 2017-10-21 19:04 UTC (permalink / raw)
  To: Casey Schaufler, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James.Morris-g+Cd2gT1u6QP3drIcvDWNA

<james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,ocfs2-devel-N0ozoZBvEnrZJqsBc5GL+g@public.gmane.org,linux-unionfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,reiserfs-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org,linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org
From: Nicolas Belouin <nicolas-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>
Message-ID: <E5A1BDA4-A309-4118-84D5-72780F619EBA-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>



On October 21, 2017 7:25:21 PM GMT+02:00, Casey Schaufler <casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org> wrote:
>On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>Please explain how this is different from CAP_MAC_ADMIN in
>any existing use case. If it is significantly different, how
>would the two interact?

>From my point of view, CAP_MAC_ADMIN allows one to read/write security xattrs, those are meant to describe security policies. As far as I know of, trusted xattrs are intended for a privileged process to read or write arbitrary data. I don't have any real world example in mind that use trusted xattrs, but I'll try to find one.

>
>> Signed-off-by: Nicolas Belouin <nicolas-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>
>> ---
>>  include/uapi/linux/capability.h     | 6 +++++-
>>  security/selinux/include/classmap.h | 5 +++--
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/uapi/linux/capability.h
>b/include/uapi/linux/capability.h
>> index ce230aa6d928..27e457b93c84 100644
>> --- a/include/uapi/linux/capability.h
>> +++ b/include/uapi/linux/capability.h
>> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>>  
>>  #define CAP_SYS_MOUNT		38
>>  
>> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
>> +/* Allow read/write trusted xattr */
>> +
>> +#define CAP_TRUSTED		39
>> +
>> +#define CAP_LAST_CAP         CAP_TRUSTED
>>  
>>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>>  
>> diff --git a/security/selinux/include/classmap.h
>b/security/selinux/include/classmap.h
>> index a873dce97fd5..f5dc8e109f5a 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -24,9 +24,10 @@
>>  	    "audit_control", "setfcap"
>>  
>>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
>> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
>> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
>> +		"trusted"
>>  
>> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
>> +#if CAP_LAST_CAP > CAP_TRUSTED
>>  #error New capability defined, please update COMMON_CAP2_PERMS.
>>  #endif
>>  

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 19:04     ` nicolas at belouin.fr
  0 siblings, 0 replies; 42+ messages in thread
From: nicolas at belouin.fr @ 2017-10-21 19:04 UTC (permalink / raw)
  To: linux-security-module

<james.l.morris@oracle.com>,linux-ext4 at vger.kernel.org,linux-kernel at vger.kernel.org,linux-f2fs-devel at lists.sourceforge.net,linux-fsdevel at vger.kernel.org,linux-mtd at lists.infradead.org,jfs-discussion at lists.sourceforge.net,ocfs2-devel at oss.oracle.com,linux-unionfs at vger.kernel.org,reiserfs-devel at vger.kernel.org,linux-security-module at vger.kernel.org,selinux at tycho.nsa.gov,linux-api at vger.kernel.org,kernel-hardening at lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <E5A1BDA4-A309-4118-84D5-72780F619EBA@belouin.fr>



On October 21, 2017 7:25:21 PM GMT+02:00, Casey Schaufler <casey@schaufler-ca.com> wrote:
>On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>Please explain how this is different from CAP_MAC_ADMIN in
>any existing use case. If it is significantly different, how
>would the two interact?

>From my point of view, CAP_MAC_ADMIN allows one to read/write security xattrs, those are meant to describe security policies. As far as I know of, trusted xattrs are intended for a privileged process to read or write arbitrary data. I don't have any real world example in mind that use trusted xattrs, but I'll try to find one.

>
>> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
>> ---
>>  include/uapi/linux/capability.h     | 6 +++++-
>>  security/selinux/include/classmap.h | 5 +++--
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/uapi/linux/capability.h
>b/include/uapi/linux/capability.h
>> index ce230aa6d928..27e457b93c84 100644
>> --- a/include/uapi/linux/capability.h
>> +++ b/include/uapi/linux/capability.h
>> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>>  
>>  #define CAP_SYS_MOUNT		38
>>  
>> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
>> +/* Allow read/write trusted xattr */
>> +
>> +#define CAP_TRUSTED		39
>> +
>> +#define CAP_LAST_CAP         CAP_TRUSTED
>>  
>>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>>  
>> diff --git a/security/selinux/include/classmap.h
>b/security/selinux/include/classmap.h
>> index a873dce97fd5..f5dc8e109f5a 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -24,9 +24,10 @@
>>  	    "audit_control", "setfcap"
>>  
>>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
>> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
>> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
>> +		"trusted"
>>  
>> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
>> +#if CAP_LAST_CAP > CAP_TRUSTED
>>  #error New capability defined, please update COMMON_CAP2_PERMS.
>>  #endif
>>  

Nicolas
--
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

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 19:04     ` nicolas at belouin.fr
  0 siblings, 0 replies; 42+ messages in thread
From: nicolas @ 2017-10-21 19:04 UTC (permalink / raw)
  To: Casey Schaufler, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James.Morris

<james.l.morris@oracle.com>,linux-ext4@vger.kernel.org,linux-kernel@vger.kernel.org,linux-f2fs-devel@lists.sourceforge.net,linux-fsdevel@vger.kernel.org,linux-mtd@lists.infradead.org,jfs-discussion@lists.sourceforge.net,ocfs2-devel@oss.oracle.com,linux-unionfs@vger.kernel.org,reiserfs-devel@vger.kernel.org,linux-security-module@vger.kernel.org,selinux@tycho.nsa.gov,linux-api@vger.kernel.org,kernel-hardening@lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <E5A1BDA4-A309-4118-84D5-72780F619EBA@belouin.fr>



On October 21, 2017 7:25:21 PM GMT+02:00, Casey Schaufler <casey@schaufler-ca.com> wrote:
>On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>Please explain how this is different from CAP_MAC_ADMIN in
>any existing use case. If it is significantly different, how
>would the two interact?

From my point of view, CAP_MAC_ADMIN allows one to read/write security xattrs, those are meant to describe security policies. As far as I know of, trusted xattrs are intended for a privileged process to read or write arbitrary data. I don't have any real world example in mind that use trusted xattrs, but I'll try to find one.

>
>> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
>> ---
>>  include/uapi/linux/capability.h     | 6 +++++-
>>  security/selinux/include/classmap.h | 5 +++--
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/uapi/linux/capability.h
>b/include/uapi/linux/capability.h
>> index ce230aa6d928..27e457b93c84 100644
>> --- a/include/uapi/linux/capability.h
>> +++ b/include/uapi/linux/capability.h
>> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>>  
>>  #define CAP_SYS_MOUNT		38
>>  
>> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
>> +/* Allow read/write trusted xattr */
>> +
>> +#define CAP_TRUSTED		39
>> +
>> +#define CAP_LAST_CAP         CAP_TRUSTED
>>  
>>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>>  
>> diff --git a/security/selinux/include/classmap.h
>b/security/selinux/include/classmap.h
>> index a873dce97fd5..f5dc8e109f5a 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -24,9 +24,10 @@
>>  	    "audit_control", "setfcap"
>>  
>>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
>> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
>> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
>> +		"trusted"
>>  
>> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
>> +#if CAP_LAST_CAP > CAP_TRUSTED
>>  #error New capability defined, please update COMMON_CAP2_PERMS.
>>  #endif
>>  

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 17:25   ` Casey Schaufler
                     ` (6 preceding siblings ...)
  (?)
@ 2017-10-21 19:04   ` nicolas
  -1 siblings, 0 replies; 42+ messages in thread
From: nicolas @ 2017-10-21 19:04 UTC (permalink / raw)
  To: Casey Schaufler, Jan Kara, Theodore Ts'o, Andreas Dilger,
	Jaegeuk Kim, Chao Yu, David Woodhouse, Dave Kleikamp,
	Mark Fasheh, Joel Becker, Miklos Szeredi, Phillip Lougher,
	Richard Weinberger, Artem Bityutskiy, Adrian Hunter,
	Alexander Viro, Serge Hallyn, Paul Moore, Stephen Smalley,
	Eric Paris, James.Morris

<james.l.morris@oracle.com>,linux-ext4@vger.kernel.org,linux-kernel@vger.kernel.org,linux-f2fs-devel@lists.sourceforge.net,linux-fsdevel@vger.kernel.org,linux-mtd@lists.infradead.org,jfs-discussion@lists.sourceforge.net,ocfs2-devel@oss.oracle.com,linux-unionfs@vger.kernel.org,reiserfs-devel@vger.kernel.org,linux-security-module@vger.kernel.org,selinux@tycho.nsa.gov,linux-api@vger.kernel.org,kernel-hardening@lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <E5A1BDA4-A309-4118-84D5-72780F619EBA@belouin.fr>



On October 21, 2017 7:25:21 PM GMT+02:00, Casey Schaufler <casey@schaufler-ca.com> wrote:
>On 10/21/2017 6:45 AM, Nicolas Belouin wrote:
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>Please explain how this is different from CAP_MAC_ADMIN in
>any existing use case. If it is significantly different, how
>would the two interact?

From my point of view, CAP_MAC_ADMIN allows one to read/write security xattrs, those are meant to describe security policies. As far as I know of, trusted xattrs are intended for a privileged process to read or write arbitrary data. I don't have any real world example in mind that use trusted xattrs, but I'll try to find one.

>
>> Signed-off-by: Nicolas Belouin <nicolas@belouin.fr>
>> ---
>>  include/uapi/linux/capability.h     | 6 +++++-
>>  security/selinux/include/classmap.h | 5 +++--
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/uapi/linux/capability.h
>b/include/uapi/linux/capability.h
>> index ce230aa6d928..27e457b93c84 100644
>> --- a/include/uapi/linux/capability.h
>> +++ b/include/uapi/linux/capability.h
>> @@ -369,7 +369,11 @@ struct vfs_ns_cap_data {
>>  
>>  #define CAP_SYS_MOUNT		38
>>  
>> -#define CAP_LAST_CAP         CAP_SYS_MOUNT
>> +/* Allow read/write trusted xattr */
>> +
>> +#define CAP_TRUSTED		39
>> +
>> +#define CAP_LAST_CAP         CAP_TRUSTED
>>  
>>  #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
>>  
>> diff --git a/security/selinux/include/classmap.h
>b/security/selinux/include/classmap.h
>> index a873dce97fd5..f5dc8e109f5a 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -24,9 +24,10 @@
>>  	    "audit_control", "setfcap"
>>  
>>  #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
>> -		"wake_alarm", "block_suspend", "audit_read", "sys_mount"
>> +		"wake_alarm", "block_suspend", "audit_read", "sys_mount", \
>> +		"trusted"
>>  
>> -#if CAP_LAST_CAP > CAP_SYS_MOUNT
>> +#if CAP_LAST_CAP > CAP_TRUSTED
>>  #error New capability defined, please update COMMON_CAP2_PERMS.
>>  #endif
>>  

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 16:03   ` Serge E. Hallyn
                     ` (4 preceding siblings ...)
  (?)
@ 2017-10-21 19:09   ` nicolas
  -1 siblings, 0 replies; 42+ messages in thread
From: nicolas @ 2017-10-21 19:09 UTC (permalink / raw)
  Cc: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James.Morris

<james.l.morris@oracle.com>,linux-ext4@vger.kernel.org,linux-kernel@vger.kernel.org,linux-f2fs-devel@lists.sourceforge.net,linux-fsdevel@vger.kernel.org,linux-mtd@lists.infradead.org,jfs-discussion@lists.sourceforge.net,ocfs2-devel@oss.oracle.com,linux-unionfs@vger.kernel.org,reiserfs-devel@vger.kernel.org,linux-security-module@vger.kernel.org,selinux@tycho.nsa.gov,linux-api@vger.kernel.org,kernel-hardening@lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <99179B10-4EAE-4FAB-9D14-B885156261B3@belouin.fr>



On October 21, 2017 6:03:02 PM GMT+02:00, "Serge E. Hallyn" <serge@hallyn.com> wrote:
>Quoting Nicolas Belouin (nicolas@belouin.fr):
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>You say "for example".  Are you intending to add more uses?  If so,
>what
>are they?  If not, how about renaming it CAP_TRUSTED_XATTR?
>

I don't see any other use for now, but I don't want it to be too narrow and non usable in a similar context in the future. So I believe the underlying purpose of marking a process as "trusted" (even if for now it only means rw permission on trusted xattr) is more meaningful.

>What all does allowing writes to trusted xattrs give you?  There are
>the overlayfs whiteouts, what else?

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 16:03   ` Serge E. Hallyn
@ 2017-10-21 19:09     ` nicolas at belouin.fr
  -1 siblings, 0 replies; 42+ messages in thread
From: nicolas @ 2017-10-21 19:09 UTC (permalink / raw)
  To: Serge E. Hallyn
  Cc: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James.Morris

<james.l.morris@oracle.com>,linux-ext4@vger.kernel.org,linux-kernel@vger.kernel.org,linux-f2fs-devel@lists.sourceforge.net,linux-fsdevel@vger.kernel.org,linux-mtd@lists.infradead.org,jfs-discussion@lists.sourceforge.net,ocfs2-devel@oss.oracle.com,linux-unionfs@vger.kernel.org,reiserfs-devel@vger.kernel.org,linux-security-module@vger.kernel.org,selinux@tycho.nsa.gov,linux-api@vger.kernel.org,kernel-hardening@lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <99179B10-4EAE-4FAB-9D14-B885156261B3@belouin.fr>



On October 21, 2017 6:03:02 PM GMT+02:00, "Serge E. Hallyn" <serge@hallyn.com> wrote:
>Quoting Nicolas Belouin (nicolas@belouin.fr):
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>You say "for example".  Are you intending to add more uses?  If so,
>what
>are they?  If not, how about renaming it CAP_TRUSTED_XATTR?
>

I don't see any other use for now, but I don't want it to be too narrow and non usable in a similar context in the future. So I believe the underlying purpose of marking a process as "trusted" (even if for now it only means rw permission on trusted xattr) is more meaningful.

>What all does allowing writes to trusted xattrs give you?  There are
>the overlayfs whiteouts, what else?

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 16:03   ` Serge E. Hallyn
                     ` (7 preceding siblings ...)
  (?)
@ 2017-10-21 19:09   ` nicolas
  -1 siblings, 0 replies; 42+ messages in thread
From: nicolas @ 2017-10-21 19:09 UTC (permalink / raw)
  To: Serge E. Hallyn
  Cc: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James.Morris

<james.l.morris@oracle.com>,linux-ext4@vger.kernel.org,linux-kernel@vger.kernel.org,linux-f2fs-devel@lists.sourceforge.net,linux-fsdevel@vger.kernel.org,linux-mtd@lists.infradead.org,jfs-discussion@lists.sourceforge.net,ocfs2-devel@oss.oracle.com,linux-unionfs@vger.kernel.org,reiserfs-devel@vger.kernel.org,linux-security-module@vger.kernel.org,selinux@tycho.nsa.gov,linux-api@vger.kernel.org,kernel-hardening@lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <99179B10-4EAE-4FAB-9D14-B885156261B3@belouin.fr>



On October 21, 2017 6:03:02 PM GMT+02:00, "Serge E. Hallyn" <serge@hallyn.com> wrote:
>Quoting Nicolas Belouin (nicolas@belouin.fr):
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>You say "for example".  Are you intending to add more uses?  If so,
>what
>are they?  If not, how about renaming it CAP_TRUSTED_XATTR?
>

I don't see any other use for now, but I don't want it to be too narrow and non usable in a similar context in the future. So I believe the underlying purpose of marking a process as "trusted" (even if for now it only means rw permission on trusted xattr) is more meaningful.

>What all does allowing writes to trusted xattrs give you?  There are
>the overlayfs whiteouts, what else?

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 16:03   ` Serge E. Hallyn
                     ` (3 preceding siblings ...)
  (?)
@ 2017-10-21 19:09   ` nicolas
  -1 siblings, 0 replies; 42+ messages in thread
From: nicolas @ 2017-10-21 19:09 UTC (permalink / raw)
  To: Serge E. Hallyn
  Cc: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James.Morris

<james.l.morris@oracle.com>,linux-ext4@vger.kernel.org,linux-kernel@vger.kernel.org,linux-f2fs-devel@lists.sourceforge.net,linux-fsdevel@vger.kernel.org,linux-mtd@lists.infradead.org,jfs-discussion@lists.sourceforge.net,ocfs2-devel@oss.oracle.com,linux-unionfs@vger.kernel.org,reiserfs-devel@vger.kernel.org,linux-security-module@vger.kernel.org,selinux@tycho.nsa.gov,linux-api@vger.kernel.org,kernel-hardening@lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <99179B10-4EAE-4FAB-9D14-B885156261B3@belouin.fr>



On October 21, 2017 6:03:02 PM GMT+02:00, "Serge E. Hallyn" <serge@hallyn.com> wrote:
>Quoting Nicolas Belouin (nicolas@belouin.fr):
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>You say "for example".  Are you intending to add more uses?  If so,
>what
>are they?  If not, how about renaming it CAP_TRUSTED_XATTR?
>

I don't see any other use for now, but I don't want it to be too narrow and non usable in a similar context in the future. So I believe the underlying purpose of marking a process as "trusted" (even if for now it only means rw permission on trusted xattr) is more meaningful.

>What all does allowing writes to trusted xattrs give you?  There are
>the overlayfs whiteouts, what else?

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
       [not found]   ` <20171021160302.GA2842-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
@ 2017-10-21 19:09     ` nicolas-6zwZCx3K5ONGWvitb5QawA
  0 siblings, 0 replies; 42+ messages in thread
From: nicolas-6zwZCx3K5ONGWvitb5QawA @ 2017-10-21 19:09 UTC (permalink / raw)
  Cc: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris,
	James.Morris-YwJKx0arFUy+Po31K3cvAx+/fu+cuQ+V

<james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,ocfs2-devel-N0ozoZBvEnrZJqsBc5GL+g@public.gmane.org,linux-unionfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,reiserfs-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org,linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org
From: Nicolas Belouin <nicolas-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>
Message-ID: <99179B10-4EAE-4FAB-9D14-B885156261B3-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>



On October 21, 2017 6:03:02 PM GMT+02:00, "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
>Quoting Nicolas Belouin (nicolas-6zwZCx3K5ONGWvitb5QawA@public.gmane.org):
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>You say "for example".  Are you intending to add more uses?  If so,
>what
>are they?  If not, how about renaming it CAP_TRUSTED_XATTR?
>

I don't see any other use for now, but I don't want it to be too narrow and non usable in a similar context in the future. So I believe the underlying purpose of marking a process as "trusted" (even if for now it only means rw permission on trusted xattr) is more meaningful.

>What all does allowing writes to trusted xattrs give you?  There are
>the overlayfs whiteouts, what else?

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
@ 2017-10-21 19:09     ` nicolas at belouin.fr
  0 siblings, 0 replies; 42+ messages in thread
From: nicolas at belouin.fr @ 2017-10-21 19:09 UTC (permalink / raw)
  To: linux-security-module

<james.l.morris@oracle.com>,linux-ext4 at vger.kernel.org,linux-kernel at vger.kernel.org,linux-f2fs-devel at lists.sourceforge.net,linux-fsdevel at vger.kernel.org,linux-mtd at lists.infradead.org,jfs-discussion at lists.sourceforge.net,ocfs2-devel at oss.oracle.com,linux-unionfs at vger.kernel.org,reiserfs-devel at vger.kernel.org,linux-security-module at vger.kernel.org,selinux at tycho.nsa.gov,linux-api at vger.kernel.org,kernel-hardening at lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <99179B10-4EAE-4FAB-9D14-B885156261B3@belouin.fr>



On October 21, 2017 6:03:02 PM GMT+02:00, "Serge E. Hallyn" <serge@hallyn.com> wrote:
>Quoting Nicolas Belouin (nicolas at belouin.fr):
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>You say "for example".  Are you intending to add more uses?  If so,
>what
>are they?  If not, how about renaming it CAP_TRUSTED_XATTR?
>

I don't see any other use for now, but I don't want it to be too narrow and non usable in a similar context in the future. So I believe the underlying purpose of marking a process as "trusted" (even if for now it only means rw permission on trusted xattr) is more meaningful.

>What all does allowing writes to trusted xattrs give you?  There are
>the overlayfs whiteouts, what else?

Nicolas
--
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

^ permalink raw reply	[flat|nested] 42+ messages in thread
* Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED
  2017-10-21 16:03   ` Serge E. Hallyn
                     ` (5 preceding siblings ...)
  (?)
@ 2017-10-21 19:09   ` nicolas
  -1 siblings, 0 replies; 42+ messages in thread
From: nicolas @ 2017-10-21 19:09 UTC (permalink / raw)
  To: Serge E. Hallyn
  Cc: Jan Kara, Theodore Ts'o, Andreas Dilger, Jaegeuk Kim,
	Chao Yu, David Woodhouse, Dave Kleikamp, Mark Fasheh,
	Joel Becker, Miklos Szeredi, Phillip Lougher, Richard Weinberger,
	Artem Bityutskiy, Adrian Hunter, Alexander Viro, Serge Hallyn,
	Paul Moore, Stephen Smalley, Eric Paris, James.Morris

<james.l.morris@oracle.com>,linux-ext4@vger.kernel.org,linux-kernel@vger.kernel.org,linux-f2fs-devel@lists.sourceforge.net,linux-fsdevel@vger.kernel.org,linux-mtd@lists.infradead.org,jfs-discussion@lists.sourceforge.net,ocfs2-devel@oss.oracle.com,linux-unionfs@vger.kernel.org,reiserfs-devel@vger.kernel.org,linux-security-module@vger.kernel.org,selinux@tycho.nsa.gov,linux-api@vger.kernel.org,kernel-hardening@lists.openwall.com
From: Nicolas Belouin <nicolas@belouin.fr>
Message-ID: <99179B10-4EAE-4FAB-9D14-B885156261B3@belouin.fr>



On October 21, 2017 6:03:02 PM GMT+02:00, "Serge E. Hallyn" <serge@hallyn.com> wrote:
>Quoting Nicolas Belouin (nicolas@belouin.fr):
>> with CAP_SYS_ADMIN being bloated, the usefulness of using it to
>> flag a process to be entrusted for e.g reading and writing trusted
>> xattr is near zero.
>> CAP_TRUSTED aims to provide userland with a way to mark a process as
>> entrusted to do specific (not specially admin-centered) actions. It
>> would for example allow a process to red/write the trusted xattrs.
>
>You say "for example".  Are you intending to add more uses?  If so,
>what
>are they?  If not, how about renaming it CAP_TRUSTED_XATTR?
>

I don't see any other use for now, but I don't want it to be too narrow and non usable in a similar context in the future. So I believe the underlying purpose of marking a process as "trusted" (even if for now it only means rw permission on trusted xattr) is more meaningful.

>What all does allowing writes to trusted xattrs give you?  There are
>the overlayfs whiteouts, what else?

Nicolas

^ permalink raw reply	[flat|nested] 42+ messages in thread
end of thread, other threads:[~2017-10-21 19:12 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-21 13:45 [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED Nicolas Belouin
2017-10-21 13:45 ` [kernel-hardening] " Nicolas Belouin
2017-10-21 13:45 ` Nicolas Belouin
2017-10-21 13:45 ` Nicolas Belouin
2017-10-21 13:45 ` [RFC PATCH 2/2] fs: Grant CAP_TRUSTED rw access to trusted xattrs Nicolas Belouin
2017-10-21 13:45 ` Nicolas Belouin
2017-10-21 13:45   ` [kernel-hardening] " Nicolas Belouin
2017-10-21 13:45   ` Nicolas Belouin
2017-10-21 13:45   ` Nicolas Belouin
2017-10-21 13:45 ` Nicolas Belouin
2017-10-21 16:03 ` [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED Serge E. Hallyn
2017-10-21 16:03   ` [kernel-hardening] " Serge E. Hallyn
2017-10-21 16:03   ` Serge E. Hallyn
2017-10-21 16:03   ` Serge E. Hallyn
2017-10-21 19:09   ` nicolas
2017-10-21 19:09     ` nicolas at belouin.fr
2017-10-21 19:09   ` nicolas
2017-10-21 19:09   ` nicolas
2017-10-21 19:09   ` nicolas
     [not found]   ` <20171021160302.GA2842-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-10-21 19:09     ` nicolas-6zwZCx3K5ONGWvitb5QawA
2017-10-21 19:09   ` nicolas
2017-10-21 17:25 ` [kernel-hardening] " Casey Schaufler
2017-10-21 17:25 ` Casey Schaufler
2017-10-21 17:25 ` Casey Schaufler
2017-10-21 17:25 ` [kernel-hardening] " Casey Schaufler
2017-10-21 17:25 ` Casey Schaufler
     [not found] ` <20171021134558.21195-1-nicolas-6zwZCx3K5ONGWvitb5QawA@public.gmane.org>
2017-10-21 13:45   ` [RFC PATCH 2/2] fs: Grant CAP_TRUSTED rw access to trusted xattrs Nicolas Belouin
2017-10-21 17:25   ` [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED Casey Schaufler
2017-10-21 17:25   ` Casey Schaufler
2017-10-21 17:25 ` Casey Schaufler
2017-10-21 17:25   ` Casey Schaufler
2017-10-21 17:25   ` Casey Schaufler
2017-10-21 17:25   ` Casey Schaufler
     [not found]   ` <d3e1c911-138d-082a-b941-651217d0faf8-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-10-21 19:04     ` nicolas-6zwZCx3K5ONGWvitb5QawA
2017-10-21 19:04   ` nicolas
2017-10-21 19:04   ` nicolas
2017-10-21 19:04     ` nicolas
2017-10-21 19:04     ` nicolas at belouin.fr
2017-10-21 19:04   ` nicolas
2017-10-21 19:04   ` nicolas
2017-10-21 19:04   ` nicolas
2017-10-21 17:25 ` Casey Schaufler

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.