lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