From: Casey Schaufler <casey@schaufler-ca.com> To: Nicolas Belouin <nicolas@belouin.fr>, kernel-hardening@lists.openwall.com, David Howells <dhowells@redhat.com>, "Theodore Ts'o" <tytso@mit.edu>, Andreas Dilger <adilger.kernel@dilger.ca>, Alexander Viro <viro@zeniv.linux.org.uk>, Serge Hallyn <serge@hallyn.com>, Paul Moore <paul@paul-moore.com>, Stephen Smalley <sds@tycho.nsa.gov>, Eric Paris <eparis@parisplace.org>, James Morris <james.l.morris@oracle.com>, 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 Subject: Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: Add CAP_SYS_MOUNT Date: Sat, 21 Oct 2017 17:54:11 -0700 [thread overview] Message-ID: <8d0ff7c9-a27f-db74-5870-3d4bdb5784b1@schaufler-ca.com> (raw) In-Reply-To: <AED1D433-EDCE-4B0B-AB8D-55627E5B94A4@belouin.fr> On 10/21/2017 11:41 AM, Nicolas Belouin wrote: > > On October 21, 2017 7:31:24 PM GMT+02:00, Casey Schaufler <casey@schaufler-ca.com> 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 <nicolas@belouin.fr> >>> --- >>> 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 >
WARNING: multiple messages have this Message-ID (diff)
From: casey@schaufler-ca.com (Casey Schaufler) To: linux-security-module@vger.kernel.org Subject: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: Add CAP_SYS_MOUNT Date: Sat, 21 Oct 2017 17:54:11 -0700 [thread overview] Message-ID: <8d0ff7c9-a27f-db74-5870-3d4bdb5784b1@schaufler-ca.com> (raw) In-Reply-To: <AED1D433-EDCE-4B0B-AB8D-55627E5B94A4@belouin.fr> On 10/21/2017 11:41 AM, Nicolas Belouin wrote: > > On October 21, 2017 7:31:24 PM GMT+02:00, Casey Schaufler <casey@schaufler-ca.com> 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 <nicolas@belouin.fr> >>> --- >>> 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
next prev parent reply other threads:[~2017-10-22 0:54 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-10-21 13:43 [RFC PATCH 1/2] security, capabilities: Add CAP_SYS_MOUNT Nicolas Belouin 2017-10-21 13:43 ` [kernel-hardening] " Nicolas Belouin 2017-10-21 13:43 ` Nicolas Belouin 2017-10-21 13:43 ` [RFC PATCH 2/2] fs: add the possibility to use CAP_SYS_MOUNT to (u)mount a fs Nicolas Belouin 2017-10-21 13:43 ` [kernel-hardening] " Nicolas Belouin 2017-10-21 13:43 ` Nicolas Belouin 2017-10-21 17:31 ` [kernel-hardening] [RFC PATCH 1/2] security, capabilities: Add CAP_SYS_MOUNT Casey Schaufler 2017-10-21 17:31 ` Casey Schaufler 2017-10-21 17:31 ` Casey Schaufler 2017-10-21 18:41 ` [kernel-hardening] " Nicolas Belouin 2017-10-21 18:41 ` Nicolas Belouin 2017-10-21 18:41 ` Nicolas Belouin 2017-10-22 0:54 ` Casey Schaufler [this message] 2017-10-22 0:54 ` [kernel-hardening] " Casey Schaufler 2017-10-23 12:57 ` Stephen Smalley 2017-10-23 12:57 ` [kernel-hardening] " Stephen Smalley 2017-10-23 12:57 ` Stephen Smalley
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8d0ff7c9-a27f-db74-5870-3d4bdb5784b1@schaufler-ca.com \ --to=casey@schaufler-ca.com \ --cc=adilger.kernel@dilger.ca \ --cc=dhowells@redhat.com \ --cc=eparis@parisplace.org \ --cc=james.l.morris@oracle.com \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-cachefs@redhat.com \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=nicolas@belouin.fr \ --cc=paul@paul-moore.com \ --cc=sds@tycho.nsa.gov \ --cc=selinux@tycho.nsa.gov \ --cc=serge@hallyn.com \ --cc=tytso@mit.edu \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.