All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jann Horn <jannh@google.com>
To: 18650033736@163.com
Cc: kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kernel: prevent submission of creds with higher privileges inside container
Date: Fri, 14 Sep 2018 13:23:10 +0200	[thread overview]
Message-ID: <CAG48ez3o+v6=FcEy40MbbQzpLYXPz4ehQ-z8VRsEvU3ghWxzZA@mail.gmail.com> (raw)
In-Reply-To: <1536922536-5803-1-git-send-email-18650033736@163.com>

On Fri, Sep 14, 2018 at 1:14 PM My Name <18650033736@163.com> wrote:
> Adversaries often attack the Linux kernel via using
> commit_creds(prepare_kernel_cred(0)) to submit ROOT
> credential for the purpose of privilege escalation.
> For processes inside the Linux container, the above
> approach also works, because the container and the
> host share the same Linux kernel. Therefore, we en-
> force a check in commit_creds() before updating the
> cred of the caller process. If the process is insi-
> de a container (judging from the Namespace ID) and
> try to submit credentials with higher privileges t-
> han current (judging from the uid, gid, and cap_bset
> in the new cred), we will stop the modification. We
> consider that if the namespace ID of the process is
> different from the init Namespace ID (enumed in /i-
> nclude/linux/proc_ns.h), the process is inside a c-
> ontainer. And if the uid/gid in the new cred is sm-
> aller or the cap_bset (capability bounding set) in
> the new cred is larger, it may be a privilege esca-
> lation operation.

You only sent this patch to the LKML list without CC'ing anyone.
People are unlikely to see your patches this way; you may want to, for
example, CC the kernel-hardening list and people who have touched the
files your patch changes in the past. More information on this is at
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#select-the-recipients-for-your-patch
.

You sent five different versions of this patch; when you send multiple
versions of a patch, please ensure that the subject line contains the
version of the patch, as described in
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
.

I also disagree with the fundamental approach taken in your patch; in
my opinion, it is pointless to attempt to prevent kernel exploitation
by restricting usage of one specific function.

> Signed-off-by: Xin Lin <18650033736@163.com>
> ---
>  kernel/cred.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
>
> diff --git a/kernel/cred.c b/kernel/cred.c
> index ecf0365..b9a313d 100644
> --- a/kernel/cred.c
> +++ b/kernel/cred.c
> @@ -19,6 +19,12 @@
>  #include <linux/security.h>
>  #include <linux/binfmts.h>
>  #include <linux/cn_proc.h>
> +#include <linux/proc_ns.h>
> +#include <linux/ipc_namespace.h>
> +#include "../fs/mount.h"
> +#include <net/net_namespace.h>
> +#include <linux/capability.h>
> +#include <linux/cgroup.h>
>
>  #if 0
>  #define kdebug(FMT, ...)                                               \
> @@ -33,6 +39,8 @@ do {                                                                  \
>  } while (0)
>  #endif
>
> +bool flag = true;
> +static struct net *initnet;
>  static struct kmem_cache *cred_jar;
>
>  /* init to 2 - one for init_task, one to ensure it is never freed */
> @@ -425,6 +433,22 @@ int commit_creds(struct cred *new)
>         struct task_struct *task = current;
>         const struct cred *old = task->real_cred;
>
> +       if (flag) {
> +               initnet = get_net_ns_by_pid(1);
> +               flag = false;
> +       }
> +       if (task->nsproxy->uts_ns->ns.inum != PROC_UTS_INIT_INO ||
> +       task->nsproxy->ipc_ns->ns.inum != PROC_IPC_INIT_INO ||
> +       task->nsproxy->mnt_ns->ns.inum != 0xF0000000U ||
> +       task->nsproxy->pid_ns_for_children->ns.inum != PROC_PID_INIT_INO ||
> +       task->nsproxy->net_ns->ns.inum != initnet->ns.inum ||
> +       old->user_ns->ns.inum != PROC_USER_INIT_INO ||
> +       task->nsproxy->cgroup_ns->ns.inum != PROC_CGROUP_INIT_INO) {
> +               if (new->uid.val < old->uid.val || new->gid.val < old->gid.val
> +               || new->cap_bset.cap[0] > old->cap_bset.cap[0])
> +                       return 0;
> +       }
> +
>         kdebug("commit_creds(%p{%d,%d})", new,
>                atomic_read(&new->usage),
>                read_cred_subscribers(new));
> --
> 2.7.4
>
>
>

  reply	other threads:[~2018-09-14 11:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-14 10:55 [PATCH] kernel: prevent submission of creds with higher privileges inside container My Name
2018-09-14 11:23 ` Jann Horn [this message]
2018-09-14 22:01 ` kbuild test robot
2018-09-19  3:16 ` [LKP] [kernel] 7b00cf1438: BUG:unable_to_handle_kernel kernel test robot
2018-09-19  3:16   ` kernel test robot
  -- strict thread matches above, loose matches on Subject: below --
2018-09-14  7:25 [PATCH] kernel: prevent submission of creds with higher privileges inside container My Name
2018-09-14 10:20 ` kbuild test robot
2018-09-12  6:46 My Name
2018-09-11  7:29 My Name
2018-09-11  2:08 My Name
2018-09-11  6:47 ` kbuild test robot
2018-09-11  6:53 ` kbuild test robot

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='CAG48ez3o+v6=FcEy40MbbQzpLYXPz4ehQ-z8VRsEvU3ghWxzZA@mail.gmail.com' \
    --to=jannh@google.com \
    --cc=18650033736@163.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 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.