linux-kernel - Re: [PATCH 2/2] Revert "pstore: Honor dmesg

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]

Date:   Thu, 17 Aug 2017 10:29:47 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Nick Kralevich <nnk@...gle.com>,
        Sebastian Schmidt <yath@...h.de>,
        Tony Luck <tony.luck@...el.com>,
        Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Patrick Tjin <pattjin@...gle.com>,
        Mark Salyzyn <salyzyn@...gle.com>
Subject: Re: [PATCH 2/2] Revert "pstore: Honor dmesg_restrict sysctl on dmesg
 dumps"

Hello Kees,

On (08/16/17 08:38), Kees Cook wrote:
[..]
> > so, effectively, `dmesg_restrict' does not work for pstore anymore? wouldn't
> > that be a problem? one more thing, doesn't it affect the consistency -- we
> > respect the `dmesg_restrict' restrictions, except that we ignore it when
> > access pstore? or do I completely misunderstand the change? sorry if so.
> 
> This revert is combined with the commit before it which changes the
> perms of the pstorefs rootdir to 750. Privacy is retained, but now a
> system owner can modify access to specific entirely unprivileged
> groups (that do no require CAP_SYSLOG).

sure, I saw the 0750 change.

> Note, also, that pstore (normally) shows only the prior boot's console
> and crash.

one more question,

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)?

	-ss