From: Casey Schaufler <casey@schaufler-ca.com>
To: Nicolas Belouin <nicolas@belouin.fr>,
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, kernel-hardening@lists.openwall.com
Subject: Re: [kernel-hardening] [RFC PATCH 1/2] security, capabilities: Add CAP_SYS_MOUNT
Date: Sat, 21 Oct 2017 10:31:24 -0700 [thread overview]
Message-ID: <edfdfc70-fd07-4930-c7f5-0d2b6355b09b@schaufler-ca.com> (raw)
In-Reply-To: <20171021134303.20685-1-nicolas@belouin.fr>
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.
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.
> 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
>
next prev parent reply other threads:[~2017-10-21 17:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 17:31 ` Casey Schaufler [this message]
2017-10-21 18:41 ` [kernel-hardening] [RFC PATCH 1/2] security, capabilities: Add CAP_SYS_MOUNT Nicolas Belouin
2017-10-22 0:54 ` Casey Schaufler
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=edfdfc70-fd07-4930-c7f5-0d2b6355b09b@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®