[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez1LFAKoi-nvipsar2SAH0eNhKkOzWj4Fuf9wNCtpWsH9A@mail.gmail.com>
Date: Fri, 30 Oct 2020 16:47:47 +0100
From: Jann Horn <jannh@...gle.com>
To: Mickaël Salaün <mic@...ikod.net>
Cc: Christian Brauner <christian.brauner@...ntu.com>,
Kees Cook <keescook@...omium.org>,
Oleg Nesterov <oleg@...hat.com>,
Eric Paris <eparis@...hat.com>,
James Morris <jmorris@...ei.org>,
"Serge E . Hallyn" <serge@...lyn.com>,
Tyler Hicks <tyhicks@...ux.microsoft.com>,
Will Drewry <wad@...omium.org>,
kernel list <linux-kernel@...r.kernel.org>,
stable <stable@...r.kernel.org>,
Mickaël Salaün <mic@...ux.microsoft.com>
Subject: Re: [PATCH v1 1/2] ptrace: Set PF_SUPERPRIV when checking capability
On Fri, Oct 30, 2020 at 1:39 PM Mickaël Salaün <mic@...ikod.net> wrote:
> Commit 69f594a38967 ("ptrace: do not audit capability check when outputing
> /proc/pid/stat") replaced the use of ns_capable() with
> has_ns_capability{,_noaudit}() which doesn't set PF_SUPERPRIV.
>
> Commit 6b3ad6649a4c ("ptrace: reintroduce usage of subjective credentials in
> ptrace_has_cap()") replaced has_ns_capability{,_noaudit}() with
> security_capable(), which doesn't set PF_SUPERPRIV neither.
>
> Since commit 98f368e9e263 ("kernel: Add noaudit variant of ns_capable()"), a
> new ns_capable_noaudit() helper is available. Let's use it!
>
> As a result, the signature of ptrace_has_cap() is restored to its original one.
>
> Cc: Christian Brauner <christian.brauner@...ntu.com>
> Cc: Eric Paris <eparis@...hat.com>
> Cc: Jann Horn <jannh@...gle.com>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Oleg Nesterov <oleg@...hat.com>
> Cc: Serge E. Hallyn <serge@...lyn.com>
> Cc: Tyler Hicks <tyhicks@...ux.microsoft.com>
> Cc: stable@...r.kernel.org
> Fixes: 6b3ad6649a4c ("ptrace: reintroduce usage of subjective credentials in ptrace_has_cap()")
> Fixes: 69f594a38967 ("ptrace: do not audit capability check when outputing /proc/pid/stat")
> Signed-off-by: Mickaël Salaün <mic@...ux.microsoft.com>
Yeah... I guess this makes sense. (We'd have to undo or change it if
we ever end up needing to use a different set of credentials, e.g.
from ->f_cred, but I guess that's really something we should avoid
anyway.)
Reviewed-by: Jann Horn <jannh@...gle.com>
with one nit:
[...]
> /* Returns 0 on success, -errno on denial. */
> static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> {
> - const struct cred *cred = current_cred(), *tcred;
> + const struct cred *const cred = current_cred(), *tcred;
This is an unrelated change, and almost no kernel code marks local
pointer variables as "const". I would drop this change from the patch.
> struct mm_struct *mm;
> kuid_t caller_uid;
> kgid_t caller_gid;
Powered by blists - more mailing lists