Messages in this thread |  | | Date | Thu, 17 Aug 2017 10:29:47 +0900 | From | Sergey Senozhatsky <> | 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
|  |