From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Schaufler Subject: Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED Date: Sat, 21 Oct 2017 10:25:21 -0700 Message-ID: References: <20171021134558.21195-1-nicolas@belouin.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from sonic305-27.consmr.mail.ne1.yahoo.com ([66.163.185.153]:46671 "EHLO sonic305-27.consmr.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932164AbdJURZ1 (ORCPT ); Sat, 21 Oct 2017 13:25:27 -0400 In-Reply-To: <20171021134558.21195-1-nicolas@belouin.fr> Content-Language: en-US Sender: linux-unionfs-owner@vger.kernel.org List-Id: linux-unionfs@vger.kernel.org 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 > --- > 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932229AbdJURZc (ORCPT ); Sat, 21 Oct 2017 13:25:32 -0400 Received: from sonic315-26.consmr.mail.ne1.yahoo.com ([66.163.190.152]:35166 "EHLO sonic315-26.consmr.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932174AbdJURZ2 (ORCPT ); Sat, 21 Oct 2017 13:25:28 -0400 X-YMail-OSG: G7EnvrYVM1lrI57chvsNu7tTygmMBUbdLgdeAyDpOS3eA17b4iNCn.qNyP_7frx hGULCCTF_0jRGkL9ni8wFPVII0TA_veSUWK3ngnJSQUgPy5ihCTiedtDpGvgc7WKcW_U4yEnUzQE 3bp9LEkyiqjdquQH_ZWFfj4x.q0QVqDvlATVuDHz3dTCDkzVOTnLPm0FWZlPIeFEw6XE5qN5ecro u0Qsl0gbmZ9Bo2QXJUSmvyeN90X9WRx6WtHgEgaXfu4ddLXeRnr21t4LWUa_LiXxgo1Hlo9_fSnQ PQUqv.JikdxgrPV5V.FYKQ9hdHVc9tFRrH0vOSMGVO9dU8d4P0aIRixQquLz6FuhANkJEni4fdTK nj5ZPDTQdyoK6tLcEjam.sFpGQm3BDWFhNd.s.RGv5lFFj6MhqFM.cncoQtPd26gzn2q2xEb.2io zAJhXR8.mAqmqib_ybFnk33vh6Ze3N3E8q2fxEFyX5VVjERcoytrN1jXILzu09AYcb0GY9Kw- X-Yahoo-Newman-Id: 270390.83541.bm@smtp113.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: G7EnvrYVM1lrI57chvsNu7tTygmMBUbdLgdeAyDpOS3eA17 b4iNCn.qNyP_7frxhGULCCTF_0jRGkL9ni8wFPVII0TA_veSUWK3ngnJSQUg Py5ihCTiedtDpGvgc7WKcW_U4yEnUzQE3bp9LEkyiqjdquQH_ZWFfj4x.q0Q VqDvlATVuDHz3dTCDkzVOTnLPm0FWZlPIeFEw6XE5qN5ecrou0Qsl0gbmZ9B o2QXJUSmvyeN90X9WRx6WtHgEgaXfu4ddLXeRnr21t4LWUa_LiXxgo1Hlo9_ fSnQPQUqv.JikdxgrPV5V.FYKQ9hdHVc9tFRrH0vOSMGVO9dU8d4P0aIRixQ quLz6FuhANkJEni4fdTKnj5ZPDTQdyoK6tLcEjam.sFpGQm3BDWFhNd.s.RG v5lFFj6MhqFM.cncoQtPd26gzn2q2xEb.2iozAJhXR8.mAqmqib_ybFnk33v h6Ze3N3E8q2fxEFyX5VVjERcoytrN1jXILzu09AYcb0GY9Kw- X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED 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@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 References: <20171021134558.21195-1-nicolas@belouin.fr> From: Casey Schaufler Message-ID: Date: Sat, 21 Oct 2017 10:25:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171021134558.21195-1-nicolas@belouin.fr> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Schaufler Subject: Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED Date: Sat, 21 Oct 2017 10:25:21 -0700 Message-ID: References: <20171021134558.21195-1-nicolas@belouin.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 In-Reply-To: <20171021134558.21195-1-nicolas@belouin.fr> Content-Language: en-US Sender: linux-unionfs-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org 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 > --- > 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: casey@schaufler-ca.com (Casey Schaufler) Date: Sat, 21 Oct 2017 10:25:21 -0700 Subject: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED In-Reply-To: <20171021134558.21195-1-nicolas@belouin.fr> References: <20171021134558.21195-1-nicolas@belouin.fr> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org 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 > --- > 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