x86/mtrr: Require CAP_SYS_ADMIN for all access
Zhang Xiaoxu noted that physical address locations for MTRR were visible to non-root users, which could be considered an information leak. In discussing[1] the options for solving this, it sounded like just moving the capable check into open() was the first step. If this breaks userspace, then we will have a test case for the more conservative approaches discussed in the thread. In summary: - MTRR should check capabilities at open time (or retain the checks on the opener's permissions for later checks). - changing the DAC permissions might break something that expects to open mtrr when not uid 0. - if we leave the DAC permissions alone and just move the capable check to the opener, we should get the desired protection. (i.e. check against CAP_SYS_ADMIN not just the wider uid 0.) - if that still breaks things, as in userspace expects to be able to read other parts of the file as non-uid-0 and non-CAP_SYS_ADMIN, then we need to censor the contents using the opener's permissions. For example, as done in other /proc cases, like commit 51d7b120 ("/proc/iomem: only expose physical resource addresses to privileged users"). [1] https://lore.kernel.org/lkml/201911110934.AC5BA313@keescook/Reported-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: James Morris <jamorris@linux.microsoft.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-security-module@vger.kernel.org Cc: Matthew Garrett <mjg59@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tyler Hicks <tyhicks@canonical.com> Cc: x86-ml <x86@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/201911181308.63F06502A1@keescook
Showing
Please register or sign in to comment