Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED

[nicolas]

,linux-e...@vger.kernel.org,linux-ker...@vger.kernel.org,linux-f2fs-de...@lists.sourceforge.net,linux-fsde...@vger.kernel.org,linux-...@lists.infradead.org,jfs-discuss...@lists.sourceforge.net,ocfs2-de...@oss.oracle.com,linux-unio...@vger.kernel.org,reiserfs-de...@vger.kernel.org,linux-security-mod...@vger.kernel.org,selinux@tycho.nsa.gov,linux-...@vger.kernel.org,kernel-harden...@lists.openwall.com
From: Nicolas Belouin 
Message-ID: <99179b10-4eae-4fab-9d14-b88515626...@belouin.fr>



On October 21, 2017 6:03:02 PM GMT+02:00, "Serge E. Hallyn"  
wrote:
>Quoting Nicolas Belouin (nico...@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

Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED

[nicolas]

,linux-e...@vger.kernel.org,linux-ker...@vger.kernel.org,linux-f2fs-de...@lists.sourceforge.net,linux-fsde...@vger.kernel.org,linux-...@lists.infradead.org,jfs-discuss...@lists.sourceforge.net,ocfs2-de...@oss.oracle.com,linux-unio...@vger.kernel.org,reiserfs-de...@vger.kernel.org,linux-security-mod...@vger.kernel.org,selinux@tycho.nsa.gov,linux-...@vger.kernel.org,kernel-harden...@lists.openwall.com
From: Nicolas Belouin 
Message-ID: 



On October 21, 2017 7:25:21 PM GMT+02:00, Casey Schaufler 
 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 
>> ---
>>  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

Re: [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED

[Serge E. Hallyn]

Quoting Nicolas Belouin (nico...@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?

Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED

[Casey Schaufler]

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

[RFC PATCH 1/2] security, capabilities: create CAP_TRUSTED

[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 
---
 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_TRUSTED39
+
+#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