Re: [RFC] Second attempt at kernel secure boot support
> You have a fair chance of protecting via physical means (Locked rooms, > Background checks on users etc.) of preventing a user with malicious intent > to access the local machine. So called "secure boot" doesn't deal with any kind of physical access, which also means its useless if a device is lost and returned and you don't know if it was in the hands of a third party. > The first thing a computer does when switched on is run its first code > instructions. Commonly referred to as the BIOS. A good deal more complicated than that. However the signing in hardware and early boot up on a lot of devices already goes as far as the BIOS if the system has BIOS or EFI if it doesn't. You also have all the devices to deal with. > Normally digital signatures would examine the binary, ensure the signature > matches, and then run the code contained in it. No - it's a good deal more complicated than that too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Hi, The basis for any secure boot is a way to detect that the system has been tampered with or not. "Tamper Evidence". There are two main vectors for a system to be tampered with. Someone local to the machine and remote users who can access the machine across a network interface. (this includes the local user installing a program from a remote source) You have a fair chance of protecting via physical means (Locked rooms, Background checks on users etc.) of preventing a user with malicious intent to access the local machine. The first thing a computer does when switched on is run its first code instructions. Commonly referred to as the BIOS. It would therefore be a requirement to ensure that the BIOS cannot be tampered with via any other method apart from physically located at the machine. Once you have a base computer code that cannot be tampered with, you can trust it. >From that point on, you can use digital signatures to build the chain of trust. Normally digital signatures would examine the binary, ensure the signature matches, and then run the code contained in it. It is vital that the private key used to sign binaries cannot be found on the local machine, otherwise an malicious user could use it to sign malicious code, and therefore break the trust. The binary files therefore must be signed on a separate computer, that is trusted and protected from malicious users. There is one known use case where the normal digital signature checks will not work and this is the Hibernate file. The files were digitally checked when loaded into a previously running machine. The state of the machine was then saved to a file. The problem is how to check the hibernate file has not been tampered with in the interim. As explained above, we cannot store a private key on the local machine, so some other method for checking that the hibernate file has not been tampered with is required. I would suggest the fix for this problem is working out a way to check the signature of binary files, while in RAM, or even on a running machine. This is the format that the hibernate file is, it is basically a RAM image. When starting a hibernate image, the file would have to be scanned and digital signature checked that all the executable code in the hibernate image was sourced from correctly digitally signed binaries. In fact, this last point, if done correctly, could replace virus scanners. We would then have a system that rather than scan for viruses, it instead scans for "tampering". Remaining problems: 1) deciding who you trust, and from that, which digital signatures/certificates you trust. 2) Handling compromised or expired signatures/certificates. For 2, if the signatures are attached in each binary file, in order to distribute a new set of signatures, you would have to re-distribute all the binary files. Not a good idea due to download size. I would therefore suggest that the signatures are distributed separately from the binary files, so that you can change the signatures without having to redistribute all the binary files. Summary: 1) The BIOS code and the certificate it uses to check subsequently loaded binaries should only be changeable by a user local to the machine or not changeable at all without changing hardware. For example, on some ARM based mobile phones, the BIOS and certificate it uses are in a ROM, so not changeable at all. It then uses a multi stage boot loader, with each stage providing for a different certificate to be used to the next stage. This then permits the certificates that are used to sign the Linux kernel to be changed without having to change the certificate in the ROM. For Secure boot for Linux, the BIOS and certificate should probably be controlled by the user who controls the physical access to his machine. Then multi stage boot loaders can be used to introduce a chain to trust to trust other certificates, such as the debian or redhat or Microsoft ones, if the user chooses to trust them. With the user using their own BIOS certificate, it is very unlikely for the remote malicious user to obtain the private key and thus compromise the security of the system. 2) When "tamper" is detected, the system should revert to a stable safe state. This probably means, prevent the system booting, and present the local user with the evidence of tampering. Letting the user choose the next step. On 7 November 2012 14:55, Matthew Garrett wrote: > On Wed, Nov 07, 2012 at 09:19:35AM +0100, Olivier Galibert wrote: >> On Tue, Nov 6, 2012 at 11:47 PM, Matthew Garrett wrote: >> >> > Sure, and scripts run as root can wipe your files too. That's really not >> > what this is all about. >> >> What it is about then? What is secure boot supposed to do for the owner of >> the computer in a linux context? I've not been able to understand it >> through this discussion. > > It provides a chain of trust that allows you to ensure that a platform > boots a trusted kernel. That's a pre-requisite for implementing any kind > of
Re: [RFC] Second attempt at kernel secure boot support
Hi, The basis for any secure boot is a way to detect that the system has been tampered with or not. Tamper Evidence. There are two main vectors for a system to be tampered with. Someone local to the machine and remote users who can access the machine across a network interface. (this includes the local user installing a program from a remote source) You have a fair chance of protecting via physical means (Locked rooms, Background checks on users etc.) of preventing a user with malicious intent to access the local machine. The first thing a computer does when switched on is run its first code instructions. Commonly referred to as the BIOS. It would therefore be a requirement to ensure that the BIOS cannot be tampered with via any other method apart from physically located at the machine. Once you have a base computer code that cannot be tampered with, you can trust it. From that point on, you can use digital signatures to build the chain of trust. Normally digital signatures would examine the binary, ensure the signature matches, and then run the code contained in it. It is vital that the private key used to sign binaries cannot be found on the local machine, otherwise an malicious user could use it to sign malicious code, and therefore break the trust. The binary files therefore must be signed on a separate computer, that is trusted and protected from malicious users. There is one known use case where the normal digital signature checks will not work and this is the Hibernate file. The files were digitally checked when loaded into a previously running machine. The state of the machine was then saved to a file. The problem is how to check the hibernate file has not been tampered with in the interim. As explained above, we cannot store a private key on the local machine, so some other method for checking that the hibernate file has not been tampered with is required. I would suggest the fix for this problem is working out a way to check the signature of binary files, while in RAM, or even on a running machine. This is the format that the hibernate file is, it is basically a RAM image. When starting a hibernate image, the file would have to be scanned and digital signature checked that all the executable code in the hibernate image was sourced from correctly digitally signed binaries. In fact, this last point, if done correctly, could replace virus scanners. We would then have a system that rather than scan for viruses, it instead scans for tampering. Remaining problems: 1) deciding who you trust, and from that, which digital signatures/certificates you trust. 2) Handling compromised or expired signatures/certificates. For 2, if the signatures are attached in each binary file, in order to distribute a new set of signatures, you would have to re-distribute all the binary files. Not a good idea due to download size. I would therefore suggest that the signatures are distributed separately from the binary files, so that you can change the signatures without having to redistribute all the binary files. Summary: 1) The BIOS code and the certificate it uses to check subsequently loaded binaries should only be changeable by a user local to the machine or not changeable at all without changing hardware. For example, on some ARM based mobile phones, the BIOS and certificate it uses are in a ROM, so not changeable at all. It then uses a multi stage boot loader, with each stage providing for a different certificate to be used to the next stage. This then permits the certificates that are used to sign the Linux kernel to be changed without having to change the certificate in the ROM. For Secure boot for Linux, the BIOS and certificate should probably be controlled by the user who controls the physical access to his machine. Then multi stage boot loaders can be used to introduce a chain to trust to trust other certificates, such as the debian or redhat or Microsoft ones, if the user chooses to trust them. With the user using their own BIOS certificate, it is very unlikely for the remote malicious user to obtain the private key and thus compromise the security of the system. 2) When tamper is detected, the system should revert to a stable safe state. This probably means, prevent the system booting, and present the local user with the evidence of tampering. Letting the user choose the next step. On 7 November 2012 14:55, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Nov 07, 2012 at 09:19:35AM +0100, Olivier Galibert wrote: On Tue, Nov 6, 2012 at 11:47 PM, Matthew Garrett mj...@srcf.ucam.orgwrote: Sure, and scripts run as root can wipe your files too. That's really not what this is all about. What it is about then? What is secure boot supposed to do for the owner of the computer in a linux context? I've not been able to understand it through this discussion. It provides a chain of trust that allows you to ensure that a platform boots a trusted kernel. That's a pre-requisite for implementing any
Re: [RFC] Second attempt at kernel secure boot support
You have a fair chance of protecting via physical means (Locked rooms, Background checks on users etc.) of preventing a user with malicious intent to access the local machine. So called secure boot doesn't deal with any kind of physical access, which also means its useless if a device is lost and returned and you don't know if it was in the hands of a third party. The first thing a computer does when switched on is run its first code instructions. Commonly referred to as the BIOS. A good deal more complicated than that. However the signing in hardware and early boot up on a lot of devices already goes as far as the BIOS if the system has BIOS or EFI if it doesn't. You also have all the devices to deal with. Normally digital signatures would examine the binary, ensure the signature matches, and then run the code contained in it. No - it's a good deal more complicated than that too. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Wed, Nov 07, 2012 at 09:19:35AM +0100, Olivier Galibert wrote: > On Tue, Nov 6, 2012 at 11:47 PM, Matthew Garrett wrote: > > > Sure, and scripts run as root can wipe your files too. That's really not > > what this is all about. > > What it is about then? What is secure boot supposed to do for the owner of > the computer in a linux context? I've not been able to understand it > through this discussion. It provides a chain of trust that allows you to ensure that a platform boots a trusted kernel. That's a pre-requisite for implementing any kind of fully trusted platform, but it's not sufficient in itself. One of those additional requirements is ensuring that the kernel *stays* trusted - in the past an attacker could just replace the kernel on disk and so there was little incentive to engage in more subtle attacks, but now that's impossible we need to care about them. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Wed, Nov 07, 2012 at 09:19:35AM +0100, Olivier Galibert wrote: On Tue, Nov 6, 2012 at 11:47 PM, Matthew Garrett mj...@srcf.ucam.orgwrote: Sure, and scripts run as root can wipe your files too. That's really not what this is all about. What it is about then? What is secure boot supposed to do for the owner of the computer in a linux context? I've not been able to understand it through this discussion. It provides a chain of trust that allows you to ensure that a platform boots a trusted kernel. That's a pre-requisite for implementing any kind of fully trusted platform, but it's not sufficient in itself. One of those additional requirements is ensuring that the kernel *stays* trusted - in the past an attacker could just replace the kernel on disk and so there was little incentive to engage in more subtle attacks, but now that's impossible we need to care about them. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Sure, and scripts run as root can wipe your files too. That's really not what this is all about. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Tue, 06 Nov 2012 16:55:25 -0500 Matthew Garrett wrote: > I'm not sure why you think that Fedora PXE installs will automatically wipe > disks - they'll do whatever Kickstart tells them to do. The only thing > relevant to secure boot here is that you need a signed bootloader, just like > when you book off CD. They'll do whatever the kickstart file says - which means for any untrusted distribution path like PXE your kickstart file had better be signed too -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
It protects against certain classes of compromise. It doesn't prevent rogue software damaging your system - anyone who gets root (and so could reconfigure your boot order) could just rm -rf / anyway. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
* Matthew Garrett: > I'm not sure why you think that Fedora PXE installs will > automatically wipe disks - they'll do whatever Kickstart tells them > to do. Or what the referenced initrd contains (which is not signed, for obvious reasons). The point is that "the bootloader is signed by Fedora" does not translate to "I can run this without worries". I'm not sure if anybody has made promises in this direction. But lack of a "do no harm" rule (which would have to prevent certain forms of unattended installation for sure) means that we do not get that many benefits out of Secure Boot. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
I'm not sure why you think that Fedora PXE installs will automatically wipe disks - they'll do whatever Kickstart tells them to do. The only thing relevant to secure boot here is that you need a signed bootloader, just like when you book off CD. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
* Chris Friesen: > On 11/06/2012 01:56 AM, Florian Weimer wrote: > >> Personally, I think the only way out of this mess is to teach users >> how to disable Secure Boot. > > If you're going to go that far, why not just get them to install a > RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead? Behind that key, considerable infrastructure is needed, and the challenges are not purely technical. I don't expect many such keys as a result. > Secure boot does arguably solve a class of problems, so it seems a bit > odd to recommend just throwing it out entirely. I have never seen a Linux system with a compromised boot path. Surely they exist out there, but they are rare. It's also relatively simple to detect such a compromise on disk, from the outside. Secure Boot doesn't even allow you to safely boot from PXE because Fedora's shim will automatically load an initrd which wipes all your disks. (Safe booting from network would be a compelling feature, but it's not in the focus of Secure Boot; that's client-only technology at the moment.) Some side effects, such as the end of proprietary kernel modules, may be desirable. But others are not, like missing hibernate support (or perhaps even X). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Tue, 6 Nov 2012, Chris Friesen wrote: > > Personally, I think the only way out of this mess is to teach users > > how to disable Secure Boot. > > If you're going to go that far, why not just get them to install a RedHat (or > SuSE, or Ubuntu, or whoever) key and use that instead? You always need to keep in mind the possibility of the key being revoked. > Secure boot does arguably solve a class of problems, so it seems a bit odd to > recommend just throwing it out entirely. Not really. It doesn't solve the the most usual attack vector used (i.e. exploiting the bug in the kernel ... and that's independent of the OS we are talking about). Just because it contains "secure" in its name, doesn't really make it a proper security solution. It should rather be called "vendor lock-in boot", or something like that. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On 11/06/2012 01:56 AM, Florian Weimer wrote: Personally, I think the only way out of this mess is to teach users how to disable Secure Boot. If you're going to go that far, why not just get them to install a RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead? Secure boot does arguably solve a class of problems, so it seems a bit odd to recommend just throwing it out entirely. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Tue, Nov 06, 2012 at 09:12:17AM +, Alan Cox wrote: > - is it worth Red Hat doing - that's up to Red Hat's business managers > > - is it worth merging into the kernel - that's not > > The capability bit is small and clean the rest of it is beginning to look > far too ugly for upstream right now. Not to say it might not end up small > and clean in the end. I absolutely agree - the code has to be good enough to be accepted upstream and I've no objection to being told that better implementations must be produced. I do object to being told that there's no point in trying to find an acceptable implementation. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Tue, Nov 06, 2012 at 01:51:15PM +0100, Jiri Kosina wrote: > On Wed, 31 Oct 2012, Matthew Garrett wrote: > > shim generates a public and private key. > > It seems to me that this brings quite a huge delay into the boot process > both for "regular" and resume cases (as shim has no way to know what is > going to happen next). Mostly because obtaining enough entropy is > generally very difficult when we have just shim running, right? pseudorandom keys should be sufficient here. It's intended to deal with the case of an automated attack rather than a deliberate effort to break into a given user's system. > > It hands the kernel the private key in a boot parameter and stores the > > public key in a boot variable. On suspend, the kernel signs the suspend > > image with that private key and discards it. On the next boot, shim > > generates a new key pair and hands the new private key to the kernel > > along with the old public key. The kernel verifies the suspend image > > before resuming it. The only way to subvert this would be to be able to > > access kernel memory directly, which means the attacker has already won. > > I like this protocol, but after some off-line discussions, I still have > doubts about it. Namely: how do we make sure that there is noone tampering > with the variable? The variable has the same level of security as MOK, so that would be a more attractive target. > - consider securely booted win8 (no Linux installed on that machine, so > the variable for storing public key doesn't exist yet), possibly being > taken over by a malicious user > - he/she creates this secure variable from within the win8 and stores > his/her own public key into it You can't create a non-RT variable from the OS. > - he/she supplies a signed shim (as provided by some Linux distro vendor), > signed kernel (as provided by some Linux distro vendor) and specially > crafted resume image, signed by his/her own private key shim detects that the key has the RT bit set and deletes it. > - he/she reboots the machine in a way that shim+distro kernel+hacker's S4 > image is used to resume And so this step can't happen. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Wed, 31 Oct 2012, Matthew Garrett wrote: > > Reading stored memory image (potentially tampered before reboot) from disk > > is basically DMA-ing arbitrary data over the whole RAM. I am currently not > > able to imagine a scenario how this could be made "secure" (without > > storing private keys to sign the hibernation image on the machine itself > > which, well, doesn't sound secure either). > > shim generates a public and private key. It seems to me that this brings quite a huge delay into the boot process both for "regular" and resume cases (as shim has no way to know what is going to happen next). Mostly because obtaining enough entropy is generally very difficult when we have just shim running, right? > It hands the kernel the private key in a boot parameter and stores the > public key in a boot variable. On suspend, the kernel signs the suspend > image with that private key and discards it. On the next boot, shim > generates a new key pair and hands the new private key to the kernel > along with the old public key. The kernel verifies the suspend image > before resuming it. The only way to subvert this would be to be able to > access kernel memory directly, which means the attacker has already won. I like this protocol, but after some off-line discussions, I still have doubts about it. Namely: how do we make sure that there is noone tampering with the variable? Obvious step towards solving this is making the variable inaccessible after ExitBootServices() has been called (by not setting runtime access flag on it). Now how about this scenario: - consider securely booted win8 (no Linux installed on that machine, so the variable for storing public key doesn't exist yet), possibly being taken over by a malicious user - he/she creates this secure variable from within the win8 and stores his/her own public key into it - he/she supplies a signed shim (as provided by some Linux distro vendor), signed kernel (as provided by some Linux distro vendor) and specially crafted resume image, signed by his/her own private key - he/she reboots the machine in a way that shim+distro kernel+hacker's S4 image is used to resume - distro kernel verifies the signature of the S4 image against the attacker's public key stored in the variable; the signature is OK - he/she has won, as he has managed to run an arbitrary kernel code (stored in the S4 image) in a trusted mode No? Basically, once the machine is already populated with the "secure" version of Linux, this can't happen, as we will (as far as I understand) set the variable for storing the public key in a way that it can't be accessed from runtime environment. But how can we prevent it being *created* before the machine is ever touched by Linux? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Tue, 6 Nov 2012 03:53:52 + Matthew Garrett wrote: > On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > > > For automated installs you don't have to satisfy me. Feel free to > > deliver a lousy solution to your users. Just don't use your arbitrary > > design decisions to justify your kernel patches. > > My kernel patches are justified by genuine user requirements. So are lots of patches tht don't go in because they are too ugly or too invasive or two special case for mainstream. There are two discussions here - is it worth Red Hat doing - that's up to Red Hat's business managers - is it worth merging into the kernel - that's not The capability bit is small and clean the rest of it is beginning to look far too ugly for upstream right now. Not to say it might not end up small and clean in the end. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Tue, 06 Nov 2012 03:12:19 +, Matthew Garrett said: > On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: > > You have it backwards. The conclusion here is that having a case where > > a non-interactive install is possible is not a given. > > I deal with customers who perform non-interactive installs. The fact > that you don't care about that use case is entirely irrelevant to me, > because you're not the person that I am obliged to satisfy. You *do* realize that the fact you have some set of customers who perform non-interactive installs does *not* imply that being able to do so is a given, right? The fact it is available and doable for your customers does *not* mean it's available and doable in general. There's a big difference between "the design has to deal with the fact that some customers can do this on some subsets of hardware" and "the design is free to assume that this is doable". pgppwjMUVeMFW.pgp Description: PGP signature
Re: [RFC] Second attempt at kernel secure boot support
On Tue, 06 Nov 2012 03:12:19 +, Matthew Garrett said: On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: You have it backwards. The conclusion here is that having a case where a non-interactive install is possible is not a given. I deal with customers who perform non-interactive installs. The fact that you don't care about that use case is entirely irrelevant to me, because you're not the person that I am obliged to satisfy. You *do* realize that the fact you have some set of customers who perform non-interactive installs does *not* imply that being able to do so is a given, right? The fact it is available and doable for your customers does *not* mean it's available and doable in general. There's a big difference between the design has to deal with the fact that some customers can do this on some subsets of hardware and the design is free to assume that this is doable. pgppwjMUVeMFW.pgp Description: PGP signature
Re: [RFC] Second attempt at kernel secure boot support
On Tue, 6 Nov 2012 03:53:52 + Matthew Garrett mj...@srcf.ucam.org wrote: On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: For automated installs you don't have to satisfy me. Feel free to deliver a lousy solution to your users. Just don't use your arbitrary design decisions to justify your kernel patches. My kernel patches are justified by genuine user requirements. So are lots of patches tht don't go in because they are too ugly or too invasive or two special case for mainstream. There are two discussions here - is it worth Red Hat doing - that's up to Red Hat's business managers - is it worth merging into the kernel - that's not The capability bit is small and clean the rest of it is beginning to look far too ugly for upstream right now. Not to say it might not end up small and clean in the end. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Wed, 31 Oct 2012, Matthew Garrett wrote: Reading stored memory image (potentially tampered before reboot) from disk is basically DMA-ing arbitrary data over the whole RAM. I am currently not able to imagine a scenario how this could be made secure (without storing private keys to sign the hibernation image on the machine itself which, well, doesn't sound secure either). shim generates a public and private key. It seems to me that this brings quite a huge delay into the boot process both for regular and resume cases (as shim has no way to know what is going to happen next). Mostly because obtaining enough entropy is generally very difficult when we have just shim running, right? It hands the kernel the private key in a boot parameter and stores the public key in a boot variable. On suspend, the kernel signs the suspend image with that private key and discards it. On the next boot, shim generates a new key pair and hands the new private key to the kernel along with the old public key. The kernel verifies the suspend image before resuming it. The only way to subvert this would be to be able to access kernel memory directly, which means the attacker has already won. I like this protocol, but after some off-line discussions, I still have doubts about it. Namely: how do we make sure that there is noone tampering with the variable? Obvious step towards solving this is making the variable inaccessible after ExitBootServices() has been called (by not setting runtime access flag on it). Now how about this scenario: - consider securely booted win8 (no Linux installed on that machine, so the variable for storing public key doesn't exist yet), possibly being taken over by a malicious user - he/she creates this secure variable from within the win8 and stores his/her own public key into it - he/she supplies a signed shim (as provided by some Linux distro vendor), signed kernel (as provided by some Linux distro vendor) and specially crafted resume image, signed by his/her own private key - he/she reboots the machine in a way that shim+distro kernel+hacker's S4 image is used to resume - distro kernel verifies the signature of the S4 image against the attacker's public key stored in the variable; the signature is OK - he/she has won, as he has managed to run an arbitrary kernel code (stored in the S4 image) in a trusted mode No? Basically, once the machine is already populated with the secure version of Linux, this can't happen, as we will (as far as I understand) set the variable for storing the public key in a way that it can't be accessed from runtime environment. But how can we prevent it being *created* before the machine is ever touched by Linux? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Tue, Nov 06, 2012 at 01:51:15PM +0100, Jiri Kosina wrote: On Wed, 31 Oct 2012, Matthew Garrett wrote: shim generates a public and private key. It seems to me that this brings quite a huge delay into the boot process both for regular and resume cases (as shim has no way to know what is going to happen next). Mostly because obtaining enough entropy is generally very difficult when we have just shim running, right? pseudorandom keys should be sufficient here. It's intended to deal with the case of an automated attack rather than a deliberate effort to break into a given user's system. It hands the kernel the private key in a boot parameter and stores the public key in a boot variable. On suspend, the kernel signs the suspend image with that private key and discards it. On the next boot, shim generates a new key pair and hands the new private key to the kernel along with the old public key. The kernel verifies the suspend image before resuming it. The only way to subvert this would be to be able to access kernel memory directly, which means the attacker has already won. I like this protocol, but after some off-line discussions, I still have doubts about it. Namely: how do we make sure that there is noone tampering with the variable? The variable has the same level of security as MOK, so that would be a more attractive target. - consider securely booted win8 (no Linux installed on that machine, so the variable for storing public key doesn't exist yet), possibly being taken over by a malicious user - he/she creates this secure variable from within the win8 and stores his/her own public key into it You can't create a non-RT variable from the OS. - he/she supplies a signed shim (as provided by some Linux distro vendor), signed kernel (as provided by some Linux distro vendor) and specially crafted resume image, signed by his/her own private key shim detects that the key has the RT bit set and deletes it. - he/she reboots the machine in a way that shim+distro kernel+hacker's S4 image is used to resume And so this step can't happen. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Tue, Nov 06, 2012 at 09:12:17AM +, Alan Cox wrote: - is it worth Red Hat doing - that's up to Red Hat's business managers - is it worth merging into the kernel - that's not The capability bit is small and clean the rest of it is beginning to look far too ugly for upstream right now. Not to say it might not end up small and clean in the end. I absolutely agree - the code has to be good enough to be accepted upstream and I've no objection to being told that better implementations must be produced. I do object to being told that there's no point in trying to find an acceptable implementation. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On 11/06/2012 01:56 AM, Florian Weimer wrote: Personally, I think the only way out of this mess is to teach users how to disable Secure Boot. If you're going to go that far, why not just get them to install a RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead? Secure boot does arguably solve a class of problems, so it seems a bit odd to recommend just throwing it out entirely. Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Tue, 6 Nov 2012, Chris Friesen wrote: Personally, I think the only way out of this mess is to teach users how to disable Secure Boot. If you're going to go that far, why not just get them to install a RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead? You always need to keep in mind the possibility of the key being revoked. Secure boot does arguably solve a class of problems, so it seems a bit odd to recommend just throwing it out entirely. Not really. It doesn't solve the the most usual attack vector used (i.e. exploiting the bug in the kernel ... and that's independent of the OS we are talking about). Just because it contains secure in its name, doesn't really make it a proper security solution. It should rather be called vendor lock-in boot, or something like that. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
* Chris Friesen: On 11/06/2012 01:56 AM, Florian Weimer wrote: Personally, I think the only way out of this mess is to teach users how to disable Secure Boot. If you're going to go that far, why not just get them to install a RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead? Behind that key, considerable infrastructure is needed, and the challenges are not purely technical. I don't expect many such keys as a result. Secure boot does arguably solve a class of problems, so it seems a bit odd to recommend just throwing it out entirely. I have never seen a Linux system with a compromised boot path. Surely they exist out there, but they are rare. It's also relatively simple to detect such a compromise on disk, from the outside. Secure Boot doesn't even allow you to safely boot from PXE because Fedora's shim will automatically load an initrd which wipes all your disks. (Safe booting from network would be a compelling feature, but it's not in the focus of Secure Boot; that's client-only technology at the moment.) Some side effects, such as the end of proprietary kernel modules, may be desirable. But others are not, like missing hibernate support (or perhaps even X). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
I'm not sure why you think that Fedora PXE installs will automatically wipe disks - they'll do whatever Kickstart tells them to do. The only thing relevant to secure boot here is that you need a signed bootloader, just like when you book off CD. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
* Matthew Garrett: I'm not sure why you think that Fedora PXE installs will automatically wipe disks - they'll do whatever Kickstart tells them to do. Or what the referenced initrd contains (which is not signed, for obvious reasons). The point is that the bootloader is signed by Fedora does not translate to I can run this without worries. I'm not sure if anybody has made promises in this direction. But lack of a do no harm rule (which would have to prevent certain forms of unattended installation for sure) means that we do not get that many benefits out of Secure Boot. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
It protects against certain classes of compromise. It doesn't prevent rogue software damaging your system - anyone who gets root (and so could reconfigure your boot order) could just rm -rf / anyway. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Tue, 06 Nov 2012 16:55:25 -0500 Matthew Garrett mj...@srcf.ucam.org wrote: I'm not sure why you think that Fedora PXE installs will automatically wipe disks - they'll do whatever Kickstart tells them to do. The only thing relevant to secure boot here is that you need a signed bootloader, just like when you book off CD. They'll do whatever the kickstart file says - which means for any untrusted distribution path like PXE your kickstart file had better be signed too -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Sure, and scripts run as root can wipe your files too. That's really not what this is all about. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
* Eric W. Biederman: > If windows is not present on a system linux can not be used to boot a > compromised version of windows without user knowledge because windows is > not present. Interesting idea. Unfortunately, it is very hard to detect reliably that Windows is not present from the bootloader, so it's not possible to use this approach to simplify matters. > If windows is present on a system then to install linux a user must be > present and push buttons to get the system to boot off of install media. That's not necessarily true. > If a user is present a user presence test may be used to prevent a > bootloader signed with Microsoft's key from booting linux without the > users consent, and thus prevent Linux from attacking windows users. As already explained, I don't think that user presence accomplishes anything. You need informed consent, and it's impossible to cram that on a 80x25 screen. You also need to make sure that you aren't unnecessarily alarmist. We don't want a "Linux may harm your computer" warning. > Therefore preventing the revokation of a signature with Microsoft's > signature from your bootloader does not justify elaborate kernel > modifications to prevent the booting a compromised version of windows. I don't like this approach, either. > Furthermore no matter how hard we try with current techniques there will > eventually be kernel bugs that allow attackers to inject code into the > kernel. So attempting to fully close that attack vector is > questionable. I suspect we'd need to revoke old binaries after a grace period. I guess the Microsoft approach is to revoke only what's actually used for attacks, but that leads to a lot of unpredictability for our users. It's also annoying if we figure out after release that we have to disable additional kernel functionality because it can be used to compromise the boot path. Users will not like that, especially if they do not use Windows at all. Personally, I think the only way out of this mess is to teach users how to disable Secure Boot. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 09:19:46PM -0800, Eric W. Biederman wrote: > Matthew Garrett writes: > > > On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > > > >> For automated installs you don't have to satisfy me. Feel free to > >> deliver a lousy solution to your users. Just don't use your arbitrary > >> design decisions to justify your kernel patches. > > > > My kernel patches are justified by genuine user requirements. > > Hogwash. You keep using that word, which is unfortunate. > If windows is not present on a system linux can not be used to boot a > compromised version of windows without user knowledge because windows is > not present. Correct. > If windows is present on a system then to install linux a user must be > present and push buttons to get the system to boot off of install media. Incorrect. UEFI boot priorities can be set without physical user interaction. > If a user is present a user presence test may be used to prevent a > bootloader signed with Microsoft's key from booting linux without the > users consent, and thus prevent Linux from attacking windows users. Correct, but precludes the kind of automated installs that I know real people do. The keys a machine carries don't vary depending on whether it shipped with Windows or not, so it's not possible to differentiate between the "shipped with Windows" and "shipped without Windows" cases when determining security models. > Therefore preventing the revokation of a signature with Microsoft's > signature from your bootloader does not justify elaborate kernel > modifications to prevent the booting a compromised version of windows. That's a stretch. Bored now. You're adding nothing new to anyone's understanding of the problem, and I'm just saying the same thing I've been saying for months, so I don't see any purpose in discussing this with you further. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett writes: > On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > >> For automated installs you don't have to satisfy me. Feel free to >> deliver a lousy solution to your users. Just don't use your arbitrary >> design decisions to justify your kernel patches. > > My kernel patches are justified by genuine user requirements. Hogwash. If windows is not present on a system linux can not be used to boot a compromised version of windows without user knowledge because windows is not present. If windows is present on a system then to install linux a user must be present and push buttons to get the system to boot off of install media. If a user is present a user presence test may be used to prevent a bootloader signed with Microsoft's key from booting linux without the users consent, and thus prevent Linux from attacking windows users. Therefore preventing the revokation of a signature with Microsoft's signature from your bootloader does not justify elaborate kernel modifications to prevent the booting a compromised version of windows. Furthermore no matter how hard we try with current techniques there will eventually be kernel bugs that allow attackers to inject code into the kernel. So attempting to fully close that attack vector is questionable. > If you > don't feel that there's any requirement for the kernel to satisfy the > people who use it, you're free to ignore those patches. I feel allowing the kernel to be hacked to bits and decend into an unmaintainable mess does not serve the users who use the kernel, and to prevent that technically poor patches should be rejected. This helps prevent non-technical considerations from justifying technically poor decisions. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > For automated installs you don't have to satisfy me. Feel free to > deliver a lousy solution to your users. Just don't use your arbitrary > design decisions to justify your kernel patches. My kernel patches are justified by genuine user requirements. If you don't feel that there's any requirement for the kernel to satisfy the people who use it, you're free to ignore those patches. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett writes: > On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: >> Matthew Garrett writes: >> >> > On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: >> >> Matthew Garrett writes: >> >> > No, in the general case the system will do that once it fails to find a >> >> > bootable OS on the drive. >> >> >> >> In the general case there will be a bootable OS on the drive. >> > >> > That's in no way a given. >> >> You have it backwards. The conclusion here is that having a case where >> a non-interactive install is possible is not a given. > > I deal with customers who perform non-interactive installs. The fact > that you don't care about that use case is entirely irrelevant to me, > because you're not the person that I am obliged to satisfy. I have spent what feels like half my life doing automatic installs. I care a lot and I understand the requirements. I also see through misstatements about reality used to justify stupid design decisions. For automated installs you don't have to satisfy me. Feel free to deliver a lousy solution to your users. Just don't use your arbitrary design decisions to justify your kernel patches. Non-interactive installs do not justify removing all trust from the root user of a system, disabling suspend to disk and completely rewriting kexec for the simple expedient removing a couple of lines of code from your bootloader. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: > Matthew Garrett writes: > > > On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: > >> Matthew Garrett writes: > >> > No, in the general case the system will do that once it fails to find a > >> > bootable OS on the drive. > >> > >> In the general case there will be a bootable OS on the drive. > > > > That's in no way a given. > > You have it backwards. The conclusion here is that having a case where > a non-interactive install is possible is not a given. I deal with customers who perform non-interactive installs. The fact that you don't care about that use case is entirely irrelevant to me, because you're not the person that I am obliged to satisfy. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett writes: > On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: >> Matthew Garrett writes: >> > No, in the general case the system will do that once it fails to find a >> > bootable OS on the drive. >> >> In the general case there will be a bootable OS on the drive. > > That's in no way a given. You have it backwards. The conclusion here is that having a case where a non-interactive install is possible is not a given. Therefore inflicting the entire rest of the ecosystem with requirements that only exist in the union of the requirements for non-interactive installs and installs on a machine with an existing machine does not make sense. In situations where a non-interactive install is interesting. Aka an empty boot disk it is not interesting to guard against. In situations where interaction happens is where windows may already exists and so spoofing windows is a design consideration and and a user presence test does not break the design. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
* James Bottomley: > Right, but what I'm telling you is that by deciding to allow automatic > first boot, you're causing the windows attack vector problem. You could > easily do a present user test only on first boot which would eliminate > it. Apparently, the warning will look like this: WARNING: This Binary is unsigned Are you sure you wish to run an unsigned binary in a secure environment? To avoid this question in future place the platform into setup mode See http://www.linuxfoundation.org/uefi-setup-mode And reboot. I'm not convinced this will work because users will confirm their presence to get back into the system. We expect GNU/Linux users to do it, why wouldn't Windows users? (And what harm can an unsigned binary do to a "secure environment", anyway? If it's adversely affected, it can't be that secure, can it?) And what's the backup plan if users use this to boot into compromised Windows systems? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: > Matthew Garrett writes: > > No, in the general case the system will do that once it fails to find a > > bootable OS on the drive. > > In the general case there will be a bootable OS on the drive. That's in no way a given. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett writes: > On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote: >> "H. Peter Anvin" writes: >> > >> > That is a hugely different thing from needing a console. >> >> Not at all. >> >> In the general case user intereaction is required to tell the system to >> boot off of your choosen boot media instead of the local hard drive. > > No, in the general case the system will do that once it fails to find a > bootable OS on the drive. In the general case there will be a bootable OS on the drive. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 09:37:18AM -0600, Chris Friesen wrote: > On 11/05/2012 09:31 AM, Jiri Kosina wrote: > > >I had a naive idea of just putting in-kernel verification of a complete > >ELF binary passed to kernel by userspace, and if the signature matches, > >jumping to it. > >Would work for elf-x86_64 nicely I guess, but we'd lose a lot of other > >functionality currently being provided by kexec-tools. > > > >Bah. This is a real pandora's box. > > Would it be so bad to statically link kexec? statically linking and signing /sbin/kexec is sounding most reasonable so far, to me. Even if we do that, there are few more issues queries though. - Do we still need a new system call? - Who does the kernel signature verification. Is it /sbin/kexec or kernel should do that. - If kernel is supposed to do kernel signature verification, how the signed bzImage is passed to kernel with existing system call. Are certificates passed in separate segments. How does kernel differentiate between segmets etc. - Does signed /sbin/kexec means that it can load any other segments like elf header, boot_params and no signature verifiation is needed. If we move all the kernel signatuer verification part into /sbin/kexec, then we should possibly be able to use existing system call. But I don't know what kind of crypto support we shall have to build into kexec-tools statically and how much help we can get from static libraries and how much work it is. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
At Thu, 1 Nov 2012 13:18:49 +, Alan Cox wrote: > > > I think it make sense because the private key is still protected by > > signer. Any hacker who modified firmware is still need use private key > > to generate signature, but hacker's private key is impossible to match > > with the public key that kernel used to verify firmware. > > > > And, I afraid we have no choice that we need put the firmware signature > > in a separate file. Contacting with those company's legal department > > will be very time-consuming, and I am not sure all company will agree we > > put the signature with firmware then distribute. > > Then you'd better stop storing it on disk because your disk drive is FEC > encoding it and adding a CRC 8) > > It does want checking with a lawyer but my understanding is that if you > have a file which is a package that contains the firmware and a signature > then there is not generally a problem, any more than putting it in an RPM > file - it's packaging/aggregation. This should be referred to the Linux > Foundation folks perhaps - no point designing something badly to work > around a non existant issue. > > Also the interface needs to consider that a lot of device firmware is > already signed. Nobody notices because they don't ever try and do their > own thus many drivers don't need extra signatures in fact. Besides the legal concern, embedding the signature into the firmware makes the file incompatible with old kernel that has no support for signed firmware. That's the reason I put the files into a new location in my test patch, /lib/firmware/signed/. Having a separate signature file would make this easier. I cooked again quickly firmware loader code for the separate signature files. I'm going to send a series of test patches. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On 11/05/2012 09:31 AM, Jiri Kosina wrote: I had a naive idea of just putting in-kernel verification of a complete ELF binary passed to kernel by userspace, and if the signature matches, jumping to it. Would work for elf-x86_64 nicely I guess, but we'd lose a lot of other functionality currently being provided by kexec-tools. Bah. This is a real pandora's box. Would it be so bad to statically link kexec? Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, 5 Nov 2012, Jiri Kosina wrote: > Do I understand you correctly that by the 'glue' stuff you actually mean > the division of the kexec image into segments? > > Of course, when we are dividing the image into segments and then passing > those individually (even more so if some transformations are performed on > those segments, which I don't know whether that's the case or not), then > we can't do any signature verification of the image any more. > > But I still don't fully understand what is so magical about taking the > kernel image as is, and passing the whole lot to the running kernel as-is, > allowing for signature verification. > > Yes, it couldn't be sys_kexec_load(), as that would be ABI breakage, so > it'd mean sys_kexec_raw_load(), or whatever ... but I fail to see why that > would be problem in principle. > > If you can point me to the code where all the magic that prevents this > easy handling is happening, I'd appreciate it. OK, so after wandering through kexec-tools sources for a while, I am starting to get your point. I wasn't actually aware of the fact that it supports such a wide variety of binary formats etc. (multiboot, nbi, etc). I had a naive idea of just putting in-kernel verification of a complete ELF binary passed to kernel by userspace, and if the signature matches, jumping to it. Would work for elf-x86_64 nicely I guess, but we'd lose a lot of other functionality currently being provided by kexec-tools. Bah. This is a real pandora's box. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun, 4 Nov 2012, Eric W. Biederman wrote: > > Why is "when kernel has been securely booted, the in-kernel kexec > > mechanism has to verify the signature of the supplied image before > > kexecing it" not enough? (basically the same thing we are doing for signed > > modules already). > > For modules the only untrusted part of their environment are the command > line parameters, and several of those have already been noted for > needing to be ignored in a non-trusted root scenario. > > For kexec there is a bunch of glue code and data that takes care of > transitioning from the environment provided by kexec and the environment > that the linux kernel or memtest86 or whatever we are booting is > expecting. > > Figuring out what glue code and data we need and supplying that glue > code and data is what kexec-tools does. The situation is a bit like > dealing with the modules before most of the work of insmod was moved > into the kernel. > > For kexec-tools it is desirable to have glue layers outside of the > kernel because every boot system in existence has a different set of > parameter passing rules. > > So signing in the kernel gets us into how do we sign the glue code and > how dow we verify the glue code will jump to our signed and verified > kernel image. Do I understand you correctly that by the 'glue' stuff you actually mean the division of the kexec image into segments? Of course, when we are dividing the image into segments and then passing those individually (even more so if some transformations are performed on those segments, which I don't know whether that's the case or not), then we can't do any signature verification of the image any more. But I still don't fully understand what is so magical about taking the kernel image as is, and passing the whole lot to the running kernel as-is, allowing for signature verification. Yes, it couldn't be sys_kexec_load(), as that would be ABI breakage, so it'd mean sys_kexec_raw_load(), or whatever ... but I fail to see why that would be problem in principle. If you can point me to the code where all the magic that prevents this easy handling is happening, I'd appreciate it. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 01:44:36PM +, Alan Cox wrote: > On Mon, 5 Nov 2012 12:38:58 + > Matthew Garrett wrote: > > No, in the general case the system will do that once it fails to find a > > bootable OS on the drive. > > So your "secure" system can be wiped by a random Windows 8 install media. > Ooh thats good stuff 8) Once you've booted trusted code you can change the boot order. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, 5 Nov 2012 12:38:58 + Matthew Garrett wrote: > On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote: > > "H. Peter Anvin" writes: > > > > > > That is a hugely different thing from needing a console. > > > > Not at all. > > > > In the general case user intereaction is required to tell the system to > > boot off of your choosen boot media instead of the local hard drive. > > No, in the general case the system will do that once it fails to find a > bootable OS on the drive. So your "secure" system can be wiped by a random Windows 8 install media. Ooh thats good stuff 8) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote: > "H. Peter Anvin" writes: > > > > That is a hugely different thing from needing a console. > > Not at all. > > In the general case user intereaction is required to tell the system to > boot off of your choosen boot media instead of the local hard drive. No, in the general case the system will do that once it fails to find a bootable OS on the drive. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 09:20:17AM +0100, James Bottomley wrote: > On Sun, 2012-11-04 at 13:52 +, Matthew Garrett wrote: > > You don't get to punt on making the kernel secure by simply asserting > > that some other system can be secure instead. The chain of trust needs > > to go all the way back - if your security model is based on all installs > > needing a physically present end user, all installs need a physically > > present end user. That's not acceptable, so we need a different security > > model. > > I didn't. I advocated a simple security model which you asserted > wouldn't allow unattended installs, so I explained how they could be > done. You've explained that a hypothetical piece of software could handle key provisioning without providing any explanation for how it would be able to do so in a secure manner. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On 11/05/2012 09:50 AM, Eric W. Biederman wrote: > > Facts are always a good thing to assume. > > The fact is the general case does not admit an install without user > interaction. > In the general case, no. However, that is not a good reason to rule out the cases where it *can* be done; especially as vendors are starting to wake up to actual needs of users and of Linux in particular. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
"H. Peter Anvin" writes: > This is not a good thing to assume. A vendor could have an external > button, for example. Facts are always a good thing to assume. The fact is the general case does not admit an install without user interaction. It makes a lot of sense to revisit the working assumptions when for lack of 3 o4 4 lines in the bootloader people are advocating turning gold into lead at the cost of a national banking bailout. Non-interactive installs are very interesting but they only make sense in a very narrow range of cases not on every in every BIOS state on every machine. If the UEFI firmware will let me install a platform key and set ever other firmware setting in my installer, then it is a good starting state. The rest of the time there will be some unpredictable inconsistent mess of firmware settings that someone is going to have to go in and fix. Or the install cd will have blown away my existing partitions deleting data I forgot to back up that day. The notion that a non-interactive install is possible in the general case is complete and total hogwash. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun, 2012-11-04 at 13:52 +, Matthew Garrett wrote: > On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote: > > > I've actually had more than enough experience with automated installs > > over my career: they're either done by paying someone or using a > > provisioning system. In either case, they provision a static image and > > boot environment description, including EFI boot services variables, so > > you can provision a default MOK database if you want the ignition image > > not to pause on firstboot. > > And now you've moved the attack vector to a copy of your provisioning > system instead. Well, no, it always exists: a lot of provisioning systems install efi (or previously dos) based agents not linux kernels. However it's a different vector since the efi agents tend to want to PXE boot and contact the image server. > > There is obviously the question of making the provisioning systems > > secure, but it's a separate one from making boot secure. > > You don't get to punt on making the kernel secure by simply asserting > that some other system can be secure instead. The chain of trust needs > to go all the way back - if your security model is based on all installs > needing a physically present end user, all installs need a physically > present end user. That's not acceptable, so we need a different security > model. I didn't. I advocated a simple security model which you asserted wouldn't allow unattended installs, so I explained how they could be done. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun, 2012-11-04 at 13:52 +, Matthew Garrett wrote: On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote: I've actually had more than enough experience with automated installs over my career: they're either done by paying someone or using a provisioning system. In either case, they provision a static image and boot environment description, including EFI boot services variables, so you can provision a default MOK database if you want the ignition image not to pause on firstboot. And now you've moved the attack vector to a copy of your provisioning system instead. Well, no, it always exists: a lot of provisioning systems install efi (or previously dos) based agents not linux kernels. However it's a different vector since the efi agents tend to want to PXE boot and contact the image server. There is obviously the question of making the provisioning systems secure, but it's a separate one from making boot secure. You don't get to punt on making the kernel secure by simply asserting that some other system can be secure instead. The chain of trust needs to go all the way back - if your security model is based on all installs needing a physically present end user, all installs need a physically present end user. That's not acceptable, so we need a different security model. I didn't. I advocated a simple security model which you asserted wouldn't allow unattended installs, so I explained how they could be done. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
H. Peter Anvin h...@zytor.com writes: This is not a good thing to assume. A vendor could have an external button, for example. Facts are always a good thing to assume. The fact is the general case does not admit an install without user interaction. It makes a lot of sense to revisit the working assumptions when for lack of 3 o4 4 lines in the bootloader people are advocating turning gold into lead at the cost of a national banking bailout. Non-interactive installs are very interesting but they only make sense in a very narrow range of cases not on every in every BIOS state on every machine. If the UEFI firmware will let me install a platform key and set ever other firmware setting in my installer, then it is a good starting state. The rest of the time there will be some unpredictable inconsistent mess of firmware settings that someone is going to have to go in and fix. Or the install cd will have blown away my existing partitions deleting data I forgot to back up that day. The notion that a non-interactive install is possible in the general case is complete and total hogwash. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On 11/05/2012 09:50 AM, Eric W. Biederman wrote: Facts are always a good thing to assume. The fact is the general case does not admit an install without user interaction. In the general case, no. However, that is not a good reason to rule out the cases where it *can* be done; especially as vendors are starting to wake up to actual needs of users and of Linux in particular. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 09:20:17AM +0100, James Bottomley wrote: On Sun, 2012-11-04 at 13:52 +, Matthew Garrett wrote: You don't get to punt on making the kernel secure by simply asserting that some other system can be secure instead. The chain of trust needs to go all the way back - if your security model is based on all installs needing a physically present end user, all installs need a physically present end user. That's not acceptable, so we need a different security model. I didn't. I advocated a simple security model which you asserted wouldn't allow unattended installs, so I explained how they could be done. You've explained that a hypothetical piece of software could handle key provisioning without providing any explanation for how it would be able to do so in a secure manner. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote: H. Peter Anvin h...@zytor.com writes: That is a hugely different thing from needing a console. Not at all. In the general case user intereaction is required to tell the system to boot off of your choosen boot media instead of the local hard drive. No, in the general case the system will do that once it fails to find a bootable OS on the drive. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, 5 Nov 2012 12:38:58 + Matthew Garrett mj...@srcf.ucam.org wrote: On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote: H. Peter Anvin h...@zytor.com writes: That is a hugely different thing from needing a console. Not at all. In the general case user intereaction is required to tell the system to boot off of your choosen boot media instead of the local hard drive. No, in the general case the system will do that once it fails to find a bootable OS on the drive. So your secure system can be wiped by a random Windows 8 install media. Ooh thats good stuff 8) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 01:44:36PM +, Alan Cox wrote: On Mon, 5 Nov 2012 12:38:58 + Matthew Garrett mj...@srcf.ucam.org wrote: No, in the general case the system will do that once it fails to find a bootable OS on the drive. So your secure system can be wiped by a random Windows 8 install media. Ooh thats good stuff 8) Once you've booted trusted code you can change the boot order. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun, 4 Nov 2012, Eric W. Biederman wrote: Why is when kernel has been securely booted, the in-kernel kexec mechanism has to verify the signature of the supplied image before kexecing it not enough? (basically the same thing we are doing for signed modules already). For modules the only untrusted part of their environment are the command line parameters, and several of those have already been noted for needing to be ignored in a non-trusted root scenario. For kexec there is a bunch of glue code and data that takes care of transitioning from the environment provided by kexec and the environment that the linux kernel or memtest86 or whatever we are booting is expecting. Figuring out what glue code and data we need and supplying that glue code and data is what kexec-tools does. The situation is a bit like dealing with the modules before most of the work of insmod was moved into the kernel. For kexec-tools it is desirable to have glue layers outside of the kernel because every boot system in existence has a different set of parameter passing rules. So signing in the kernel gets us into how do we sign the glue code and how dow we verify the glue code will jump to our signed and verified kernel image. Do I understand you correctly that by the 'glue' stuff you actually mean the division of the kexec image into segments? Of course, when we are dividing the image into segments and then passing those individually (even more so if some transformations are performed on those segments, which I don't know whether that's the case or not), then we can't do any signature verification of the image any more. But I still don't fully understand what is so magical about taking the kernel image as is, and passing the whole lot to the running kernel as-is, allowing for signature verification. Yes, it couldn't be sys_kexec_load(), as that would be ABI breakage, so it'd mean sys_kexec_raw_load(), or whatever ... but I fail to see why that would be problem in principle. If you can point me to the code where all the magic that prevents this easy handling is happening, I'd appreciate it. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, 5 Nov 2012, Jiri Kosina wrote: Do I understand you correctly that by the 'glue' stuff you actually mean the division of the kexec image into segments? Of course, when we are dividing the image into segments and then passing those individually (even more so if some transformations are performed on those segments, which I don't know whether that's the case or not), then we can't do any signature verification of the image any more. But I still don't fully understand what is so magical about taking the kernel image as is, and passing the whole lot to the running kernel as-is, allowing for signature verification. Yes, it couldn't be sys_kexec_load(), as that would be ABI breakage, so it'd mean sys_kexec_raw_load(), or whatever ... but I fail to see why that would be problem in principle. If you can point me to the code where all the magic that prevents this easy handling is happening, I'd appreciate it. OK, so after wandering through kexec-tools sources for a while, I am starting to get your point. I wasn't actually aware of the fact that it supports such a wide variety of binary formats etc. (multiboot, nbi, etc). I had a naive idea of just putting in-kernel verification of a complete ELF binary passed to kernel by userspace, and if the signature matches, jumping to it. Would work for elf-x86_64 nicely I guess, but we'd lose a lot of other functionality currently being provided by kexec-tools. Bah. This is a real pandora's box. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On 11/05/2012 09:31 AM, Jiri Kosina wrote: I had a naive idea of just putting in-kernel verification of a complete ELF binary passed to kernel by userspace, and if the signature matches, jumping to it. Would work for elf-x86_64 nicely I guess, but we'd lose a lot of other functionality currently being provided by kexec-tools. Bah. This is a real pandora's box. Would it be so bad to statically link kexec? Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
At Thu, 1 Nov 2012 13:18:49 +, Alan Cox wrote: I think it make sense because the private key is still protected by signer. Any hacker who modified firmware is still need use private key to generate signature, but hacker's private key is impossible to match with the public key that kernel used to verify firmware. And, I afraid we have no choice that we need put the firmware signature in a separate file. Contacting with those company's legal department will be very time-consuming, and I am not sure all company will agree we put the signature with firmware then distribute. Then you'd better stop storing it on disk because your disk drive is FEC encoding it and adding a CRC 8) It does want checking with a lawyer but my understanding is that if you have a file which is a package that contains the firmware and a signature then there is not generally a problem, any more than putting it in an RPM file - it's packaging/aggregation. This should be referred to the Linux Foundation folks perhaps - no point designing something badly to work around a non existant issue. Also the interface needs to consider that a lot of device firmware is already signed. Nobody notices because they don't ever try and do their own thus many drivers don't need extra signatures in fact. Besides the legal concern, embedding the signature into the firmware makes the file incompatible with old kernel that has no support for signed firmware. That's the reason I put the files into a new location in my test patch, /lib/firmware/signed/. Having a separate signature file would make this easier. I cooked again quickly firmware loader code for the separate signature files. I'm going to send a series of test patches. thanks, Takashi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 09:37:18AM -0600, Chris Friesen wrote: On 11/05/2012 09:31 AM, Jiri Kosina wrote: I had a naive idea of just putting in-kernel verification of a complete ELF binary passed to kernel by userspace, and if the signature matches, jumping to it. Would work for elf-x86_64 nicely I guess, but we'd lose a lot of other functionality currently being provided by kexec-tools. Bah. This is a real pandora's box. Would it be so bad to statically link kexec? statically linking and signing /sbin/kexec is sounding most reasonable so far, to me. Even if we do that, there are few more issues queries though. - Do we still need a new system call? - Who does the kernel signature verification. Is it /sbin/kexec or kernel should do that. - If kernel is supposed to do kernel signature verification, how the signed bzImage is passed to kernel with existing system call. Are certificates passed in separate segments. How does kernel differentiate between segmets etc. - Does signed /sbin/kexec means that it can load any other segments like elf header, boot_params and no signature verifiation is needed. If we move all the kernel signatuer verification part into /sbin/kexec, then we should possibly be able to use existing system call. But I don't know what kind of crypto support we shall have to build into kexec-tools statically and how much help we can get from static libraries and how much work it is. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett mj...@srcf.ucam.org writes: On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote: H. Peter Anvin h...@zytor.com writes: That is a hugely different thing from needing a console. Not at all. In the general case user intereaction is required to tell the system to boot off of your choosen boot media instead of the local hard drive. No, in the general case the system will do that once it fails to find a bootable OS on the drive. In the general case there will be a bootable OS on the drive. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: Matthew Garrett mj...@srcf.ucam.org writes: No, in the general case the system will do that once it fails to find a bootable OS on the drive. In the general case there will be a bootable OS on the drive. That's in no way a given. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
* James Bottomley: Right, but what I'm telling you is that by deciding to allow automatic first boot, you're causing the windows attack vector problem. You could easily do a present user test only on first boot which would eliminate it. Apparently, the warning will look like this: WARNING: This Binary is unsigned Are you sure you wish to run an unsigned binary in a secure environment? To avoid this question in future place the platform into setup mode See http://www.linuxfoundation.org/uefi-setup-mode And reboot. I'm not convinced this will work because users will confirm their presence to get back into the system. We expect GNU/Linux users to do it, why wouldn't Windows users? (And what harm can an unsigned binary do to a secure environment, anyway? If it's adversely affected, it can't be that secure, can it?) And what's the backup plan if users use this to boot into compromised Windows systems? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett mj...@srcf.ucam.org writes: On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: Matthew Garrett mj...@srcf.ucam.org writes: No, in the general case the system will do that once it fails to find a bootable OS on the drive. In the general case there will be a bootable OS on the drive. That's in no way a given. You have it backwards. The conclusion here is that having a case where a non-interactive install is possible is not a given. Therefore inflicting the entire rest of the ecosystem with requirements that only exist in the union of the requirements for non-interactive installs and installs on a machine with an existing machine does not make sense. In situations where a non-interactive install is interesting. Aka an empty boot disk it is not interesting to guard against. In situations where interaction happens is where windows may already exists and so spoofing windows is a design consideration and and a user presence test does not break the design. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: Matthew Garrett mj...@srcf.ucam.org writes: On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: Matthew Garrett mj...@srcf.ucam.org writes: No, in the general case the system will do that once it fails to find a bootable OS on the drive. In the general case there will be a bootable OS on the drive. That's in no way a given. You have it backwards. The conclusion here is that having a case where a non-interactive install is possible is not a given. I deal with customers who perform non-interactive installs. The fact that you don't care about that use case is entirely irrelevant to me, because you're not the person that I am obliged to satisfy. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett mj...@srcf.ucam.org writes: On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: Matthew Garrett mj...@srcf.ucam.org writes: On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: Matthew Garrett mj...@srcf.ucam.org writes: No, in the general case the system will do that once it fails to find a bootable OS on the drive. In the general case there will be a bootable OS on the drive. That's in no way a given. You have it backwards. The conclusion here is that having a case where a non-interactive install is possible is not a given. I deal with customers who perform non-interactive installs. The fact that you don't care about that use case is entirely irrelevant to me, because you're not the person that I am obliged to satisfy. I have spent what feels like half my life doing automatic installs. I care a lot and I understand the requirements. I also see through misstatements about reality used to justify stupid design decisions. For automated installs you don't have to satisfy me. Feel free to deliver a lousy solution to your users. Just don't use your arbitrary design decisions to justify your kernel patches. Non-interactive installs do not justify removing all trust from the root user of a system, disabling suspend to disk and completely rewriting kexec for the simple expedient removing a couple of lines of code from your bootloader. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: For automated installs you don't have to satisfy me. Feel free to deliver a lousy solution to your users. Just don't use your arbitrary design decisions to justify your kernel patches. My kernel patches are justified by genuine user requirements. If you don't feel that there's any requirement for the kernel to satisfy the people who use it, you're free to ignore those patches. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett mj...@srcf.ucam.org writes: On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: For automated installs you don't have to satisfy me. Feel free to deliver a lousy solution to your users. Just don't use your arbitrary design decisions to justify your kernel patches. My kernel patches are justified by genuine user requirements. Hogwash. If windows is not present on a system linux can not be used to boot a compromised version of windows without user knowledge because windows is not present. If windows is present on a system then to install linux a user must be present and push buttons to get the system to boot off of install media. If a user is present a user presence test may be used to prevent a bootloader signed with Microsoft's key from booting linux without the users consent, and thus prevent Linux from attacking windows users. Therefore preventing the revokation of a signature with Microsoft's signature from your bootloader does not justify elaborate kernel modifications to prevent the booting a compromised version of windows. Furthermore no matter how hard we try with current techniques there will eventually be kernel bugs that allow attackers to inject code into the kernel. So attempting to fully close that attack vector is questionable. If you don't feel that there's any requirement for the kernel to satisfy the people who use it, you're free to ignore those patches. I feel allowing the kernel to be hacked to bits and decend into an unmaintainable mess does not serve the users who use the kernel, and to prevent that technically poor patches should be rejected. This helps prevent non-technical considerations from justifying technically poor decisions. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 09:19:46PM -0800, Eric W. Biederman wrote: Matthew Garrett mj...@srcf.ucam.org writes: On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: For automated installs you don't have to satisfy me. Feel free to deliver a lousy solution to your users. Just don't use your arbitrary design decisions to justify your kernel patches. My kernel patches are justified by genuine user requirements. Hogwash. You keep using that word, which is unfortunate. If windows is not present on a system linux can not be used to boot a compromised version of windows without user knowledge because windows is not present. Correct. If windows is present on a system then to install linux a user must be present and push buttons to get the system to boot off of install media. Incorrect. UEFI boot priorities can be set without physical user interaction. If a user is present a user presence test may be used to prevent a bootloader signed with Microsoft's key from booting linux without the users consent, and thus prevent Linux from attacking windows users. Correct, but precludes the kind of automated installs that I know real people do. The keys a machine carries don't vary depending on whether it shipped with Windows or not, so it's not possible to differentiate between the shipped with Windows and shipped without Windows cases when determining security models. Therefore preventing the revokation of a signature with Microsoft's signature from your bootloader does not justify elaborate kernel modifications to prevent the booting a compromised version of windows. That's a stretch. Bored now. You're adding nothing new to anyone's understanding of the problem, and I'm just saying the same thing I've been saying for months, so I don't see any purpose in discussing this with you further. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
* Eric W. Biederman: If windows is not present on a system linux can not be used to boot a compromised version of windows without user knowledge because windows is not present. Interesting idea. Unfortunately, it is very hard to detect reliably that Windows is not present from the bootloader, so it's not possible to use this approach to simplify matters. If windows is present on a system then to install linux a user must be present and push buttons to get the system to boot off of install media. That's not necessarily true. If a user is present a user presence test may be used to prevent a bootloader signed with Microsoft's key from booting linux without the users consent, and thus prevent Linux from attacking windows users. As already explained, I don't think that user presence accomplishes anything. You need informed consent, and it's impossible to cram that on a 80x25 screen. You also need to make sure that you aren't unnecessarily alarmist. We don't want a Linux may harm your computer warning. Therefore preventing the revokation of a signature with Microsoft's signature from your bootloader does not justify elaborate kernel modifications to prevent the booting a compromised version of windows. I don't like this approach, either. Furthermore no matter how hard we try with current techniques there will eventually be kernel bugs that allow attackers to inject code into the kernel. So attempting to fully close that attack vector is questionable. I suspect we'd need to revoke old binaries after a grace period. I guess the Microsoft approach is to revoke only what's actually used for attacks, but that leads to a lot of unpredictability for our users. It's also annoying if we figure out after release that we have to disable additional kernel functionality because it can be used to compromise the boot path. Users will not like that, especially if they do not use Windows at all. Personally, I think the only way out of this mess is to teach users how to disable Secure Boot. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
This is not a good thing to assume. A vendor could have an external button, gor example. ebied...@xmission.com wrote: >"H. Peter Anvin" writes: > >> On 11/05/2012 07:14 AM, Eric W. Biederman wrote: >>> >>> In any case the notion that unattended install with no user >interaction >>> on any uefi machine in any state is complete and total rubbish. It >>> can't be done. You need power and you need boot media. >>> >> >> That is a hugely different thing from needing a console. > >Not at all. > >In the general case user intereaction is required to tell the system to >boot off of your choosen boot media instead of the local hard drive. > >Eric -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
"H. Peter Anvin" writes: > On 11/05/2012 07:14 AM, Eric W. Biederman wrote: >> >> In any case the notion that unattended install with no user interaction >> on any uefi machine in any state is complete and total rubbish. It >> can't be done. You need power and you need boot media. >> > > That is a hugely different thing from needing a console. Not at all. In the general case user intereaction is required to tell the system to boot off of your choosen boot media instead of the local hard drive. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On 11/05/2012 07:14 AM, Eric W. Biederman wrote: > > In any case the notion that unattended install with no user interaction > on any uefi machine in any state is complete and total rubbish. It > can't be done. You need power and you need boot media. > That is a hugely different thing from needing a console. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Jiri Kosina writes: > On Fri, 2 Nov 2012, Vivek Goyal wrote: > >> > With secure boot enabled, then the kernel should refuse to let an >> > unsigned kexec load new images, and kexec itself should refuse to >> > load unsigned images. >> >> Yep, good in theory. Now that basically means reimplementing kexec-tools >> in kernel. > > Why is "when kernel has been securely booted, the in-kernel kexec > mechanism has to verify the signature of the supplied image before > kexecing it" not enough? (basically the same thing we are doing for signed > modules already). For modules the only untrusted part of their environment are the command line parameters, and several of those have already been noted for needing to be ignored in a non-trusted root scenario. For kexec there is a bunch of glue code and data that takes care of transitioning from the environment provided by kexec and the environment that the linux kernel or memtest86 or whatever we are booting is expecting. Figuring out what glue code and data we need and supplying that glue code and data is what kexec-tools does. The situation is a bit like dealing with the modules before most of the work of insmod was moved into the kernel. For kexec-tools it is desirable to have glue layers outside of the kernel because every boot system in existence has a different set of parameter passing rules. So signing in the kernel gets us into how do we sign the glue code and how dow we verify the glue code will jump to our signed and verified kernel image. I will be happy to review patches for that don't through the baby out with the bath water. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett writes: > On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote: > >> I've actually had more than enough experience with automated installs >> over my career: they're either done by paying someone or using a >> provisioning system. In either case, they provision a static image and >> boot environment description, including EFI boot services variables, so >> you can provision a default MOK database if you want the ignition image >> not to pause on firstboot. > > And now you've moved the attack vector to a copy of your provisioning > system instead. > >> There is obviously the question of making the provisioning systems >> secure, but it's a separate one from making boot secure. > > You don't get to punt on making the kernel secure by simply asserting > that some other system can be secure instead. The chain of trust needs > to go all the way back - if your security model is based on all installs > needing a physically present end user, all installs need a physically > present end user. That's not acceptable, so we need a different security > model. Bzzzt. Theory and reality disagreeing. I have done a lot of automatic installs. At the very least someone has to be present to apply power to the hardware. So someone being present is not a requirement you can remove. Furthermore in most cases an automatic install requires kicking the system into network boot mode or into inserting an install cd. Both are actions that require a user to be present. The goal is to reduce what a user must do to a minimum to remove the possibility of human error, not to reduce what must happen into absurdity. The other side is that a general purpose configuration of firmware almost never is suitable for a general install. So either some small amount of time must be spent fixing the BIOS settings or have an appropriate set of BIOS settings come from your supplier. In practice what I would expect of a UEFI system that ships ready for automatic installs is a system that initiall boots up in "setup mode" where it is possible to install your own platform signing key. What I would expect to happen in that situation is that during the first boot software would come over the network or from an install cd and install my platform signing key. Then a bootloader signed with my key would be installed, and then everything would chain from there. In most cases where I would be setting up an automatic install I would not install Microsoft's key, and I would definitely not sign my bootloader with Microsoft's key. At most I would sign my own "key install" with Microsoft's key. Then in cases of automatic reinstallation my key would be in the firmware and I could change my bootloader and my kernels at will with no risk that some third party could do anything to the machine unless they manged to get physical access. If I was a distroy my key would that I would install by default would be the distro's signing key. Although honestly I would still prefer a solution where I could lock things down a little farther. In any case the notion that unattended install with no user interaction on any uefi machine in any state is complete and total rubbish. It can't be done. You need power and you need boot media. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote: > I've actually had more than enough experience with automated installs > over my career: they're either done by paying someone or using a > provisioning system. In either case, they provision a static image and > boot environment description, including EFI boot services variables, so > you can provision a default MOK database if you want the ignition image > not to pause on firstboot. And now you've moved the attack vector to a copy of your provisioning system instead. > There is obviously the question of making the provisioning systems > secure, but it's a separate one from making boot secure. You don't get to punt on making the kernel secure by simply asserting that some other system can be secure instead. The chain of trust needs to go all the way back - if your security model is based on all installs needing a physically present end user, all installs need a physically present end user. That's not acceptable, so we need a different security model. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun 2012-11-04 04:28:02, Matthew Garrett wrote: > On Sat, Nov 03, 2012 at 10:56:40PM +, James Bottomley wrote: > > On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote: > > > I... what? Our signed bootloader will boot our signed kernel without any > > > physically present end-user involvement. We therefore need to make it > > > as difficult as practically possible for an attacker to use our signed > > > bootloader and our signed kernel as an attack vector against other > > > operating systems, which includes worrying about hibernate and kexec. If > > > people want to support this use case then patches to deal with that need > > > to be present in the upstream kernel. > > > > Right, but what I'm telling you is that by deciding to allow automatic > > first boot, you're causing the windows attack vector problem. You could > > easily do a present user test only on first boot which would eliminate > > it. Instead, we get all of this. > > Your definition of "Best practices" is "Automated installs are > impossible"? Have you ever actually spoken to a user? Always polite Matthew... Anyway, problem with introducing random signatures all over the kernel is that it does not _work_. You'll end up signing all the userspace, too. So far you want to sign kexec, soon you'll discover you need to sign s2disk, too, and then you realize X, wine and dosemu needs the same treatment. fwvm95 comes next. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun, 2012-11-04 at 04:28 +, Matthew Garrett wrote: > On Sat, Nov 03, 2012 at 10:56:40PM +, James Bottomley wrote: > > On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote: > > > I... what? Our signed bootloader will boot our signed kernel without any > > > physically present end-user involvement. We therefore need to make it > > > as difficult as practically possible for an attacker to use our signed > > > bootloader and our signed kernel as an attack vector against other > > > operating systems, which includes worrying about hibernate and kexec. If > > > people want to support this use case then patches to deal with that need > > > to be present in the upstream kernel. > > > > Right, but what I'm telling you is that by deciding to allow automatic > > first boot, you're causing the windows attack vector problem. You could > > easily do a present user test only on first boot which would eliminate > > it. Instead, we get all of this. > > Your definition of "Best practices" is "Automated installs are > impossible"? Have you ever actually spoken to a user? Are you sure you've spoken to the right users if you think they use a distro boot system to do automated installs? I've actually had more than enough experience with automated installs over my career: they're either done by paying someone or using a provisioning system. In either case, they provision a static image and boot environment description, including EFI boot services variables, so you can provision a default MOK database if you want the ignition image not to pause on firstboot. There is obviously the question of making the provisioning systems secure, but it's a separate one from making boot secure. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun, 2012-11-04 at 04:28 +, Matthew Garrett wrote: On Sat, Nov 03, 2012 at 10:56:40PM +, James Bottomley wrote: On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote: I... what? Our signed bootloader will boot our signed kernel without any physically present end-user involvement. We therefore need to make it as difficult as practically possible for an attacker to use our signed bootloader and our signed kernel as an attack vector against other operating systems, which includes worrying about hibernate and kexec. If people want to support this use case then patches to deal with that need to be present in the upstream kernel. Right, but what I'm telling you is that by deciding to allow automatic first boot, you're causing the windows attack vector problem. You could easily do a present user test only on first boot which would eliminate it. Instead, we get all of this. Your definition of Best practices is Automated installs are impossible? Have you ever actually spoken to a user? Are you sure you've spoken to the right users if you think they use a distro boot system to do automated installs? I've actually had more than enough experience with automated installs over my career: they're either done by paying someone or using a provisioning system. In either case, they provision a static image and boot environment description, including EFI boot services variables, so you can provision a default MOK database if you want the ignition image not to pause on firstboot. There is obviously the question of making the provisioning systems secure, but it's a separate one from making boot secure. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun 2012-11-04 04:28:02, Matthew Garrett wrote: On Sat, Nov 03, 2012 at 10:56:40PM +, James Bottomley wrote: On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote: I... what? Our signed bootloader will boot our signed kernel without any physically present end-user involvement. We therefore need to make it as difficult as practically possible for an attacker to use our signed bootloader and our signed kernel as an attack vector against other operating systems, which includes worrying about hibernate and kexec. If people want to support this use case then patches to deal with that need to be present in the upstream kernel. Right, but what I'm telling you is that by deciding to allow automatic first boot, you're causing the windows attack vector problem. You could easily do a present user test only on first boot which would eliminate it. Instead, we get all of this. Your definition of Best practices is Automated installs are impossible? Have you ever actually spoken to a user? Always polite Matthew... Anyway, problem with introducing random signatures all over the kernel is that it does not _work_. You'll end up signing all the userspace, too. So far you want to sign kexec, soon you'll discover you need to sign s2disk, too, and then you realize X, wine and dosemu needs the same treatment. fwvm95 comes next. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote: I've actually had more than enough experience with automated installs over my career: they're either done by paying someone or using a provisioning system. In either case, they provision a static image and boot environment description, including EFI boot services variables, so you can provision a default MOK database if you want the ignition image not to pause on firstboot. And now you've moved the attack vector to a copy of your provisioning system instead. There is obviously the question of making the provisioning systems secure, but it's a separate one from making boot secure. You don't get to punt on making the kernel secure by simply asserting that some other system can be secure instead. The chain of trust needs to go all the way back - if your security model is based on all installs needing a physically present end user, all installs need a physically present end user. That's not acceptable, so we need a different security model. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett mj...@srcf.ucam.org writes: On Sun, Nov 04, 2012 at 09:14:47AM +, James Bottomley wrote: I've actually had more than enough experience with automated installs over my career: they're either done by paying someone or using a provisioning system. In either case, they provision a static image and boot environment description, including EFI boot services variables, so you can provision a default MOK database if you want the ignition image not to pause on firstboot. And now you've moved the attack vector to a copy of your provisioning system instead. There is obviously the question of making the provisioning systems secure, but it's a separate one from making boot secure. You don't get to punt on making the kernel secure by simply asserting that some other system can be secure instead. The chain of trust needs to go all the way back - if your security model is based on all installs needing a physically present end user, all installs need a physically present end user. That's not acceptable, so we need a different security model. Bzzzt. Theory and reality disagreeing. I have done a lot of automatic installs. At the very least someone has to be present to apply power to the hardware. So someone being present is not a requirement you can remove. Furthermore in most cases an automatic install requires kicking the system into network boot mode or into inserting an install cd. Both are actions that require a user to be present. The goal is to reduce what a user must do to a minimum to remove the possibility of human error, not to reduce what must happen into absurdity. The other side is that a general purpose configuration of firmware almost never is suitable for a general install. So either some small amount of time must be spent fixing the BIOS settings or have an appropriate set of BIOS settings come from your supplier. In practice what I would expect of a UEFI system that ships ready for automatic installs is a system that initiall boots up in setup mode where it is possible to install your own platform signing key. What I would expect to happen in that situation is that during the first boot software would come over the network or from an install cd and install my platform signing key. Then a bootloader signed with my key would be installed, and then everything would chain from there. In most cases where I would be setting up an automatic install I would not install Microsoft's key, and I would definitely not sign my bootloader with Microsoft's key. At most I would sign my own key install with Microsoft's key. Then in cases of automatic reinstallation my key would be in the firmware and I could change my bootloader and my kernels at will with no risk that some third party could do anything to the machine unless they manged to get physical access. If I was a distroy my key would that I would install by default would be the distro's signing key. Although honestly I would still prefer a solution where I could lock things down a little farther. In any case the notion that unattended install with no user interaction on any uefi machine in any state is complete and total rubbish. It can't be done. You need power and you need boot media. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Jiri Kosina jkos...@suse.cz writes: On Fri, 2 Nov 2012, Vivek Goyal wrote: With secure boot enabled, then the kernel should refuse to let an unsigned kexec load new images, and kexec itself should refuse to load unsigned images. Yep, good in theory. Now that basically means reimplementing kexec-tools in kernel. Why is when kernel has been securely booted, the in-kernel kexec mechanism has to verify the signature of the supplied image before kexecing it not enough? (basically the same thing we are doing for signed modules already). For modules the only untrusted part of their environment are the command line parameters, and several of those have already been noted for needing to be ignored in a non-trusted root scenario. For kexec there is a bunch of glue code and data that takes care of transitioning from the environment provided by kexec and the environment that the linux kernel or memtest86 or whatever we are booting is expecting. Figuring out what glue code and data we need and supplying that glue code and data is what kexec-tools does. The situation is a bit like dealing with the modules before most of the work of insmod was moved into the kernel. For kexec-tools it is desirable to have glue layers outside of the kernel because every boot system in existence has a different set of parameter passing rules. So signing in the kernel gets us into how do we sign the glue code and how dow we verify the glue code will jump to our signed and verified kernel image. I will be happy to review patches for that don't through the baby out with the bath water. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On 11/05/2012 07:14 AM, Eric W. Biederman wrote: In any case the notion that unattended install with no user interaction on any uefi machine in any state is complete and total rubbish. It can't be done. You need power and you need boot media. That is a hugely different thing from needing a console. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
H. Peter Anvin h...@zytor.com writes: On 11/05/2012 07:14 AM, Eric W. Biederman wrote: In any case the notion that unattended install with no user interaction on any uefi machine in any state is complete and total rubbish. It can't be done. You need power and you need boot media. That is a hugely different thing from needing a console. Not at all. In the general case user intereaction is required to tell the system to boot off of your choosen boot media instead of the local hard drive. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
This is not a good thing to assume. A vendor could have an external button, gor example. ebied...@xmission.com wrote: H. Peter Anvin h...@zytor.com writes: On 11/05/2012 07:14 AM, Eric W. Biederman wrote: In any case the notion that unattended install with no user interaction on any uefi machine in any state is complete and total rubbish. It can't be done. You need power and you need boot media. That is a hugely different thing from needing a console. Not at all. In the general case user intereaction is required to tell the system to boot off of your choosen boot media instead of the local hard drive. Eric -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sat, Nov 03, 2012 at 10:56:40PM +, James Bottomley wrote: > On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote: > > I... what? Our signed bootloader will boot our signed kernel without any > > physically present end-user involvement. We therefore need to make it > > as difficult as practically possible for an attacker to use our signed > > bootloader and our signed kernel as an attack vector against other > > operating systems, which includes worrying about hibernate and kexec. If > > people want to support this use case then patches to deal with that need > > to be present in the upstream kernel. > > Right, but what I'm telling you is that by deciding to allow automatic > first boot, you're causing the windows attack vector problem. You could > easily do a present user test only on first boot which would eliminate > it. Instead, we get all of this. Your definition of "Best practices" is "Automated installs are impossible"? Have you ever actually spoken to a user? -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Fri, 2 Nov 2012, Vivek Goyal wrote: > > With secure boot enabled, then the kernel should refuse to let an > > unsigned kexec load new images, and kexec itself should refuse to > > load unsigned images. > > Yep, good in theory. Now that basically means reimplementing kexec-tools > in kernel. Why is "when kernel has been securely booted, the in-kernel kexec mechanism has to verify the signature of the supplied image before kexecing it" not enough? (basically the same thing we are doing for signed modules already). -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote: > On Sat, Nov 03, 2012 at 12:03:56PM +, James Bottomley wrote: > > On Sat, 2012-11-03 at 00:22 +, Matthew Garrett wrote: > > > Why would an attacker use one of those Linux systems? There's going to > > > be plenty available that don't have that restriction. > > > > It's called best practices. If someone else releases something that > > doesn't conform to them, then it's their signing key in jeopardy, not > > yours. You surely must see that the goal of securing "everything" > > against "anything" isn't achievable because if someone releases a > > bootloader not conforming to the best practices, why would they have > > bothered to include your secure boot lockdowns in their kernel. In > > other words, you lost ab initio, so it's pointless to cite this type of > > thing as a rationale for a kernel lockdown patch. > > I... what? Our signed bootloader will boot our signed kernel without any > physically present end-user involvement. We therefore need to make it > as difficult as practically possible for an attacker to use our signed > bootloader and our signed kernel as an attack vector against other > operating systems, which includes worrying about hibernate and kexec. If > people want to support this use case then patches to deal with that need > to be present in the upstream kernel. Right, but what I'm telling you is that by deciding to allow automatic first boot, you're causing the windows attack vector problem. You could easily do a present user test only on first boot which would eliminate it. Instead, we get all of this. By analogy, it's like an architect trying to design a house to be secure without a front door lock. If you just secure the front door, you don't necessarily need all the internal security. There is certainly a market for houses with good internal security, but not everyone wants the hassle, so trying to make every house that way is counterproductive. It's also not so useful to the people who want specialist internal security because they're willing to use much more specialised systems than you have to deploy generally. In short, if you'd just separate the problem into 1. What do we have to do to prevent Linux being used to attack windows and thus getting our key revoked from, 2. What specialised systems can we put in place to enhance linux security with secure boot for those who want it It becomes a lot simpler than trying to do a one size fits all solution. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sat, Nov 03, 2012 at 12:37:44PM -0400, Eric Paris wrote: > On Sat, Nov 3, 2012 at 12:31 PM, Alan Cox wrote: > >> You're guaranteed to be able > >> to do this on any Windows 8 certified hardware. > > > > Thats not my understanding of the situation. > > Windows 8 certification has this as a requirement for x86 hardware. I > belied the opposite is a requirement for arm hardware. However it's > possible that it just doesn't specifiy at all for arm. Arm devices are Windows RT, not Windows 8. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sat, Nov 03, 2012 at 04:31:52PM +, Alan Cox wrote: > > You're guaranteed to be able > > to do this on any Windows 8 certified hardware. > > Thats not my understanding of the situation. "17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following: a. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode." -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sat, Nov 3, 2012 at 12:31 PM, Alan Cox wrote: >> You're guaranteed to be able >> to do this on any Windows 8 certified hardware. > > Thats not my understanding of the situation. Windows 8 certification has this as a requirement for x86 hardware. I belied the opposite is a requirement for arm hardware. However it's possible that it just doesn't specifiy at all for arm. So yes, you're guaranteed to be able to do this on any Windows 8 certified x86 hardware. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
> You're guaranteed to be able > to do this on any Windows 8 certified hardware. Thats not my understanding of the situation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Sat, Nov 03, 2012 at 12:03:56PM +, James Bottomley wrote: > On Sat, 2012-11-03 at 00:22 +, Matthew Garrett wrote: > > Why would an attacker use one of those Linux systems? There's going to > > be plenty available that don't have that restriction. > > It's called best practices. If someone else releases something that > doesn't conform to them, then it's their signing key in jeopardy, not > yours. You surely must see that the goal of securing "everything" > against "anything" isn't achievable because if someone releases a > bootloader not conforming to the best practices, why would they have > bothered to include your secure boot lockdowns in their kernel. In > other words, you lost ab initio, so it's pointless to cite this type of > thing as a rationale for a kernel lockdown patch. I... what? Our signed bootloader will boot our signed kernel without any physically present end-user involvement. We therefore need to make it as difficult as practically possible for an attacker to use our signed bootloader and our signed kernel as an attack vector against other operating systems, which includes worrying about hibernate and kexec. If people want to support this use case then patches to deal with that need to be present in the upstream kernel. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
