containers.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Alexey Gladkov <legion@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	 Linux Containers <containers@lists.linux.dev>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Christian Brauner <brauner@kernel.org>,
	 Kees Cook <keescook@chromium.org>,
	 Manfred Spraul <manfred@colorfullife.com>
Subject: Re: [PATCH v1] sysctl: Allow change system v ipc sysctls inside ipc namespace
Date: Mon, 25 Jul 2022 11:16:07 -0500	[thread overview]
Message-ID: <87wnc1i2wo.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <54e6b6b1b430537748a7136e854923498443f78a.1657642613.git.legion@kernel.org> (Alexey Gladkov's message of "Tue, 12 Jul 2022 18:17:38 +0200")

Alexey Gladkov <legion@kernel.org> writes:

> Rootless containers are not allowed to modify kernel IPC parameters such
> as kernel.msgmnb.
>
> It seems to me that we can allow customization of these parameters if
> the user has CAP_SYS_RESOURCE in that ipc namespace.
>
> CAP_SYS_RESOURCE is already needed in order to overcome mqueue limits
> (msg_max and msgsize_max).


For changing the permissions on who can modify the SysV limits, I don't
think this change is safe.  I don't see anything that will prevent abuse
if anyone can modify these limits.  Replacing the ordinary unix DAC
permission check with ns_capable will allow anyone to modify the limits.


That said there is RLIMIT_MSGQUEUE that limits the posix messages queues
so those should be safe to allow anyone to modify their limits.

The code in mqueue_get_inode is where that limiting happens.

For the posix message queues all that should be needed is to change the
owner of the sysctl files from the global root to the user namespace
root.  There are also two capable calls in ipc/mqueue.c that can
probably be changed to ns_capable calls.


The only posix message queue limit that I don't immediately see
something that will prevent abuse of is /proc/sys/fs/mqueue/queus_max.
That probably still runs into RLIMIT_MSGQUEUE somewhere but it was
not immediately obvious at first glance.

Eric






>
> Signed-off-by: Alexey Gladkov <legion@kernel.org>
> ---
>  ipc/ipc_sysctl.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
> index ef313ecfb53a..e79452867720 100644
> --- a/ipc/ipc_sysctl.c
> +++ b/ipc/ipc_sysctl.c
> @@ -193,16 +193,19 @@ static int set_is_seen(struct ctl_table_set *set)
>  static int ipc_permissions(struct ctl_table_header *head, struct ctl_table *table)
>  {
>  	int mode = table->mode;
> -
> -#ifdef CONFIG_CHECKPOINT_RESTORE
>  	struct ipc_namespace *ns = current->nsproxy->ipc_ns;
>  
> +#ifdef CONFIG_CHECKPOINT_RESTORE
>  	if (((table->data == &ns->ids[IPC_SEM_IDS].next_id) ||
>  	     (table->data == &ns->ids[IPC_MSG_IDS].next_id) ||
>  	     (table->data == &ns->ids[IPC_SHM_IDS].next_id)) &&
>  	    checkpoint_restore_ns_capable(ns->user_ns))
>  		mode = 0666;
> +	else
>  #endif
> +	if (ns_capable(ns->user_ns, CAP_SYS_RESOURCE))
> +		mode = 0666;
> +
>  	return mode;
>  }

  reply	other threads:[~2022-07-25 16:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-12 16:17 [PATCH v1] sysctl: Allow change system v ipc sysctls inside ipc namespace Alexey Gladkov
2022-07-25 16:16 ` Eric W. Biederman [this message]
2022-08-16 15:42   ` Alexey Gladkov
2022-08-16 15:42     ` [PATCH v1 1/3] " Alexey Gladkov
2022-09-19 15:26       ` Eric W. Biederman
2022-09-20 16:15         ` Alexey Gladkov
2022-09-20 18:08           ` [PATCH v2 0/3] Allow to change ipc/mq " Alexey Gladkov
2022-09-20 18:08             ` [PATCH v2 1/3] sysctl: Allow change system v ipc " Alexey Gladkov
2022-09-21  9:38               ` kernel test robot
2022-09-21 10:41                 ` [PATCH v3 0/3] Allow to change ipc/mq " Alexey Gladkov
2022-09-21 10:41                   ` [PATCH v3 1/3] sysctl: Allow change system v ipc " Alexey Gladkov
2022-09-21 10:41                   ` [PATCH v3 2/3] sysctl: Allow to change limits for posix messages queues Alexey Gladkov
2022-09-21 10:41                   ` [PATCH v3 3/3] docs: Add information about ipc sysctls limitations Alexey Gladkov
2024-01-15 15:46                   ` [RESEND PATCH v3 0/3] Allow to change ipc/mq sysctls inside ipc namespace Alexey Gladkov
2024-01-15 15:46                     ` [RESEND PATCH v3 1/3] sysctl: Allow change system v ipc " Alexey Gladkov
2024-01-15 15:46                     ` [RESEND PATCH v3 2/3] docs: Add information about ipc sysctls limitations Alexey Gladkov
2024-01-15 15:46                     ` [RESEND PATCH v3 3/3] sysctl: Allow to change limits for posix messages queues Alexey Gladkov
2022-09-20 18:08             ` [PATCH v2 2/3] " Alexey Gladkov
2022-09-20 18:08             ` [PATCH v2 3/3] docs: Add information about ipc sysctls limitations Alexey Gladkov
2022-08-16 15:42     ` [PATCH v1 2/3] sysctl: Allow to change limits for posix messages queues Alexey Gladkov
2022-09-19 15:27       ` Eric W. Biederman
2022-08-16 15:42     ` [PATCH v1 3/3] docs: Add information about ipc sysctls limitations Alexey Gladkov
2022-09-19 15:29       ` Eric W. Biederman

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=87wnc1i2wo.fsf@email.froward.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=containers@lists.linux.dev \
    --cc=keescook@chromium.org \
    --cc=legion@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    /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).