Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1441013 > unrolled thread
| Started by | AKASHI Takahiro <takahiro.akashi@linaro.org> |
|---|---|
| First post | 2016-07-12 03:40 +0200 |
| Last post | 2016-07-13 15:30 +0200 |
| Articles | 10 on this page of 70 — 14 participants |
Back to article view | Back to linux.kernel
[RFC 0/3] extend kexec_file_load system call AKASHI Takahiro <takahiro.akashi@linaro.org> - 2016-07-12 03:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call ebiederm@xmission.com (Eric W. Biederman) - 2016-07-12 15:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-12 16:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-12 16:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 01:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 15:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-12 16:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-12 16:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-12 16:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-12 17:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-13 04:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 10:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 10:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-13 11:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 15:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-13 20:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 22:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-14 04:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-14 10:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-15 03:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-15 09:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-15 15:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-15 15:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-15 17:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-15 17:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-15 15:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-15 22:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-15 23:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-22 02:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Jeremy Kerr <jeremy.kerr@au1.ibm.com> - 2016-07-22 03:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Michael Ellerman <michael@ellerman.id.au> - 2016-07-22 05:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-22 22:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-15 10:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-15 15:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-13 11:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call AKASHI Takahiro <takahiro.akashi@linaro.org> - 2016-07-13 19:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-13 20:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 22:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-14 14:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-14 04:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-14 04:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-12 18:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Petr Tesarik <ptesarik@suse.cz> - 2016-07-12 23:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call ebiederm@xmission.com (Eric W. Biederman) - 2016-07-12 23:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call ebiederm@xmission.com (Eric W. Biederman) - 2016-07-13 00:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Petr Tesarik <ptesarik@suse.cz> - 2016-07-13 00:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 00:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 07:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 09:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-07-13 09:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 10:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 10:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 10:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 10:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-13 10:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Petr Tesarik <ptesarik@suse.cz> - 2016-07-13 11:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 15:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 19:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 20:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Balbir Singh <bsingharora@gmail.com> - 2016-07-18 14:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-18 15:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-18 15:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Balbir Singh <bsingharora@gmail.com> - 2016-07-20 05:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-20 10:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-20 13:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-20 18:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-20 14:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-20 14:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 01:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 15:30 +0200
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Vivek Goyal <vgoyal@redhat.com> |
|---|---|
| Date | 2016-07-18 15:30 +0200 |
| Message-ID | <rWgMq-6KQ-9@gated-at.bofh.it> |
| In reply to | #1445463 |
On Mon, Jul 18, 2016 at 10:46:04PM +1000, Balbir Singh wrote: > On Wed, 2016-07-13 at 14:22 -0400, Vivek Goyal wrote: > > On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > > > > > > On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote: > > > > > > > > On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote: > > > > > > > > > > Indeed - maybe Eric knows better, but I can't see any situation where > > > > > the dtb we load via kexec should ever affect "the bootloader", unless > > > > > the "kernel" that's being loaded into kexec is "the bootloader". > > > > > > > > > > Now, going back to the more fundamental issue raised in my first reply, > > > > > about the kernel command line. > > > > > > > > > > On x86, I can see that it _is_ possible for userspace to specify a > > > > > command line, and the kernel loading the image provides the command > > > > > line to the to-be-kexeced kernel with very little checking. So, if > > > > > your kernel is signed, what stops the "insecure userspace" loading > > > > > a signed kernel but giving it an insecure rootfs and/or console? > > > > It is not kexec specific. I could do this for regular boot too, right? > > > > > > > > Command line options are not signed. I thought idea behind secureboot > > > > was to execute only trusted code and command line options don't enforce > > > > you to execute unsigned code. > > > > > > You can set module.sig_enforce=0 and open up the system a bit assuming > that you can get a module to load with another attack IIUC, sig_enforce bool_enable_only so it can only be enabled. Default value of it is 0 if CONFIG_MODULE_SIG_FORCE=n. IOW, if your kernel forced signature verification, you should not be able to do sig_enforce=0. If you kernel did not have CONFIG_MODULE_SIG_FORCE=y, then sig_enforce should be 0 by default anyway and you are not making it worse using command line. > > > > > So it sounds like different class of security problems which you are > > > > referring to and not necessarily covered by secureboot or signed > > > > kernel. > > > Let me give you an example. > > > > > > You have a secure boot setup, where the firmware/ROM validates the boot > > > loader. Good, the boot loader hasn't been tampered with. > > > > > > You interrupt the boot loader and are able to modify the command line > > > for the booted kernel. > > > > > > The boot loader loads the kernel and verifies the kernel's signature. > > > Good, the kernel hasn't been tampered with. The kernel starts running. > > > > > > You've plugged in a USB drive to the device, and specified a partition > > > containing a root filesystem that you control to the kernel. The > > > validated kernel finds the USB drive, and mounts it, and executes > > > your own binaries on the USB drive. > > You will require physical access to the machine to be able to > > insert your usb drive. And IIRC, argument was that if attacker has > > physical access to machine, all bets are off anyway. > > > > You don't need physical access -- your machine controller BMC can > do the magic for you. So its not always physical access, is it? Well, idea was that if you have physical access to machine, then all bets are off. If BMC can do something which allows running unsigned code at ring level 0, its a problem I think from secureboot model of security. > > > > > > > > > > You run a shell on the console. You now have control of the system, > > > and can mount the real rootfs, inspect it, and work out what it does, > > > etc. > > > > > > At this point, what use was all the validation that the secure boot > > > has done? Absolutely useless. > > > > > > If you can change the command line arguments given to the kernel, you > > > have no security, no matter how much you verify signatures. It's > > > the illusion of security, nothing more, nothing less. > > > > > I agree, if you can change command line arguments, all bets are of lesser value If changing command line allows execution of unsigned code at ring level 0, then it is a problem. Otherwise we are talking of security issues which are not covered by secureboot model. Vivek
[toc] | [prev] | [next] | [standalone]
| From | Vivek Goyal <vgoyal@redhat.com> |
|---|---|
| Date | 2016-07-18 15:40 +0200 |
| Message-ID | <rWgW5-6NT-19@gated-at.bofh.it> |
| In reply to | #1445482 |
On Mon, Jul 18, 2016 at 09:26:29AM -0400, Vivek Goyal wrote: > On Mon, Jul 18, 2016 at 10:46:04PM +1000, Balbir Singh wrote: > > On Wed, 2016-07-13 at 14:22 -0400, Vivek Goyal wrote: > > > On Wed, Jul 13, 2016 at 06:40:10PM +0100, Russell King - ARM Linux wrote: > > > > > > > > On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote: > > > > > > > > > > On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote: > > > > > > > > > > > > Indeed - maybe Eric knows better, but I can't see any situation where > > > > > > the dtb we load via kexec should ever affect "the bootloader", unless > > > > > > the "kernel" that's being loaded into kexec is "the bootloader". > > > > > > > > > > > > Now, going back to the more fundamental issue raised in my first reply, > > > > > > about the kernel command line. > > > > > > > > > > > > On x86, I can see that it _is_ possible for userspace to specify a > > > > > > command line, and the kernel loading the image provides the command > > > > > > line to the to-be-kexeced kernel with very little checking. So, if > > > > > > your kernel is signed, what stops the "insecure userspace" loading > > > > > > a signed kernel but giving it an insecure rootfs and/or console? > > > > > It is not kexec specific. I could do this for regular boot too, right? > > > > > > > > > > Command line options are not signed. I thought idea behind secureboot > > > > > was to execute only trusted code and command line options don't enforce > > > > > you to execute unsigned code. > > > > > > > > > You can set module.sig_enforce=0 and open up the system a bit assuming > > that you can get a module to load with another attack > > IIUC, sig_enforce bool_enable_only so it can only be enabled. Default > value of it is 0 if CONFIG_MODULE_SIG_FORCE=n. > > IOW, if your kernel forced signature verification, you should not be > able to do sig_enforce=0. If you kernel did not have > CONFIG_MODULE_SIG_FORCE=y, then sig_enforce should be 0 by default anyway > and you are not making it worse using command line. [ CC Matthew Garrett ] I think on top of this there were patches by Matthew Garrett, which disallowed loading of unsigned modules if booted with secureboot on. I think those patches never made upstream though. Vivek > > > > > > > > So it sounds like different class of security problems which you are > > > > > referring to and not necessarily covered by secureboot or signed > > > > > kernel. > > > > Let me give you an example. > > > > > > > > You have a secure boot setup, where the firmware/ROM validates the boot > > > > loader. Good, the boot loader hasn't been tampered with. > > > > > > > > You interrupt the boot loader and are able to modify the command line > > > > for the booted kernel. > > > > > > > > The boot loader loads the kernel and verifies the kernel's signature. > > > > Good, the kernel hasn't been tampered with. The kernel starts running. > > > > > > > > You've plugged in a USB drive to the device, and specified a partition > > > > containing a root filesystem that you control to the kernel. The > > > > validated kernel finds the USB drive, and mounts it, and executes > > > > your own binaries on the USB drive. > > > You will require physical access to the machine to be able to > > > insert your usb drive. And IIRC, argument was that if attacker has > > > physical access to machine, all bets are off anyway. > > > > > > > You don't need physical access -- your machine controller BMC can > > do the magic for you. So its not always physical access, is it? > > Well, idea was that if you have physical access to machine, then all > bets are off. If BMC can do something which allows running unsigned > code at ring level 0, its a problem I think from secureboot model of > security. > > > > > > > > > > > > > > > You run a shell on the console. You now have control of the system, > > > > and can mount the real rootfs, inspect it, and work out what it does, > > > > etc. > > > > > > > > At this point, what use was all the validation that the secure boot > > > > has done? Absolutely useless. > > > > > > > > If you can change the command line arguments given to the kernel, you > > > > have no security, no matter how much you verify signatures. It's > > > > the illusion of security, nothing more, nothing less. > > > > > > > > I agree, if you can change command line arguments, all bets are of lesser value > > If changing command line allows execution of unsigned code at ring level > 0, then it is a problem. Otherwise we are talking of security issues which > are not covered by secureboot model. > > Vivek
[toc] | [prev] | [next] | [standalone]
| From | Balbir Singh <bsingharora@gmail.com> |
|---|---|
| Date | 2016-07-20 05:50 +0200 |
| Message-ID | <rWQGe-4wj-9@gated-at.bofh.it> |
| In reply to | #1445482 |
>>>>> >>>>> Command line options are not signed. I thought idea behind secureboot >>>>> was to execute only trusted code and command line options don't enforce >>>>> you to execute unsigned code. >>>>> >> >> You can set module.sig_enforce=0 and open up the system a bit assuming >> that you can get a module to load with another attack > > IIUC, sig_enforce bool_enable_only so it can only be enabled. Default > value of it is 0 if CONFIG_MODULE_SIG_FORCE=n. > > IOW, if your kernel forced signature verification, you should not be > able to do sig_enforce=0. If you kernel did not have > CONFIG_MODULE_SIG_FORCE=y, then sig_enforce should be 0 by default anyway > and you are not making it worse using command line. > OK.. I checked and you are right, but that is an example and there are other things like security=, thermal.*, nosmep, nosmap that need auditing for safety and might hurt the system security if used. I still think think that assuming you can pass any command line without breaking security is a broken argument. >> >>>>> So it sounds like different class of security problems which you are >>>>> referring to and not necessarily covered by secureboot or signed >>>>> kernel. >>>> Let me give you an example. >>>> >>>> You have a secure boot setup, where the firmware/ROM validates the boot >>>> loader. Good, the boot loader hasn't been tampered with. >>>> >>>> You interrupt the boot loader and are able to modify the command line >>>> for the booted kernel. >>>> >>>> The boot loader loads the kernel and verifies the kernel's signature. >>>> Good, the kernel hasn't been tampered with. The kernel starts running. >>>> >>>> You've plugged in a USB drive to the device, and specified a partition >>>> containing a root filesystem that you control to the kernel. The >>>> validated kernel finds the USB drive, and mounts it, and executes >>>> your own binaries on the USB drive. >>> You will require physical access to the machine to be able to >>> insert your usb drive. And IIRC, argument was that if attacker has >>> physical access to machine, all bets are off anyway. >>> >> >> You don't need physical access -- your machine controller BMC can >> do the magic for you. So its not always physical access, is it? > > Well, idea was that if you have physical access to machine, then all > bets are off. If BMC can do something which allows running unsigned > code at ring level 0, its a problem I think from secureboot model of > security. > >> >>>> >>>> >>>> You run a shell on the console. You now have control of the system, >>>> and can mount the real rootfs, inspect it, and work out what it does, >>>> etc. >>>> >>>> At this point, what use was all the validation that the secure boot >>>> has done? Absolutely useless. >>>> >>>> If you can change the command line arguments given to the kernel, you >>>> have no security, no matter how much you verify signatures. It's >>>> the illusion of security, nothing more, nothing less. >>>> >> >> I agree, if you can change command line arguments, all bets are of lesser value > > If changing command line allows execution of unsigned code at ring level > 0, then it is a problem. Otherwise we are talking of security issues which > are not covered by secure I agree that from what I can see/grep there is nothing that allows unsigned code to run at boot in ring0, but there are implications like the ones I've mentioned above. Attacks are typically built as a chain and every bit might matter. One could turn off features that might lead to the system being attacked at run-time Balbir Singh.
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2016-07-20 10:40 +0200 |
| Message-ID | <rWVcS-7sY-31@gated-at.bofh.it> |
| In reply to | #1446927 |
On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote: > > IOW, if your kernel forced signature verification, you should not be > > able to do sig_enforce=0. If you kernel did not have > > CONFIG_MODULE_SIG_FORCE=y, then sig_enforce should be 0 by default anyway > > and you are not making it worse using command line. > > OK.. I checked and you are right, but that is an example and there are > other things like security=, thermal.*, nosmep, nosmap that need auditing > for safety and might hurt the system security if used. I still think > think that assuming you can pass any command line without breaking security > is a broken argument. Quite, and you don't need to run code in a privileged environment to do any of that. It's also not trivial to protect against: new kernels gain new arguments which older kernels may not know about. No matter how much protection is built into older kernels, newer kernels can become vulnerable through the addition of further arguments. Also, how sure are we that there are no stack overflow issues with kernel command line parsing? Can we be sure that there's none? This is something which happens early in the kernel boot, before the full memory protections have been set up. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-07-20 13:20 +0200 |
| Message-ID | <rWXHI-HL-13@gated-at.bofh.it> |
| In reply to | #1447091 |
On Wednesday, July 20, 2016 8:47:45 PM CEST Michael Ellerman wrote: > At least for stdout-path, I can't really see how that would significantly help > an attacker, but I'm all ears if anyone has ideas. That's actually an easy one that came up before: If an attacker controls a tty device (e.g. network console) that can be used to enter a debugger (kdb, kgdb, xmon, ...), enabling that to be the console device gives you a direct attack vector. The same thing will happen if you have a piece of software that intentially gives extra rights to the owner of the console device by treating it as "physical presence". Arnd
[toc] | [prev] | [next] | [standalone]
| From | Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-20 18:00 +0200 |
| Message-ID | <rX24F-3jb-1@gated-at.bofh.it> |
| In reply to | #1447163 |
Am Mittwoch, 20 Juli 2016, 13:12:20 schrieb Arnd Bergmann: > On Wednesday, July 20, 2016 8:47:45 PM CEST Michael Ellerman wrote: > > At least for stdout-path, I can't really see how that would > > significantly help an attacker, but I'm all ears if anyone has ideas. > > That's actually an easy one that came up before: If an attacker controls > a tty device (e.g. network console) that can be used to enter a debugger > (kdb, kgdb, xmon, ...), enabling that to be the console device > gives you a direct attack vector. The same thing will happen if you > have a piece of software that intentially gives extra rights to the > owner of the console device by treating it as "physical presence". I think people are talking past each other a bit in these arguments about what is relevant to security or not. For the kexec maintainers, kexec_file_load has one very specific and narrow purpose: enable Secure Boot as defined by UEFI. And from what I understand of their arguments so far, there is one and only one security concern: when in Secure Boot mode, a system must not allow execution of unsigned code with kernel privileges. So even if one can specify a different root filesystem and do a lot of nasty things to the system with a rogue userspace in that root filesystem, as long as the kernel won't load unsigned modules that's not a problem as far as they're concerned. Also, AFAIK attacks requiring "physical presence" are out of scope for the UEFI Secure Boot security model. Thus an attack that involves control of a console of plugging an USB device is also not a concern. One thing I don't know is whether an attack involving a networked IPMI console or a USB device that can be "plugged" virtually by a managing system (BMC) is considered a physical attack or a remote attack in the context of UEFI Secure Boot. -- []'s Thiago Jung Bauermann IBM Linux Technology Center
[toc] | [prev] | [next] | [standalone]
| From | Vivek Goyal <vgoyal@redhat.com> |
|---|---|
| Date | 2016-07-20 14:50 +0200 |
| Message-ID | <rWZ6O-1u8-11@gated-at.bofh.it> |
| In reply to | #1447091 |
On Wed, Jul 20, 2016 at 09:35:30AM +0100, Russell King - ARM Linux wrote: > On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote: > > > IOW, if your kernel forced signature verification, you should not be > > > able to do sig_enforce=0. If you kernel did not have > > > CONFIG_MODULE_SIG_FORCE=y, then sig_enforce should be 0 by default anyway > > > and you are not making it worse using command line. > > > > OK.. I checked and you are right, but that is an example and there are > > other things like security=, thermal.*, nosmep, nosmap that need auditing > > for safety and might hurt the system security if used. I still think > > think that assuming you can pass any command line without breaking security > > is a broken argument. > > Quite, and you don't need to run code in a privileged environment to do > any of that. > > It's also not trivial to protect against: new kernels gain new arguments > which older kernels may not know about. No matter how much protection > is built into older kernels, newer kernels can become vulnerable through > the addition of further arguments. If a new kernel command line option becomes an issue, new kernel can block that in secureboot environment. That way it helps kexec boot as well as regular boot. Vivek
[toc] | [prev] | [next] | [standalone]
| From | Vivek Goyal <vgoyal@redhat.com> |
|---|---|
| Date | 2016-07-20 14:30 +0200 |
| Message-ID | <rWYNr-1m8-1@gated-at.bofh.it> |
| In reply to | #1446927 |
On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote: > >>>>> > >>>>> Command line options are not signed. I thought idea behind secureboot > >>>>> was to execute only trusted code and command line options don't enforce > >>>>> you to execute unsigned code. > >>>>> > >> > >> You can set module.sig_enforce=0 and open up the system a bit assuming > >> that you can get a module to load with another attack > > > > IIUC, sig_enforce bool_enable_only so it can only be enabled. Default > > value of it is 0 if CONFIG_MODULE_SIG_FORCE=n. > > > > IOW, if your kernel forced signature verification, you should not be > > able to do sig_enforce=0. If you kernel did not have > > CONFIG_MODULE_SIG_FORCE=y, then sig_enforce should be 0 by default anyway > > and you are not making it worse using command line. > > > > OK.. I checked and you are right, but that is an example and there are > other things like security=, thermal.*, nosmep, nosmap that need auditing > for safety and might hurt the system security if used. I still think > think that assuming you can pass any command line without breaking security > is a broken argument. I agree that if some command line option allows running unsigned code at ring 0, then we probably should disable that on secureboot enabled boot. In fact, there were bunch of patches which made things tighter on secureboot enabled machines from matthew garrett. AFAIK, these patches never went upstream. Vivek
[toc] | [prev] | [next] | [standalone]
| From | Stewart Smith <stewart@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-13 01:50 +0200 |
| Message-ID | <rUfB7-3og-11@gated-at.bofh.it> |
| In reply to | #1441732 |
Petr Tesarik <ptesarik@suse.cz> writes: > On Tue, 12 Jul 2016 13:25:11 -0300 > Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> wrote: > >> Hi Eric, >> >> I'm trying to understand your concerns leading to your nack. I hope you >> don't mind expanding your thoughts on them a bit. >> >> Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: >> > AKASHI Takahiro <takahiro.akashi@linaro.org> writes: >> > > Device tree blob must be passed to a second kernel on DTB-capable >> > > archs, like powerpc and arm64, but the current kernel interface >> > > lacks this support. >> > > >> > > This patch extends kexec_file_load system call by adding an extra >> > > argument to this syscall so that an arbitrary number of file descriptors >> > > can be handed out from user space to the kernel. >> > > >> > > See the background [1]. >> > > >> > > Please note that the new interface looks quite similar to the current >> > > system call, but that it won't always mean that it provides the "binary >> > > compatibility." >> > > >> > > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html >> > >> > So this design is wrong. The kernel already has the device tree blob, >> > you should not be extracting it from the kernel munging it, and then >> > reinserting it in the kernel if you want signatures and everything to >> > pass. >> >> I don't understand how the kernel signature will be invalidated. >> >> There are some types of boot images that can embed a device tree blob in >> them, but the kernel can also be handed a separate device tree blob from >> firmware, the boot loader, or kexec. This latter case is what we are >> discussing, so we are not talking about modifying an embedded blob in the >> kernel image. >> >> > What x86 does is pass it's equivalent of the device tree blob from one >> > kernel to another directly and behind the scenes. It does not go >> > through userspace for this. >> > >> > Until a persuasive case can be made for going around the kernel and >> > probably adding a feature (like code execution) that can be used to >> > defeat the signature scheme I am going to nack this. >> >> I also don't understand what you mean by code execution. How does passing a >> device tree blob via kexec enables code execution? How can the signature >> scheme be defeated? > > I'm not an expert on DTB, so I can't provide an example of code > execution, but you have already mentioned the /chosen/linux,stdout-path > property. If an attacker redirects the bootloader to an insecure > console, they may get access to the system that would otherwise be > impossible. In this case, the user is sitting at the (or one of the) console(s) of the machine. There could be petitboot UIs running on the VGA display, IPMI serial over lan, local serial port. The logic behind setting /chosen/linux,stdout-path is (currently) mostly to set it for the kernel to what the user is interacting with. i.e. if you select an OS installer to boot from the VGA console, you get a graphical installer running and if you selected it from a text console, you get a text installer running (on the appropriate console). So the bootloader (petitboot) needs to work out which console is being interacted with in order to set up /chosen/linux,stdout-path correctly. This specific option could be passed as a kernel command line to the next kernel, yes. However, isn't the kernel command line also an attack vector? Is *every* command line option safe? > In general, tampering with the hardware inventory of a machine opens up > a security hole, and one must be very cautious which modifications are > allowed. You're giving this power to an (unsigned, hence untrusted) > userspace application; Eric argues that only the kernel should have > this power. In the case of petitboot on OpenPOWER, this (will) be a signed and trusted kernel and userspace and verified by a previous bit of firmware. -- Stewart Smith OPAL Architect, IBM.
[toc] | [prev] | [next] | [standalone]
| From | Vivek Goyal <vgoyal@redhat.com> |
|---|---|
| Date | 2016-07-13 15:30 +0200 |
| Message-ID | <rUsoG-3Co-27@gated-at.bofh.it> |
| In reply to | #1441922 |
On Wed, Jul 13, 2016 at 09:41:39AM +1000, Stewart Smith wrote: > Petr Tesarik <ptesarik@suse.cz> writes: > > On Tue, 12 Jul 2016 13:25:11 -0300 > > Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> wrote: > > > >> Hi Eric, > >> > >> I'm trying to understand your concerns leading to your nack. I hope you > >> don't mind expanding your thoughts on them a bit. > >> > >> Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > >> > AKASHI Takahiro <takahiro.akashi@linaro.org> writes: > >> > > Device tree blob must be passed to a second kernel on DTB-capable > >> > > archs, like powerpc and arm64, but the current kernel interface > >> > > lacks this support. > >> > > > >> > > This patch extends kexec_file_load system call by adding an extra > >> > > argument to this syscall so that an arbitrary number of file descriptors > >> > > can be handed out from user space to the kernel. > >> > > > >> > > See the background [1]. > >> > > > >> > > Please note that the new interface looks quite similar to the current > >> > > system call, but that it won't always mean that it provides the "binary > >> > > compatibility." > >> > > > >> > > [1] http://lists.infradead.org/pipermail/kexec/2016-June/016276.html > >> > > >> > So this design is wrong. The kernel already has the device tree blob, > >> > you should not be extracting it from the kernel munging it, and then > >> > reinserting it in the kernel if you want signatures and everything to > >> > pass. > >> > >> I don't understand how the kernel signature will be invalidated. > >> > >> There are some types of boot images that can embed a device tree blob in > >> them, but the kernel can also be handed a separate device tree blob from > >> firmware, the boot loader, or kexec. This latter case is what we are > >> discussing, so we are not talking about modifying an embedded blob in the > >> kernel image. > >> > >> > What x86 does is pass it's equivalent of the device tree blob from one > >> > kernel to another directly and behind the scenes. It does not go > >> > through userspace for this. > >> > > >> > Until a persuasive case can be made for going around the kernel and > >> > probably adding a feature (like code execution) that can be used to > >> > defeat the signature scheme I am going to nack this. > >> > >> I also don't understand what you mean by code execution. How does passing a > >> device tree blob via kexec enables code execution? How can the signature > >> scheme be defeated? > > > > I'm not an expert on DTB, so I can't provide an example of code > > execution, but you have already mentioned the /chosen/linux,stdout-path > > property. If an attacker redirects the bootloader to an insecure > > console, they may get access to the system that would otherwise be > > impossible. > > In this case, the user is sitting at the (or one of the) console(s) of > the machine. There could be petitboot UIs running on the VGA display, > IPMI serial over lan, local serial port. The logic behind setting > /chosen/linux,stdout-path is (currently) mostly to set it for the kernel > to what the user is interacting with. i.e. if you select an OS installer > to boot from the VGA console, you get a graphical installer running and > if you selected it from a text console, you get a text installer running > (on the appropriate console). > > So the bootloader (petitboot) needs to work out which console is being > interacted with in order to set up /chosen/linux,stdout-path correctly. > > This specific option could be passed as a kernel command line to the > next kernel, yes. However, isn't the kernel command line also an attack > vector? Is *every* command line option safe? I don't think kernel command line is signed. And we will have to define what is considered *unsafe*. I am working on the assumption that a user should not be able to force execution of unsigned code at provileged level. And passing console on kernel command line should be safe in that respect? Vivek
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | linux.kernel
csiph-web