linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
To: Jonathan Calmels <jcalmels@3xx0.net>,
	brauner@kernel.org,  ebiederm@xmission.com,
	Jonathan Corbet <corbet@lwn.net>,
	Paul Moore <paul@paul-moore.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	KP Singh <kpsingh@kernel.org>,
	Matt Bobrowski <mattbobrowski@google.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Luis Chamberlain <mcgrof@kernel.org>, Kees Cook <kees@kernel.org>,
	Joel Granados <j.granados@samsung.com>,
	John Johansen <john.johansen@canonical.com>,
	David Howells <dhowells@redhat.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Stephen Smalley <stephen.smalley.work@gmail.com>,
	Ondrej Mosnacek <omosnace@redhat.com>,
	 Mykola Lysenko <mykolal@fb.com>, Shuah Khan <shuah@kernel.org>
Cc: containers@lists.linux.dev, linux-kernel@vger.kernel.org,
	 linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org,
	 linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
	 apparmor@lists.ubuntu.com, keyrings@vger.kernel.org,
	selinux@vger.kernel.org,  linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 2/4] capabilities: Add securebit to restrict userns caps
Date: Fri, 28 Jun 2024 17:43:38 +0300	[thread overview]
Message-ID: <f4de777099b0dff819ee6277b3b7cd7e18d96c78.camel@iki.fi> (raw)
In-Reply-To: <20240609104355.442002-3-jcalmels@3xx0.net>

On Sun, 2024-06-09 at 03:43 -0700, Jonathan Calmels wrote:
> This patch adds a new capability security bit designed to constrain a


nit: if you think of it "This patch adds" could be just "add", right? :-)

Also name the exact thing/symbol/whatever here. This is not a HBO series.

> task’s userns capability set to its bounding set. The reason for this
> is
> twofold:
> 
> - This serves as a quick and easy way to lock down a set of
> capabilities
>   for a task, thus ensuring that any namespace it creates will never
> be
>   more privileged than itself is.
> - This helps userspace transition to more secure defaults by not
> requiring
>   specific logic for the userns capability set, or libcap support.
> 
> Example:
> 
>     # capsh --secbits=$((1 << 8)) --drop=cap_sys_rawio -- \
>             -c 'unshare -r grep Cap /proc/self/status'
>     CapInh: 0000000000000000
>     CapPrm: 000001fffffdffff
>     CapEff: 000001fffffdffff
>     CapBnd: 000001fffffdffff
>     CapAmb: 0000000000000000
>     CapUNs: 000001fffffdffff
> 
> Signed-off-by: Jonathan Calmels <jcalmels@3xx0.net>
> ---
>  include/linux/securebits.h      |  1 +
>  include/uapi/linux/securebits.h | 11 ++++++++++-
>  kernel/user_namespace.c         |  5 +++++
>  3 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/securebits.h b/include/linux/securebits.h
> index 656528673983..5f9d85cd69c3 100644
> --- a/include/linux/securebits.h
> +++ b/include/linux/securebits.h
> @@ -5,4 +5,5 @@
>  #include <uapi/linux/securebits.h>
>  
>  #define issecure(X)		(issecure_mask(X) &
> current_cred_xxx(securebits))
> +#define iscredsecure(cred, X)	(issecure_mask(X) & cred-
> >securebits)
>  #endif /* !_LINUX_SECUREBITS_H */
> diff --git a/include/uapi/linux/securebits.h
> b/include/uapi/linux/securebits.h
> index d6d98877ff1a..2da3f4be4531 100644
> --- a/include/uapi/linux/securebits.h
> +++ b/include/uapi/linux/securebits.h
> @@ -52,10 +52,19 @@
>  #define SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED \
>  			(issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE_L
> OCKED))
>  
> +/* When set, user namespace capabilities are restricted to their
> parent's bounding set. */
> +#define SECURE_USERNS_STRICT_CAPS			8
> +#define SECURE_USERNS_STRICT_CAPS_LOCKED		9  /* make



> bit-8 immutable */
> +
> +#define SECBIT_USERNS_STRICT_CAPS
> (issecure_mask(SECURE_USERNS_STRICT_CAPS))
> +#define SECBIT_USERNS_STRICT_CAPS_LOCKED \
> +			(issecure_mask(SECURE_USERNS_STRICT_CAPS_LOC
> KED))
> +
>  #define
> SECURE_ALL_BITS		(issecure_mask(SECURE_NOROOT) | \
>  				
> issecure_mask(SECURE_NO_SETUID_FIXUP) | \
>  				 issecure_mask(SECURE_KEEP_CAPS) | \
> -				
> issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE))
> +				
> issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE) | \
> +				

spurious new lines in the diff

please as first priority aim for absolute minimal diff or at least
do grow diff proactively like this.

If we really think after that, that we need some "extras" to the
patch set, then we decide that. These only take energy away from
reviewers.


