From: Vivek Goyal <vgoyal@redhat.com>
To: Balbir Singh <bsingharora@gmail.com>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
Stewart Smith <stewart@linux.vnet.ibm.com>,
bhe@redhat.com, arnd@arndb.de, Petr Tesarik <ptesarik@suse.cz>,
linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>,
dyoung@redhat.com, linux-arm-kernel@lists.infradead.org,
mjg59@srcf.ucam.org
Subject: Re: [RFC 0/3] extend kexec_file_load system call
Date: Mon, 18 Jul 2016 09:38:24 -0400 [thread overview]
Message-ID: <20160718133824.GC32512@redhat.com> (raw)
In-Reply-To: <20160718132629.GB32512@redhat.com>
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
next prev parent reply other threads:[~2016-07-18 13:38 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 1:41 [RFC 0/3] extend kexec_file_load system call AKASHI Takahiro
2016-07-12 1:41 ` [RFC 1/3] syscall: add kexec_file_load to generic unistd.h AKASHI Takahiro
2016-07-12 1:42 ` [RFC 2/3] kexec: add dtb info to struct kimage AKASHI Takahiro
2016-07-12 1:42 ` [RFC 3/3] kexec: extend kexec_file_load system call AKASHI Takahiro
2016-07-15 13:09 ` Vivek Goyal
2016-07-15 13:19 ` Mark Rutland
2016-07-18 2:30 ` Dave Young
2016-07-18 10:07 ` Mark Rutland
2016-07-19 0:55 ` Dave Young
2016-07-19 10:52 ` Mark Rutland
2016-07-19 12:24 ` Vivek Goyal
2016-07-19 12:47 ` Mark Rutland
2016-07-19 13:26 ` Vivek Goyal
2016-07-20 11:41 ` David Laight
2016-07-21 9:21 ` Russell King - ARM Linux
2016-07-18 2:33 ` Dave Young
2016-07-27 0:24 ` [PATCH v2 " Thiago Jung Bauermann
2016-08-05 20:46 ` Thiago Jung Bauermann
2016-07-12 13:25 ` [RFC 0/3] " Eric W. Biederman
2016-07-12 13:58 ` Thiago Jung Bauermann
2016-07-12 14:02 ` Vivek Goyal
2016-07-12 23:45 ` Stewart Smith
2016-07-13 13:27 ` Vivek Goyal
2016-07-12 14:02 ` Arnd Bergmann
2016-07-12 14:18 ` Vivek Goyal
2016-07-12 14:24 ` Arnd Bergmann
2016-07-12 14:50 ` Mark Rutland
2016-07-13 2:36 ` Dave Young
2016-07-13 8:01 ` Arnd Bergmann
2016-07-13 8:23 ` Stewart Smith
2016-07-13 9:41 ` Mark Rutland
2016-07-13 13:13 ` Arnd Bergmann
2016-07-13 18:45 ` Thiago Jung Bauermann
2016-07-13 19:59 ` Arnd Bergmann
2016-07-14 2:18 ` Thiago Jung Bauermann
2016-07-14 8:29 ` Arnd Bergmann
2016-07-15 1:44 ` Thiago Jung Bauermann
2016-07-15 7:31 ` Arnd Bergmann
2016-07-15 13:26 ` Vivek Goyal
2016-07-15 13:33 ` Mark Rutland
2016-07-15 15:29 ` Thiago Jung Bauermann
2016-07-15 15:47 ` Mark Rutland
2016-07-15 13:42 ` Russell King - ARM Linux
2016-07-15 20:26 ` Arnd Bergmann
2016-07-15 21:03 ` Thiago Jung Bauermann
2016-07-22 0:09 ` Thiago Jung Bauermann
2016-07-22 0:53 ` Jeremy Kerr
2016-07-22 2:54 ` Michael Ellerman
2016-07-22 20:41 ` Thiago Jung Bauermann
2016-07-15 8:49 ` Russell King - ARM Linux
2016-07-15 13:03 ` Vivek Goyal
2016-07-13 9:34 ` Mark Rutland
2016-07-13 17:38 ` AKASHI Takahiro
2016-07-13 17:58 ` Mark Rutland
2016-07-13 19:57 ` Arnd Bergmann
2016-07-14 12:42 ` Mark Rutland
2016-07-14 1:54 ` Dave Young
2016-07-14 1:50 ` Dave Young
2016-07-12 16:25 ` Thiago Jung Bauermann
2016-07-12 20:58 ` Petr Tesarik
2016-07-12 21:22 ` Eric W. Biederman
2016-07-12 21:36 ` Eric W. Biederman
2016-07-12 21:53 ` Petr Tesarik
2016-07-12 22:18 ` Russell King - ARM Linux
2016-07-13 4:59 ` Stewart Smith
2016-07-13 7:36 ` Russell King - ARM Linux
2016-07-13 7:47 ` Ard Biesheuvel
2016-07-13 8:09 ` Russell King - ARM Linux
2016-07-13 8:20 ` Stewart Smith
2016-07-13 7:55 ` Stewart Smith
2016-07-13 8:26 ` Russell King - ARM Linux
2016-07-13 8:36 ` Dave Young
2016-07-13 8:57 ` Petr Tesarik
2016-07-13 13:03 ` Vivek Goyal
2016-07-13 17:40 ` Russell King - ARM Linux
2016-07-13 18:22 ` Vivek Goyal
2016-07-18 12:46 ` Balbir Singh
2016-07-18 13:26 ` Vivek Goyal
2016-07-18 13:38 ` Vivek Goyal [this message]
2016-07-20 3:45 ` Balbir Singh
2016-07-20 8:35 ` Russell King - ARM Linux
2016-07-20 11:12 ` Arnd Bergmann
2016-07-20 15:50 ` Thiago Jung Bauermann
2016-07-20 12:46 ` Vivek Goyal
2016-07-20 12:27 ` Vivek Goyal
2016-07-12 23:41 ` Stewart Smith
2016-07-13 13:25 ` Vivek Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160718133824.GC32512@redhat.com \
--to=vgoyal@redhat.com \
--cc=arnd@arndb.de \
--cc=bauerman@linux.vnet.ibm.com \
--cc=bhe@redhat.com \
--cc=bsingharora@gmail.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mjg59@srcf.ucam.org \
--cc=ptesarik@suse.cz \
--cc=stewart@linux.vnet.ibm.com \
--cc=takahiro.akashi@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).