* Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image [not found] ` <20190404003249.14356-2-matthewgarrett@google.com> @ 2019-04-16 8:40 ` Andrew Donnellan 2019-04-18 6:38 ` Daniel Axtens 2019-04-18 19:35 ` Matthew Garrett 0 siblings, 2 replies; 6+ messages in thread From: Andrew Donnellan @ 2019-04-16 8:40 UTC (permalink / raw) To: Matthew Garrett, jmorris Cc: linux-api, cmr, linux-kernel, dhowells, linux-security-module, luto, linuxppc-dev, Daniel Axtens On 4/4/19 11:32 am, Matthew Garrett wrote: > diff --git a/Documentation/ABI/testing/lockdown b/Documentation/ABI/testing/lockdown > new file mode 100644 > index 000000000000..5bd51e20917a > --- /dev/null > +++ b/Documentation/ABI/testing/lockdown > @@ -0,0 +1,19 @@ > +What: security/lockdown > +Date: March 2019 > +Contact: Matthew Garrett <mjg59@google.com> > +Description: > + If CONFIG_LOCK_DOWN_KERNEL is enabled, the kernel can be > + moved to a more locked down state at runtime by writing to > + this attribute. Valid values are: > + > + integrity: > + The kernel will disable functionality that allows > + userland to modify the running kernel image, other > + than through the loading or execution of appropriately > + signed objects. > + > + confidentiality: > + The kernel will disable all functionality disabled by > + the integrity mode, but additionally will disable > + features that potentially permit userland to obtain > + confidential information stored within the kernel. [+ linuxppc, mpe, dja, cmr] I'm thinking about whether we should lock down the powerpc xmon debug monitor - intuitively, I think the answer is yes if for no other reason than Least Astonishment, when lockdown is enabled you probably don't expect xmon to keep letting you access kernel memory. Semantically though, xmon is not a userspace process - it's in kernel and reads debug commands/outputs debug data directly from/to the console. Is that a threat vector that this series cares about? -- Andrew Donnellan OzLabs, ADL Canberra andrew.donnellan@au1.ibm.com IBM Australia Limited ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image 2019-04-16 8:40 ` [PATCH V32 01/27] Add the ability to lock down access to the running kernel image Andrew Donnellan @ 2019-04-18 6:38 ` Daniel Axtens 2019-04-18 19:35 ` Matthew Garrett 1 sibling, 0 replies; 6+ messages in thread From: Daniel Axtens @ 2019-04-18 6:38 UTC (permalink / raw) To: Andrew Donnellan, Matthew Garrett, jmorris Cc: linux-api, cmr, linux-kernel, dhowells, linux-security-module, luto, linuxppc-dev Hi Andrew, >> + If CONFIG_LOCK_DOWN_KERNEL is enabled, the kernel can be >> + moved to a more locked down state at runtime by writing to >> + this attribute. Valid values are: >> + >> + integrity: >> + The kernel will disable functionality that allows >> + userland to modify the running kernel image, other >> + than through the loading or execution of appropriately >> + signed objects. >> + >> + confidentiality: >> + The kernel will disable all functionality disabled by >> + the integrity mode, but additionally will disable >> + features that potentially permit userland to obtain >> + confidential information stored within the kernel. > > [+ linuxppc, mpe, dja, cmr] > > I'm thinking about whether we should lock down the powerpc xmon debug > monitor - intuitively, I think the answer is yes if for no other reason > than Least Astonishment, when lockdown is enabled you probably don't > expect xmon to keep letting you access kernel memory. > > Semantically though, xmon is not a userspace process - it's in kernel > and reads debug commands/outputs debug data directly from/to the > console. Is that a threat vector that this series cares about? I guess there are 2 ways you could think about lockdown: - It adds a security boundary between the kernel and UID 0, so that userland cannot compromise the integrity/confidentiality of the locked down kernel. - It is a bundle of related security boundaries so that the integrity/confidentiality of a running, locked down kernel cannot be compromised, even by a privileged, physically present user. You're right that techincally xmon is in the kernel and on the console rather than in userland, so it doesn't fall within the first concept of lockdown. But I think usecases for lockdown tend to expect something more like the second concept. IOW, lockdown is a trapdoor - once you've locked down a kernel, you can't get out of lockdown (except by rebooting). xmon would allow you to get out of the trapdoor, so I think it should be restricted by lockdown. Regards, Daniel > > > -- > Andrew Donnellan OzLabs, ADL Canberra > andrew.donnellan@au1.ibm.com IBM Australia Limited ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image 2019-04-16 8:40 ` [PATCH V32 01/27] Add the ability to lock down access to the running kernel image Andrew Donnellan 2019-04-18 6:38 ` Daniel Axtens @ 2019-04-18 19:35 ` Matthew Garrett 2019-04-29 0:06 ` Daniel Axtens 1 sibling, 1 reply; 6+ messages in thread From: Matthew Garrett @ 2019-04-18 19:35 UTC (permalink / raw) To: Andrew Donnellan Cc: Linux API, cmr, James Morris, Linux Kernel Mailing List, David Howells, LSM List, Andy Lutomirski, linuxppc-dev, Daniel Axtens On Tue, Apr 16, 2019 at 1:40 AM Andrew Donnellan <andrew.donnellan@au1.ibm.com> wrote: > I'm thinking about whether we should lock down the powerpc xmon debug > monitor - intuitively, I think the answer is yes if for no other reason > than Least Astonishment, when lockdown is enabled you probably don't > expect xmon to keep letting you access kernel memory. The original patchset contained a sysrq hotkey to allow physically present users to disable lockdown, so I'm not super concerned about this case - I could definitely be convinced otherwise, though. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image 2019-04-18 19:35 ` Matthew Garrett @ 2019-04-29 0:06 ` Daniel Axtens 2019-04-29 4:54 ` Daniel Axtens 0 siblings, 1 reply; 6+ messages in thread From: Daniel Axtens @ 2019-04-29 0:06 UTC (permalink / raw) To: Matthew Garrett, Andrew Donnellan Cc: Linux API, cmr, James Morris, Linux Kernel Mailing List, David Howells, LSM List, Andy Lutomirski, linuxppc-dev Matthew Garrett <mjg59@google.com> writes: > On Tue, Apr 16, 2019 at 1:40 AM Andrew Donnellan > <andrew.donnellan@au1.ibm.com> wrote: >> I'm thinking about whether we should lock down the powerpc xmon debug >> monitor - intuitively, I think the answer is yes if for no other reason >> than Least Astonishment, when lockdown is enabled you probably don't >> expect xmon to keep letting you access kernel memory. > > The original patchset contained a sysrq hotkey to allow physically > present users to disable lockdown, so I'm not super concerned about > this case - I could definitely be convinced otherwise, though. So currently (and I'm pretty new to this as I've only recently rejoined IBM) we aren't considering access to the console to be sufficient to assert physical presence on bare-metal server-class Power machines. The short argument for this is that with IPMI and BMCs, a server's console isn't what it used to be. Our console is also a bit different to x86: we don't generally have bios configuration screens on the console. In your example, a sysrq key would allow you to disable lockdown after the system has booted. On Power though, we use Linux as a bootloader (Petitboot: https://github.com/open-power/petitboot) so being able to disable lockdown there allows an IPMI-connected user to prevent a signed kernel being loaded in the first place. I don't know if this is _actually_ worse, but it certainly feels worse. There are of course some arguments against our approach. I'm aware of some of them. I'm also very open to being told that not equating console access with physical access is fundamentally silly or broken and that we should rethink things. Regards, Daniel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image 2019-04-29 0:06 ` Daniel Axtens @ 2019-04-29 4:54 ` Daniel Axtens 2019-04-30 5:15 ` Andrew Donnellan 0 siblings, 1 reply; 6+ messages in thread From: Daniel Axtens @ 2019-04-29 4:54 UTC (permalink / raw) To: Matthew Garrett, Andrew Donnellan Cc: Linux API, cmr, James Morris, Linux Kernel Mailing List, David Howells, LSM List, Andy Lutomirski, linuxppc-dev Hi, >>> I'm thinking about whether we should lock down the powerpc xmon debug >>> monitor - intuitively, I think the answer is yes if for no other reason >>> than Least Astonishment, when lockdown is enabled you probably don't >>> expect xmon to keep letting you access kernel memory. >> >> The original patchset contained a sysrq hotkey to allow physically >> present users to disable lockdown, so I'm not super concerned about >> this case - I could definitely be convinced otherwise, though. So Mimi contacted me offlist and very helpfully provided me with a much better and less confused justification for disabling xmon in lockdown: On x86, physical presence (== console access) is a trigger to disable/enable lockdown mode. In lockdown mode, you're not supposed to be able to modify memory. xmon allows you to modify memory, and therefore shouldn't be allowed in lockdown. So, if you can disable lockdown on the console that's probably OK, but it should be specifically disabling lockdown, not randomly editing memory with xmon. Regards, Daniel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image 2019-04-29 4:54 ` Daniel Axtens @ 2019-04-30 5:15 ` Andrew Donnellan 0 siblings, 0 replies; 6+ messages in thread From: Andrew Donnellan @ 2019-04-30 5:15 UTC (permalink / raw) To: Daniel Axtens, Matthew Garrett Cc: Linux API, cmr, James Morris, Linux Kernel Mailing List, David Howells, LSM List, Andy Lutomirski, linuxppc-dev On 29/4/19 2:54 pm, Daniel Axtens wrote: > Hi, > >>>> I'm thinking about whether we should lock down the powerpc xmon debug >>>> monitor - intuitively, I think the answer is yes if for no other reason >>>> than Least Astonishment, when lockdown is enabled you probably don't >>>> expect xmon to keep letting you access kernel memory. >>> >>> The original patchset contained a sysrq hotkey to allow physically >>> present users to disable lockdown, so I'm not super concerned about >>> this case - I could definitely be convinced otherwise, though. > > So Mimi contacted me offlist and very helpfully provided me with a much > better and less confused justification for disabling xmon in lockdown: > > On x86, physical presence (== console access) is a trigger to > disable/enable lockdown mode. > > In lockdown mode, you're not supposed to be able to modify memory. xmon > allows you to modify memory, and therefore shouldn't be allowed in > lockdown. > > So, if you can disable lockdown on the console that's probably OK, but > it should be specifically disabling lockdown, not randomly editing > memory with xmon. That makes sense. -- Andrew Donnellan OzLabs, ADL Canberra andrew.donnellan@au1.ibm.com IBM Australia Limited ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-04-30 5:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20190404003249.14356-1-matthewgarrett@google.com>
[not found] ` <20190404003249.14356-2-matthewgarrett@google.com>
2019-04-16 8:40 ` [PATCH V32 01/27] Add the ability to lock down access to the running kernel image Andrew Donnellan
2019-04-18 6:38 ` Daniel Axtens
2019-04-18 19:35 ` Matthew Garrett
2019-04-29 0:06 ` Daniel Axtens
2019-04-29 4:54 ` Daniel Axtens
2019-04-30 5:15 ` Andrew Donnellan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).