> issecure_mask(SECURE_USERNS_STRICT_CAPS))
>  #define SECURE_ALL_LOCKS	(SECURE_ALL_BITS << 1)
>  
>  #endif /* _UAPI_LINUX_SECUREBITS_H */
> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
> index 7e624607330b..53848e2b68cd 100644
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -10,6 +10,7 @@
>  #include <linux/cred.h>
>  #include <linux/securebits.h>
>  #include <linux/security.h>
> +#include <linux/capability.h>
>  #include <linux/keyctl.h>
>  #include <linux/key-type.h>
>  #include <keys/user-type.h>
> @@ -42,6 +43,10 @@ static void dec_user_namespaces(struct ucounts
> *ucounts)
>  
>  static void set_cred_user_ns(struct cred *cred, struct
> user_namespace *user_ns)
>  {
> +	/* Limit userns capabilities to our parent's bounding set.
> */
> +	if (iscredsecure(cred, SECURE_USERNS_STRICT_CAPS))
> +		cred->cap_userns = cap_intersect(cred->cap_userns,
> cred->cap_bset);
> +
>  	/* Start with the capabilities defined in the userns set. */
>  	cred->cap_bset = cred->cap_userns;
>  	cred->cap_permitted = cred->cap_userns;

Going for 4 week holiday starting for next week so focus in on nits
but since this is something to do access control:

1. Please go surgical with the diff's because this type of patches
also require a surgical review. Now reviewing this like riding on 
a bumpy road with a car of which suspension mechanics is broken
;-)

Hope you grab my argument here. I only want to look at the problem
and solution for that not random stuff..

BR, Jarkko

  parent reply	other threads:[~2024-06-28 14:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-09 10:43 [PATCH v2 0/4] Introduce user namespace capabilities Jonathan Calmels
2024-06-09 10:43 ` [PATCH v2 1/4] capabilities: Add " Jonathan Calmels
2024-06-10  1:50   ` Serge E. Hallyn
2024-06-10  8:47     ` Jonathan Calmels
2024-06-10 12:48       ` Serge E. Hallyn
2024-06-10 13:00   ` Serge E. Hallyn
2024-06-11  8:20     ` Jonathan Calmels
2024-06-15 15:19       ` Serge E. Hallyn
2024-06-09 10:43 ` [PATCH v2 2/4] capabilities: Add securebit to restrict userns caps Jonathan Calmels
2024-06-10  2:33   ` Serge E. Hallyn
2024-06-10  9:46     ` Jonathan Calmels
2024-06-10 13:05       ` Serge E. Hallyn
2024-06-28 14:43   ` Jarkko Sakkinen [this message]
2024-06-28 14:45     ` Jarkko Sakkinen
2024-06-09 10:43 ` [PATCH v2 3/4] capabilities: Add sysctl to mask off " Jonathan Calmels
2024-06-09 10:43 ` [PATCH v2 4/4] bpf,lsm: Allow editing capabilities in BPF-LSM hooks Jonathan Calmels
2024-06-10  0:18   ` Paul Moore
2024-06-11  8:09     ` Jonathan Calmels
2024-06-11 10:31       ` John Johansen
2024-06-11 19:01         ` Paul Moore
2024-06-11 22:20           ` Jonathan Calmels
2024-06-11 22:38             ` Paul Moore
2024-06-12  8:20               ` Jonathan Calmels
2024-06-12 17:29                 ` Paul Moore
2024-06-13  3:54                   ` John Johansen
2024-06-13  8:50                     ` Jonathan Calmels
2024-06-13 20:55                       ` Paul Moore
2024-06-15 15:20                       ` Serge E. Hallyn
2024-06-13 10:45                     ` Dr. Greg
2024-06-13 20:43                     ` Paul Moore
2024-06-10 20:12 ` [PATCH v2 0/4] Introduce user namespace capabilities Josef Bacik
2024-06-11  8:33   ` Jonathan Calmels

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=f4de777099b0dff819ee6277b3b7cd7e18d96c78.camel@iki.fi \
    --to=jarkko.sakkinen@iki.fi \
    --cc=andrii@kernel.org \
    --cc=apparmor@lists.ubuntu.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=containers@lists.linux.dev \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=j.granados@samsung.com \
    --cc=jarkko@kernel.org \
    --cc=jcalmels@3xx0.net \
    --cc=jmorris@namei.org \
    --cc=john.fastabend@gmail.com \
    --cc=john.johansen@canonical.com \
    --cc=jolsa@kernel.org \
    --cc=kees@kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mattbobrowski@google.com \
    --cc=mcgrof@kernel.org \
    --cc=mykolal@fb.com \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=sdf@google.com \
    --cc=selinux@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=yonghong.song@linux.dev \
    /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;
as well as URLs for NNTP newsgroup(s).