From: Christian Brauner <christian.brauner@ubuntu.com>
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org, Jann Horn <jannh@google.com>,
Oleg Nesterov <oleg@redhat.com>,
stable@vger.kernel.org, Serge Hallyn <serge@hallyn.com>,
Eric Paris <eparis@redhat.com>
Subject: Re: [REVIEW PATCH v2] ptrace: reintroduce usage of subjective credentials in ptrace_has_cap()
Date: Fri, 17 Jan 2020 12:08:28 +0100 [thread overview]
Message-ID: <20200117110827.g7n42assgyvcfzaz@wittgenstein> (raw)
In-Reply-To: <202001161753.27427AD@keescook>
On Thu, Jan 16, 2020 at 06:29:26PM -0800, Kees Cook wrote:
> On Thu, Jan 16, 2020 at 11:45:18PM +0100, Christian Brauner wrote:
> > As one example where this might be particularly problematic, Jann pointed
> > out that in combination with the upcoming IORING_OP_OPENAT feature, this
> > bug might allow unprivileged users to bypass the capability checks while
> > asynchronously opening files like /proc/*/mem, because the capability
> > checks for this would be performed against kernel credentials.
To follow up on this part of your mail. No, afaict, it's not
aboutwinning a race. It's way simpler...
When io uring creates a new kernel context it records the subjective
credentials of the caller:
ctx = io_ring_ctx_alloc(p);
if (!ctx) {
if (account_mem)
io_unaccount_mem(user, ring_pages(p->sq_entries,
p->cq_entries));
free_uid(user);
return -ENOMEM;
}
ctx->compat = in_compat_syscall();
ctx->account_mem = account_mem;
ctx->user = user;
------> ctx->creds = get_current_cred(); <------
Later on, when it starts to do work it creates a kernel thread:
ctx->sqo_thread = kthread_create_on_cpu(io_sq_thread,
ctx, cpu,
"io_uring-sq");
} else {
ctx->sqo_thread = kthread_create(io_sq_thread, ctx,
"io_uring-sq");
}
and registers io_sq_thread as "callback". The callback io_sq_thread()
runs __with kernel creds__. To prevent this from becoming an issue
io_sq_thread() will override the __subjective credentials__ with the
callers credentials:
old_cred = override_creds(ctx->creds);
But ptrace_has_cap() currently looks at __task_cred(current) aka
__real_cred__. This means once IORING_OP_OPENAT and IORING_OP_OPENAT2
lands in v5.5-rc6 it is more or less trivial for an unprivileged user to
bypass ptrace_may_access().
Christian
prev parent reply other threads:[~2020-01-17 11:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 22:45 [REVIEW PATCH v2] ptrace: reintroduce usage of subjective credentials in ptrace_has_cap() Christian Brauner
2020-01-17 2:29 ` Kees Cook
2020-01-17 5:16 ` Christian Brauner
2020-01-17 21:07 ` Kees Cook
2020-01-17 11:08 ` Christian Brauner [this message]
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=20200117110827.g7n42assgyvcfzaz@wittgenstein \
--to=christian.brauner@ubuntu.com \
--cc=eparis@redhat.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=serge@hallyn.com \
--cc=stable@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 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).