From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753693AbdHQXBw (ORCPT <rfc822;w@1wt.eu>);
        Thu, 17 Aug 2017 19:01:52 -0400
Received: from mail-it0-f45.google.com ([209.85.214.45]:34191 "EHLO
        mail-it0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752632AbdHQXBu (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 17 Aug 2017 19:01:50 -0400
MIME-Version: 1.0
In-Reply-To: <20170817012947.GB20907@jagdpanzerIV.localdomain>
References: <1502397395-118652-1-git-send-email-keescook@chromium.org>
 <1502397395-118652-3-git-send-email-keescook@chromium.org>
 <20170816075922.GC522@jagdpanzerIV.localdomain> <CAGXu5jJ485xcf=_5U1GOWPTUPn16jdmseguiKPo46xjB5-XQ0w@mail.gmail.com>
 <20170817012947.GB20907@jagdpanzerIV.localdomain>
From: Kees Cook <keescook@chromium.org>
Date: Thu, 17 Aug 2017 16:01:49 -0700
X-Google-Sender-Auth: eyZnKplIwMDlKhVw0wCRd7kBVog
Message-ID: <CAGXu5jJEiaOyaOTqa--5HzX225VhAisa4Axj-i-N_AJRFU-j3A@mail.gmail.com>
Subject: Re: [PATCH 2/2] Revert "pstore: Honor dmesg_restrict sysctl on dmesg dumps"
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Nick Kralevich <nnk@google.com>,
        Sebastian Schmidt <yath@yath.de>, Tony Luck <tony.luck@intel.com>,
        Anton Vorontsov <anton@enomsg.org>, Colin Cross <ccross@android.com>,
        Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Patrick Tjin <pattjin@google.com>, Mark Salyzyn <salyzyn@google.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Aug 16, 2017 at 6:29 PM, Sergey Senozhatsky
<sergey.senozhatsky.work@gmail.com> wrote:
> can we accidentally "leak" kernel pointers or some other critical
> info? kptr_restrict requires CAP_SYSLOG and pstore read used to
> require CAP_SYSLOG, but it seems that now we can bypass it by
> letting "entirely unprivileged groups" to read pstore. is there
> something to be concerned about (or at least mention it in the
> commit messages)?

I can expand the commit message a bit more, sure. There may be
sensitive things in pstorefs, and it's up to a system builder to
decide how they want to deal with that risk. Most users of pstore
don't mount with update_ms=N so pstorefs contains (mostly) old
addresses. Without this change, though, a builder can't give
permissions to an unprivileged crash dump process without also giving
it CAP_SYSLOG which has much MORE privilege that it would need
(reading and wiping _current_ dmesg, for example).

-Kees

-- 
Kees Cook
Pixel Security