[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez3ojo9cLuZWjeB4W2Etv3gJrkAryxMLrgFc-awgYVvoHQ@mail.gmail.com>
Date: Fri, 30 Oct 2020 19:00:16 +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 5:06 PM Mickaël Salaün <mic@...ikod.net> wrote:
> On 30/10/2020 16:47, Jann Horn wrote:
> > 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.
>
> This give guarantee that the cred variable will not be used for
> something else than current_cred(), which kinda prove that this patch
> doesn't change the behavior of __ptrace_may_access() by not using cred
> in ptrace_has_cap(). It doesn't hurt and I think it could be useful to
> spot issues when backporting.
And it might require an extra fixup while backporting because the next
line is different and that might cause the patch to not apply.
Powered by blists - more mailing lists