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

  51d7b120418e ("/proc/iomem: only expose physical resource addresses to privileged users").

[1] https://lore.kernel.org/lkml/201911110934.AC5BA313@keescook/

Reported-by: Zhang Xiaoxu <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: James Morris <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Colin Ian King <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: [email protected]
Cc: Matthew Garrett <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Tyler Hicks <[email protected]>
Cc: x86-ml <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: https://lkml.kernel.org/r/201911181308.63F06502A1@keescook

0 files changed, 0 insertions, 0 deletions