Hello, On (08/17/17 16:01), Kees Cook wrote: > On Wed, Aug 16, 2017 at 6:29 PM, Sergey Senozhatsky > <[email protected]> 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 <[email protected]> -ss
