Messages in this thread | | | Date | Fri, 18 Aug 2017 08:24:37 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH 2/2] Revert "pstore: Honor dmesg_restrict sysctl on dmesg dumps" |
| |
Hello,
On (08/17/17 16:01), Kees Cook wrote: > 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.
that would be lovely. please do.
> 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.
I see...
> 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).
ok, the "CAP_SYSLOG and _current_ dmesg" point is surely interesting. could you please also add this to the commit message?
FWIW, both patches
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
-ss
| |