Messages in this thread | | | From | Kees Cook <> | Date | Thu, 17 Aug 2017 16:01:49 -0700 | Subject | Re: [PATCH 2/2] Revert "pstore: Honor dmesg_restrict sysctl on dmesg dumps" |
| |
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
| |