From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932302AbdJVAyT (ORCPT ); Sat, 21 Oct 2017 20:54:19 -0400 Received: from sonic305-28.consmr.mail.ne1.yahoo.com ([66.163.185.154]:42474 "EHLO sonic305-28.consmr.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932271AbdJVAyR (ORCPT ); Sat, 21 Oct 2017 20:54:17 -0400 X-YMail-OSG: LUw7FwwVM1kftLvXPgDkvHwdGsO.uP6Bvcp2w7CB6yP8zLf.rqjiHwxJMEutYPi f6qfSigySOVq0kt6oNlE2w1PhwnXEI8suueWpHbMI6eFJmcWU5m2xOaLrl4kvjypf3ttfuNVkAj7 _Yh9As9fNSdHJ0FJxJlDuQXhDBybUH1iDJ9x3geZtuVVKYUjI3VGplaRLubyuSPHe.JvervRcs62 DNdaM8ER39RlB_.E6x.H6TXxlliqGE5r.Svbo6bwSQPuUWhN9Y0hU1AqcnMLCAzL.nkWuEkdP6I9 tD3ZN1ed0hfwcZLUpSW3tyklJA_DEO8COgeCAIssk82CV_msblyKKIiIYrErqupy.KggCdcfrxvg Guv.Q4kauzQMCIoJF4f8x_emt9ZlLSceNHfSro8GmT_DRbax3BAtRUYVUogrtKRJJzCgSd6bOeO7 VJlxQrqXrAX49vUhENRebdlNEneAABAtsmY9S0WILvxbyKvYGhpM8dngi3qDbjo1XZINA_KNZTRK mwTD906OC6YeeJ3PYCqhxMK7rFnR_8A-- X-Yahoo-Newman-Id: 534451.1668.bm@smtp202.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LUw7FwwVM1kftLvXPgDkvHwdGsO.uP6Bvcp2w7CB6yP8zLf .rqjiHwxJMEutYPif6qfSigySOVq0kt6oNlE2w1PhwnXEI8suueWpHbMI6eF JmcWU5m2xOaLrl4kvjypf3ttfuNVkAj7_Yh9As9fNSdHJ0FJxJlDuQXhDByb UH1iDJ9x3geZtuVVKYUjI3VGplaRLubyuSPHe.JvervRcs62DNdaM8ER39Rl B_.E6x.H6TXxlliqGE5r.Svbo6bwSQPuUWhN9Y0hU1AqcnMLCAzL.nkWuEkd P6I9tD3ZN1ed0hfwcZLUpSW3tyklJA_DEO8COgeCAIssk82CV_msblyKKIiI YrErqupy.KggCdcfrxvgGuv.Q4kauzQMCIoJF4f8x_emt9ZlLSceNHfSro8G mT_DRbax3BAtRUYVUogrtKRJJzCgSd6bOeO7VJlxQrqXrAX49vUhENRebdlN EneAABAtsmY9S0WILvxbyKvYGhpM8dngi3qDbjo1XZINA_KNZTRKmwTD906O C6YeeJ3PYCqhxMK7rFnR_8A-- X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: Add CAP_SYS_MOUNT To: Nicolas Belouin , kernel-hardening@lists.openwall.com, David Howells , "Theodore Ts'o" , Andreas Dilger , Alexander Viro , Serge Hallyn , Paul Moore , Stephen Smalley , Eric Paris , James Morris , linux-cachefs@redhat.com, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov, linux-api@vger.kernel.org References: <20171021134303.20685-1-nicolas@belouin.fr> From: Casey Schaufler Message-ID: <8d0ff7c9-a27f-db74-5870-3d4bdb5784b1@schaufler-ca.com> Date: Sat, 21 Oct 2017 17:54:11 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 11:41 AM, Nicolas Belouin wrote: > > On October 21, 2017 7:31:24 PM GMT+02:00, Casey Schaufler wrote: >> On 10/21/2017 6:43 AM, Nicolas Belouin wrote: >>> With CAP_SYS_ADMIN being bloated and inapropriate for actions such >>> as mounting/unmounting filesystems, the creation of a new capability >>> is needed. >>> CAP_SYS_MOUNT is meant to give a process the ability to call for >> mount, >>> umount and umount2 syscalls. >> This is increased granularity for it's own sake. There is no >> compelling reason to break out this capability in particular. > Obviously there is a need to break CAP_SYS_ADMIN in pieces, No. This is a baseless assumption. Granularity for the sake of granularity is bad. Data General (a dead company) followed the fine grained capability path and ended up with 330 capabilities. Developers can't handle the granularity we already have (hell, half of them don't know what mode bits are for) and making it finer will only make it harder for them to make use of the ones we have. > to do so, you have to start somewhere, so I chose to begin with this. > >> Can you identify existing use cases where you would have >> CAP_SYS_MOUNT without also having CAP_SYS_ADMIN? I should think >> that all the work that's gone into unprivileged mounts over >> the past couple years would make this unnecessary. > If you look at the udiskd deamon used by most desktop environments, it is launched as root or at least with CAP_SYS_ADMIN. Here, you could use CAP_SYS_MOUNT. Does this demon do anything else that uses CAP_SYS_ADMIN? If it has to have that anyway, it's not an argument for breaking out the mount capability.   > There might also be a use within containers as you don't want to give CAP_SYS_ADMIN to a container if it just need to mount/unmount filesystems. There is massive work going on elsewhere to allow containers to mount without privilege. And I'm not at all interested in "might". > If you go even further, it could be used to allow swapon/swapoff (maybe in future patch set). No, you'd be asking for CAP_SWAP for that. Swap control has nothing to do with mounting filesystems. > >>> Signed-off-by: Nicolas Belouin >>> --- >>> include/uapi/linux/capability.h | 5 ++++- >>> security/selinux/include/classmap.h | 4 ++-- >>> 2 files changed, 6 insertions(+), 3 deletions(-) >>> >>> diff --git a/include/uapi/linux/capability.h >> b/include/uapi/linux/capability.h >>> index 230e05d35191..ce230aa6d928 100644 >>> --- a/include/uapi/linux/capability.h >>> +++ b/include/uapi/linux/capability.h >>> @@ -365,8 +365,11 @@ struct vfs_ns_cap_data { >>> >>> #define CAP_AUDIT_READ 37 >>> >>> +/* Allow mounting, unmounting filesystems */ >>> >>> -#define CAP_LAST_CAP CAP_AUDIT_READ >>> +#define CAP_SYS_MOUNT 38 >>> + >>> +#define CAP_LAST_CAP CAP_SYS_MOUNT >>> >>> #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 35ffb29a69cb..a873dce97fd5 100644 >>> --- a/security/selinux/include/classmap.h >>> +++ b/security/selinux/include/classmap.h >>> @@ -24,9 +24,9 @@ >>> "audit_control", "setfcap" >>> >>> #define COMMON_CAP2_PERMS "mac_override", "mac_admin", "syslog", \ >>> - "wake_alarm", "block_suspend", "audit_read" >>> + "wake_alarm", "block_suspend", "audit_read", "sys_mount" >>> >>> -#if CAP_LAST_CAP > CAP_AUDIT_READ >>> +#if CAP_LAST_CAP > CAP_SYS_MOUNT >>> #error New capability defined, please update COMMON_CAP2_PERMS. >>> #endif >>> > Nicolas > From mboxrd@z Thu Jan 1 00:00:00 1970 From: casey@schaufler-ca.com (Casey Schaufler) Date: Sat, 21 Oct 2017 17:54:11 -0700 Subject: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: Add CAP_SYS_MOUNT In-Reply-To: References: <20171021134303.20685-1-nicolas@belouin.fr> Message-ID: <8d0ff7c9-a27f-db74-5870-3d4bdb5784b1@schaufler-ca.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On 10/21/2017 11:41 AM, Nicolas Belouin wrote: > > On October 21, 2017 7:31:24 PM GMT+02:00, Casey Schaufler wrote: >> On 10/21/2017 6:43 AM, Nicolas Belouin wrote: >>> With CAP_SYS_ADMIN being bloated and inapropriate for actions such >>> as mounting/unmounting filesystems, the creation of a new capability >>> is needed. >>> CAP_SYS_MOUNT is meant to give a process the ability to call for >> mount, >>> umount and umount2 syscalls. >> This is increased granularity for it's own sake. There is no >> compelling reason to break out this capability in particular. > Obviously there is a need to break CAP_SYS_ADMIN in pieces, No. This is a baseless assumption. Granularity for the sake of granularity is bad. Data General (a dead company) followed the fine grained capability path and ended up with 330 capabilities. Developers can't handle the granularity we already have (hell, half of them don't know what mode bits are for) and making it finer will only make it harder for them to make use of the ones we have. > to do so, you have to start somewhere, so I chose to begin with this. > >> Can you identify existing use cases where you would have >> CAP_SYS_MOUNT without also having CAP_SYS_ADMIN? I should think >> that all the work that's gone into unprivileged mounts over >> the past couple years would make this unnecessary. > If you look at the udiskd deamon used by most desktop environments, it is launched as root or at least with CAP_SYS_ADMIN. Here, you could use CAP_SYS_MOUNT. Does this demon do anything else that uses CAP_SYS_ADMIN? If it has to have that anyway, it's not an argument for breaking out the mount capability. ? > There might also be a use within containers as you don't want to give CAP_SYS_ADMIN to a container if it just need to mount/unmount filesystems. There is massive work going on elsewhere to allow containers to mount without privilege. And I'm not at all interested in "might". > If you go even further, it could be used to allow swapon/swapoff (maybe in future patch set). No, you'd be asking for CAP_SWAP for that. Swap control has nothing to do with mounting filesystems. > >>> Signed-off-by: Nicolas Belouin >>> --- >>> include/uapi/linux/capability.h | 5 ++++- >>> security/selinux/include/classmap.h | 4 ++-- >>> 2 files changed, 6 insertions(+), 3 deletions(-) >>> >>> diff --git a/include/uapi/linux/capability.h >> b/include/uapi/linux/capability.h >>> index 230e05d35191..ce230aa6d928 100644 >>> --- a/include/uapi/linux/capability.h >>> +++ b/include/uapi/linux/capability.h >>> @@ -365,8 +365,11 @@ struct vfs_ns_cap_data { >>> >>> #define CAP_AUDIT_READ 37 >>> >>> +/* Allow mounting, unmounting filesystems */ >>> >>> -#define CAP_LAST_CAP CAP_AUDIT_READ >>> +#define CAP_SYS_MOUNT 38 >>> + >>> +#define CAP_LAST_CAP CAP_SYS_MOUNT >>> >>> #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 35ffb29a69cb..a873dce97fd5 100644 >>> --- a/security/selinux/include/classmap.h >>> +++ b/security/selinux/include/classmap.h >>> @@ -24,9 +24,9 @@ >>> "audit_control", "setfcap" >>> >>> #define COMMON_CAP2_PERMS "mac_override", "mac_admin", "syslog", \ >>> - "wake_alarm", "block_suspend", "audit_read" >>> + "wake_alarm", "block_suspend", "audit_read", "sys_mount" >>> >>> -#if CAP_LAST_CAP > CAP_AUDIT_READ >>> +#if CAP_LAST_CAP > CAP_SYS_MOUNT >>> #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