| Message ID | 20190907061124.1947-1-cmr@informatik.wtf (mailing list archive) |
|---|---|
| Headers | show |
| Series | Restrict xmon when kernel is locked down | expand |
Hi, So Matthew Garrett and I talked about this at Linux Plumbers. Matthew, if I understood correctly, your concern was that this doesn't sit well with the existing threat model for lockdown. As I understand it, the idea is that if you're able to get access to the physical console, you're already able to get around most restictions by just dropping into the BIOS/UEFI configuration, disabling secure boot and booting something of your choice. xmon, being a Linux feature that only operates on the physical console, therefore falls outside the threat model for lockdown. I've had a few chats with powerpc people about this, and I think our consensus is that the boundaries of our threat model are slightly different. Power machines are almost all server-class*, and therefore the console is almost always accessed over IPMI or the BMC. As such, we don't consider console access to be the same as physical access but instead consider it a form of, or akin to, remote access. This makes more sense on bare-metal powerpc than it does on x86: we don't have a boot-time configuration system that's accessible on the console, so you can't get around secure boot or any other lockdown restrictions that way. It's also consistent across our future plans: our planned assertion of physical presence for authorising unsigned keys for secureboot involves pressing a physical button on the case at a particular point in the boot sequence, rather than typing in something at the console. So I think that given that this doesn't disrupt anything else in lockdown or affect any other platforms, it's worth taking. Kind regards, Daniel * yes, there are 32-bit and even some 64-bit embedded systems still. But I don't think that should preclude xmon going in to lockdown: the existence of powerpc boxes where the physical console may be trusted doesn't mean that this is true of all the powerpc systems. > Xmon should be either fully or partially disabled depending on the > kernel lockdown state. > > Put xmon into read-only mode for lockdown=integrity and completely > disable xmon when lockdown=confidentiality. Since this can occur > dynamically, there may be pre-existing, active breakpoints in xmon when > transitioning into read-only mode. These breakpoints will still trigger, > so allow them to be listed and cleared using xmon. > > Changes since v6: > - Add lockdown check in sysrq-trigger to prevent entry into xmon_core > - Add lockdown check during init xmon setup for the case when booting > with compile-time or cmdline lockdown=confidentialiaty > > Changes since v5: > - Do not spam print messages when attempting to enter xmon when > lockdown=confidentiality > > Changes since v4: > - Move lockdown state checks into xmon_core > - Allow clearing of breakpoints in xmon read-only mode > - Test simple scenarios (combinations of xmon and lockdown cmdline > options, setting breakpoints and changing lockdown state, etc) in > QEMU and on an actual POWER8 VM > - Rebase onto security/next-lockdown > b602614a81078bf29c82b2671bb96a63488f68d6 > > Changes since v3: > - Allow active breakpoints to be shown/listed in read-only mode > > Changes since v2: > - Rebased onto v36 of https://patchwork.kernel.org/cover/11049461/ > (based on: f632a8170a6b667ee4e3f552087588f0fe13c4bb) > - Do not clear existing breakpoints when transitioning from > lockdown=none to lockdown=integrity > - Remove line continuation and dangling quote (confuses checkpatch.pl) > from the xmon command help/usage string > > Christopher M. Riedl (2): > powerpc/xmon: Allow listing and clearing breakpoints in read-only mode > powerpc/xmon: Restrict when kernel is locked down > > arch/powerpc/xmon/xmon.c | 119 +++++++++++++++++++++++++++-------- > include/linux/security.h | 2 + > security/lockdown/lockdown.c | 2 + > 3 files changed, 97 insertions(+), 26 deletions(-) > > -- > 2.23.0