Re: [qubes-users] Options for securing /boot
On Tuesday, April 3, 2018 at 4:24:21 AM UTC-4, tai...@gmx.com wrote: > On 04/02/2018 09:32 PM, cooloutac wrote: > > > On Monday, April 2, 2018 at 3:43:50 PM UTC-4, tai...@gmx.com wrote: > >> On 09/08/2017 07:12 AM, Leo Gaspard wrote: > >> > >>> Just a datapoint: secure boot is *not* microsoft-controlled (unless you > >>> assume the manufacturer put in some kind of backdoor, in which case > >>> you're screwed anyway). > >> Yes it is microsoft controlled, they're the ones who made the standard > >> and conveniently left out the owner controlled mandate in sb 2.0 once > >> the attention died down. > >> It will eventually be used to prevent people from running linux all > >> together at least your own linux not one that is approved by red hat. > > Where are these boards. I've never seen one that doesnt' let you shut it > > off or use your own keys? > The MS ARM "Windows RT" tablets for one - with those they test the waters. > SB 2.0 leaves out the owner control mandate - go examine the specs and > see for yourself. > > Smartphones were actually the first area the walled garden was tested on. > I am old enough to remember the PalmOS era when installing apps on a > smartphone was the same as the average win32 model of downloading > something off the internet not a walled garden app store - folks like > apple/ms have the masses convinced that it has always been a walled > garden but that is not the case. > > Time will tell, but right now as Richard Stallman thinks "its failed its > > intended purpose" > This is a slow burn effort - doing it all at once straight away would > lead to protest. > > and Why Red Hat? > Red hat controls linux and is microsoft friendly - because their > developers control many critical linux programs they ARE a modern > desktop linux. Why do you think so distros suddenly adopted systemd > against the opinions of their users? or why so many core programs now > require red hat controlled systemd? (like gnome and udev) > Red hat accepted "secure" boot and got a grub and kernel signed by MS - > such an action is a betrayal. > > Soon you will not even be able run the apps you please on the average > store bought computer enforcing a MS monopoly where they get a cut of > every app sale. > MS says "Windows 10 S is not well-suited for many app > developers/hackers, admins & IT pro's!" > How do you create the next generation of those? They ALL learn on their > parents computer not some "developer edition" which not even wealthy > parents buy their children. > Windows S, a locked down walled garden PC is the future of computing. tablets and phones? I'd have to see it to believe it. Qubes is a beast for a beastly desktop. it got me back into building them lol. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e5cb0dd0-95f6-4105-9fbf-2c3aff9f63b0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On 04/02/2018 09:32 PM, cooloutac wrote: > On Monday, April 2, 2018 at 3:43:50 PM UTC-4, tai...@gmx.com wrote: >> On 09/08/2017 07:12 AM, Leo Gaspard wrote: >> >>> Just a datapoint: secure boot is *not* microsoft-controlled (unless you >>> assume the manufacturer put in some kind of backdoor, in which case >>> you're screwed anyway). >> Yes it is microsoft controlled, they're the ones who made the standard >> and conveniently left out the owner controlled mandate in sb 2.0 once >> the attention died down. >> It will eventually be used to prevent people from running linux all >> together at least your own linux not one that is approved by red hat. > Where are these boards. I've never seen one that doesnt' let you shut it off > or use your own keys? The MS ARM "Windows RT" tablets for one - with those they test the waters. SB 2.0 leaves out the owner control mandate - go examine the specs and see for yourself. Smartphones were actually the first area the walled garden was tested on. I am old enough to remember the PalmOS era when installing apps on a smartphone was the same as the average win32 model of downloading something off the internet not a walled garden app store - folks like apple/ms have the masses convinced that it has always been a walled garden but that is not the case. > Time will tell, but right now as Richard Stallman thinks "its failed its > intended purpose" This is a slow burn effort - doing it all at once straight away would lead to protest. > and Why Red Hat? Red hat controls linux and is microsoft friendly - because their developers control many critical linux programs they ARE a modern desktop linux. Why do you think so distros suddenly adopted systemd against the opinions of their users? or why so many core programs now require red hat controlled systemd? (like gnome and udev) Red hat accepted "secure" boot and got a grub and kernel signed by MS - such an action is a betrayal. Soon you will not even be able run the apps you please on the average store bought computer enforcing a MS monopoly where they get a cut of every app sale. MS says "Windows 10 S is not well-suited for many app developers/hackers, admins & IT pro's!" How do you create the next generation of those? They ALL learn on their parents computer not some "developer edition" which not even wealthy parents buy their children. Windows S, a locked down walled garden PC is the future of computing. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b78210fd-9edf-d31b-6654-546770ec427c%40gmx.com. For more options, visit https://groups.google.com/d/optout. 0xDF372A17.asc Description: application/pgp-keys
Re: [qubes-users] Options for securing /boot
On Monday, April 2, 2018 at 3:43:50 PM UTC-4, tai...@gmx.com wrote: > On 09/08/2017 07:12 AM, Leo Gaspard wrote: > > > Just a datapoint: secure boot is *not* microsoft-controlled (unless you > > assume the manufacturer put in some kind of backdoor, in which case > > you're screwed anyway). > Yes it is microsoft controlled, they're the ones who made the standard > and conveniently left out the owner controlled mandate in sb 2.0 once > the attention died down. > It will eventually be used to prevent people from running linux all > together at least your own linux not one that is approved by red hat. Where are these boards. I've never seen one that doesnt' let you shut it off or use your own keys? Time will tell, but right now as Richard Stallman thinks "its failed its intended purpose". and Why Red Hat? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/227640b9-12d7-4600-82c1-9084f7618daa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On 09/08/2017 07:12 AM, Leo Gaspard wrote: > Just a datapoint: secure boot is *not* microsoft-controlled (unless you > assume the manufacturer put in some kind of backdoor, in which case > you're screwed anyway). Yes it is microsoft controlled, they're the ones who made the standard and conveniently left out the owner controlled mandate in sb 2.0 once the attention died down. It will eventually be used to prevent people from running linux all together at least your own linux not one that is approved by red hat. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f1397f4a-f1c1-8f59-1568-c0dac32d1e38%40gmx.com. For more options, visit https://groups.google.com/d/optout. 0xDF372A17.asc Description: application/pgp-keys
Re: [qubes-users] Options for securing /boot
On 09/08/2017 04:51 AM, taii...@gmx.com wrote: > One can use coreboot with grub's kernel signing features on an owner > controlled non PSP/ME PC such as the Lenovo G505 (laptop) or KCMA-D8 > (workstation), then after coreboot is working you enable the flash write > restriction so that it can't be flashed internally (an attacker would > have to have physical access for around 10mins to reflash) - this is > technically superior to "secure boot" as it is owner controlled by you > instead of microsoft. Just a datapoint: secure boot is *not* microsoft-controlled (unless you assume the manufacturer put in some kind of backdoor, in which case you're screwed anyway). Secure boot *by default* runs with keys owned by microsoft. You can (and should) replace them with a key you own and you use to sign new GRUBs, if you want to. The option to do so is usually somewhere in the BIOS menu. Once you have removed microsoft's golden key and put your own instead, there is no longer any link between your secure boot and microsoft. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4f6892f2-e515-75f5-e93d-d77d3e5df29a%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
One can use coreboot with grub's kernel signing features on an owner controlled non PSP/ME PC such as the Lenovo G505 (laptop) or KCMA-D8 (workstation), then after coreboot is working you enable the flash write restriction so that it can't be flashed internally (an attacker would have to have physical access for around 10mins to reflash) - this is technically superior to "secure boot" as it is owner controlled by you instead of microsoft. You can also use AEM if you purchase the TPM accessory. The Libre OpenPOWER9 TALOS 2 server/workstation (also owner controlled) features kernel signing features as well including some special sauce from raptor - if you have the money to buy new server/workstation class professional grade hardware it is a good deal for what you get and would last 10 years before you need to upgrade seeing as how powerful it is (the entry level 4 core CPU has 12 SMT threads, much better than intels non-SMT hyperthreading.) As always I am more than happy to assist someone with purchasing and configuring libre devices and the security features present. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c317cfb0-16f5-bfad-d63c-cc5e9aa74210%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On Thursday, September 7, 2017 at 12:49:05 PM UTC-4, cooloutac wrote: > On Thursday, September 7, 2017 at 9:40:47 AM UTC-4, Patrik Hagara wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On 09/07/2017 03:21 PM, cooloutac wrote: > > > On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara > > > wrote: On 08/29/2017 06:25 PM, cooloutac wrote: > > On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik > > Hagara wrote: On 08/29/2017 04:50 PM, > > cyberian@national.shitposting.agency wrote: > > >>> Leo Gaspard, > > >>> > > >>> I have read about AEM but have never used it, it seems > > >>> like it is geared towards protecting from USB's with > > >>> malicious firmware on them. > > >>> > > >>> Does AEM actually verify the integrity of /boot before > > >>> using? This is what I am looking for, either a method > > >>> of encrypting /boot or even better, a secure method to > > >>> verify its integrity during boot > > >>> > > > > AEM does verify the integrity of /boot using the TPM > > seal/unseal operation. If any of the boot components change, > > AEM falls back to regular, unmeasured boot -- the user is > > expected to notice this and cease using the > > potentially-compromised system (the lack of explicit > > indication of failed AEM boot is deliberate, see the last FAQ > > item at [1]). > > > > The security provided by AEM is much more stronger than > > encrypted /boot could ever offer, because as already pointed > > out, there is always a little first-stage bootloader stub on > > the disk unencrypted and it would be easy to overwrite it > > with a malicious version that would intercept the encryption > > passphrase and exfiltrate it using eg. unused disk sectors. > > > > If someone did the above with AEM, the TPM would refuse to > > useal the AEM secret as the platform state would be > > different. > > > > The feature protecting dom0 from malicious USB devices [2] > > serves a different purpose and is not related to AEM. Plus, > > you always need to disconnect all untrusted USB devices while > > rebooting Qubes, regardless of whether you have USB qube set > > up or not. > > > > > > Cheers, Patrik > > > > > > [1] > > https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html > > [2] https://www.qubes-os.org/doc/usb/ > > > > my problem is unfortunately i can't keep buying new pc's. SO > > maybe its all for naught for me.. Also AEM does not seem as > > reliable as secureboot. Alot of issues on threads with some > > people. It seems complicated. even false alarms. But I really > > do think they are supposed to compliment each other. trusted > > boot and measured boot yes? AEM definitely comes in handy for > > people who would find it nescessary to buy new equipment. > > > > > > Well, it depends... If you can be reasonably sure that the > > > attacker did not modify any firmware (eg. the network card), you > > > could simply reinstall Qubes from a trusted install media and > > > restore VMs from a backup. This becomes trivial once stateless > > > computers [1] are a thing. > > > > > But I would still want an encrypted boot, if I was going to > > use aem, and key on a external usb disk, which > > unfortunately means I could not use a sys-usb. Am I wrong > > about this? Does this change in 4.0? > > > > > > It is possible to use AEM along with USB qube, you just have to > > > disable the early hiding of USB devices from dom0. But once Qubes > > > is fully booted and sys-usb started, you get the full USB qubes > > > protecion. > > > > > So this is where the what fits into you "security model" > > What are you more concered about. I assumed we had to choose > > between aem vs sys-usb? For people travelling with laptops > > in strange places where physical compromise is more likely > > aem is a good option. Some people would prolly not just buy a > > new laptop but know when to destroy theirs too lol. > > > > > > The only trade-off for AEM regarding USB devices is that the USB > > > stick you buy to install AEM on could be compromised already > > > (straight from the factory, or intercepted & infected during > > > shipping). And since you need to plug it directly into dom0 in > > > order to perform the install, it could exploit USB or filesystem > > > drivers and gain control of dom0. > > > > > > So it is kind of a trust-on-first-use scenario for the > > > installation step only. > > > > > > > > > Cheers, Patrik > > > > > > > > > [1] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf > > > > > > Doesn't Qubes assume the netcard will be compromised, hence > > > untrusted. > > > > It does, but with compromised firmware the NIC can
Re: [qubes-users] Options for securing /boot
On Thursday, September 7, 2017 at 9:40:47 AM UTC-4, Patrik Hagara wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 09/07/2017 03:21 PM, cooloutac wrote: > > On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara > > wrote: On 08/29/2017 06:25 PM, cooloutac wrote: > On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik > Hagara wrote: On 08/29/2017 04:50 PM, > cyberian@national.shitposting.agency wrote: > >>> Leo Gaspard, > >>> > >>> I have read about AEM but have never used it, it seems > >>> like it is geared towards protecting from USB's with > >>> malicious firmware on them. > >>> > >>> Does AEM actually verify the integrity of /boot before > >>> using? This is what I am looking for, either a method > >>> of encrypting /boot or even better, a secure method to > >>> verify its integrity during boot > >>> > > AEM does verify the integrity of /boot using the TPM > seal/unseal operation. If any of the boot components change, > AEM falls back to regular, unmeasured boot -- the user is > expected to notice this and cease using the > potentially-compromised system (the lack of explicit > indication of failed AEM boot is deliberate, see the last FAQ > item at [1]). > > The security provided by AEM is much more stronger than > encrypted /boot could ever offer, because as already pointed > out, there is always a little first-stage bootloader stub on > the disk unencrypted and it would be easy to overwrite it > with a malicious version that would intercept the encryption > passphrase and exfiltrate it using eg. unused disk sectors. > > If someone did the above with AEM, the TPM would refuse to > useal the AEM secret as the platform state would be > different. > > The feature protecting dom0 from malicious USB devices [2] > serves a different purpose and is not related to AEM. Plus, > you always need to disconnect all untrusted USB devices while > rebooting Qubes, regardless of whether you have USB qube set > up or not. > > > Cheers, Patrik > > > [1] > https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html > [2] https://www.qubes-os.org/doc/usb/ > > my problem is unfortunately i can't keep buying new pc's. SO > maybe its all for naught for me.. Also AEM does not seem as > reliable as secureboot. Alot of issues on threads with some > people. It seems complicated. even false alarms. But I really > do think they are supposed to compliment each other. trusted > boot and measured boot yes? AEM definitely comes in handy for > people who would find it nescessary to buy new equipment. > > > > Well, it depends... If you can be reasonably sure that the > > attacker did not modify any firmware (eg. the network card), you > > could simply reinstall Qubes from a trusted install media and > > restore VMs from a backup. This becomes trivial once stateless > > computers [1] are a thing. > > > But I would still want an encrypted boot, if I was going to > use aem, and key on a external usb disk, which > unfortunately means I could not use a sys-usb. Am I wrong > about this? Does this change in 4.0? > > > > It is possible to use AEM along with USB qube, you just have to > > disable the early hiding of USB devices from dom0. But once Qubes > > is fully booted and sys-usb started, you get the full USB qubes > > protecion. > > > So this is where the what fits into you "security model" > What are you more concered about. I assumed we had to choose > between aem vs sys-usb? For people travelling with laptops > in strange places where physical compromise is more likely > aem is a good option. Some people would prolly not just buy a > new laptop but know when to destroy theirs too lol. > > > > The only trade-off for AEM regarding USB devices is that the USB > > stick you buy to install AEM on could be compromised already > > (straight from the factory, or intercepted & infected during > > shipping). And since you need to plug it directly into dom0 in > > order to perform the install, it could exploit USB or filesystem > > drivers and gain control of dom0. > > > > So it is kind of a trust-on-first-use scenario for the > > installation step only. > > > > > > Cheers, Patrik > > > > > > [1] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf > > > > Doesn't Qubes assume the netcard will be compromised, hence > > untrusted. > > It does, but with compromised firmware the NIC can inject code into > the OS during early boot (before the NIC is isolated from DMA using > the IOMMU). AEM will catch/prevent this. > > > So good to know we can use a usb key with a sys-usb. IS there > > some sort of risk to doing this? Do we have to pull out the usb > > stick
Re: [qubes-users] Options for securing /boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/07/2017 03:21 PM, cooloutac wrote: > On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara > wrote: On 08/29/2017 06:25 PM, cooloutac wrote: On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara wrote: On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency wrote: >>> Leo Gaspard, >>> >>> I have read about AEM but have never used it, it seems >>> like it is geared towards protecting from USB's with >>> malicious firmware on them. >>> >>> Does AEM actually verify the integrity of /boot before >>> using? This is what I am looking for, either a method >>> of encrypting /boot or even better, a secure method to >>> verify its integrity during boot >>> AEM does verify the integrity of /boot using the TPM seal/unseal operation. If any of the boot components change, AEM falls back to regular, unmeasured boot -- the user is expected to notice this and cease using the potentially-compromised system (the lack of explicit indication of failed AEM boot is deliberate, see the last FAQ item at [1]). The security provided by AEM is much more stronger than encrypted /boot could ever offer, because as already pointed out, there is always a little first-stage bootloader stub on the disk unencrypted and it would be easy to overwrite it with a malicious version that would intercept the encryption passphrase and exfiltrate it using eg. unused disk sectors. If someone did the above with AEM, the TPM would refuse to useal the AEM secret as the platform state would be different. The feature protecting dom0 from malicious USB devices [2] serves a different purpose and is not related to AEM. Plus, you always need to disconnect all untrusted USB devices while rebooting Qubes, regardless of whether you have USB qube set up or not. Cheers, Patrik [1] https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html [2] https://www.qubes-os.org/doc/usb/ my problem is unfortunately i can't keep buying new pc's. SO maybe its all for naught for me.. Also AEM does not seem as reliable as secureboot. Alot of issues on threads with some people. It seems complicated. even false alarms. But I really do think they are supposed to compliment each other. trusted boot and measured boot yes? AEM definitely comes in handy for people who would find it nescessary to buy new equipment. > > Well, it depends... If you can be reasonably sure that the > attacker did not modify any firmware (eg. the network card), you > could simply reinstall Qubes from a trusted install media and > restore VMs from a backup. This becomes trivial once stateless > computers [1] are a thing. > But I would still want an encrypted boot, if I was going to use aem, and key on a external usb disk, which unfortunately means I could not use a sys-usb. Am I wrong about this? Does this change in 4.0? > > It is possible to use AEM along with USB qube, you just have to > disable the early hiding of USB devices from dom0. But once Qubes > is fully booted and sys-usb started, you get the full USB qubes > protecion. > So this is where the what fits into you "security model" What are you more concered about. I assumed we had to choose between aem vs sys-usb? For people travelling with laptops in strange places where physical compromise is more likely aem is a good option. Some people would prolly not just buy a new laptop but know when to destroy theirs too lol. > > The only trade-off for AEM regarding USB devices is that the USB > stick you buy to install AEM on could be compromised already > (straight from the factory, or intercepted & infected during > shipping). And since you need to plug it directly into dom0 in > order to perform the install, it could exploit USB or filesystem > drivers and gain control of dom0. > > So it is kind of a trust-on-first-use scenario for the > installation step only. > > > Cheers, Patrik > > > [1] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf > > Doesn't Qubes assume the netcard will be compromised, hence > untrusted. It does, but with compromised firmware the NIC can inject code into the OS during early boot (before the NIC is isolated from DMA using the IOMMU). AEM will catch/prevent this. > So good to know we can use a usb key with a sys-usb. IS there > some sort of risk to doing this? Do we have to pull out the usb > stick quickly after booting before system loads or something? Not sure about the currently available AEM version, but if/when my changes to AEM get merged, you get prompted to remove the AEM USB stick before Qubes will finish booting (so that the untrusted sys-usb cannot read the contents of the
Re: [qubes-users] Options for securing /boot
On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 08/29/2017 06:25 PM, cooloutac wrote: > > On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara > > wrote: On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency > > wrote: > Leo Gaspard, > > I have read about AEM but have never used it, it seems like > it is geared towards protecting from USB's with malicious > firmware on them. > > Does AEM actually verify the integrity of /boot before using? > This is what I am looking for, either a method of encrypting > /boot or even better, a secure method to verify its integrity > during boot > > > > > AEM does verify the integrity of /boot using the TPM seal/unseal > > operation. If any of the boot components change, AEM falls back to > > regular, unmeasured boot -- the user is expected to notice this and > > cease using the potentially-compromised system (the lack of > > explicit indication of failed AEM boot is deliberate, see the last > > FAQ item at [1]). > > > > The security provided by AEM is much more stronger than encrypted > > /boot could ever offer, because as already pointed out, there is > > always a little first-stage bootloader stub on the disk > > unencrypted and it would be easy to overwrite it with a malicious > > version that would intercept the encryption passphrase and > > exfiltrate it using eg. unused disk sectors. > > > > If someone did the above with AEM, the TPM would refuse to useal > > the AEM secret as the platform state would be different. > > > > The feature protecting dom0 from malicious USB devices [2] serves > > a different purpose and is not related to AEM. Plus, you always > > need to disconnect all untrusted USB devices while rebooting Qubes, > > regardless of whether you have USB qube set up or not. > > > > > > Cheers, Patrik > > > > > > [1] > > https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html [2] > > https://www.qubes-os.org/doc/usb/ > > > > my problem is unfortunately i can't keep buying new pc's. SO maybe > > its all for naught for me.. Also AEM does not seem as reliable as > > secureboot. Alot of issues on threads with some people. It seems > > complicated. even false alarms. But I really do think they are > > supposed to compliment each other. trusted boot and measured boot > > yes? AEM definitely comes in handy for people who would find it > > nescessary to buy new equipment. > > Well, it depends... If you can be reasonably sure that the attacker > did not modify any firmware (eg. the network card), you could simply > reinstall Qubes from a trusted install media and restore VMs from a > backup. This becomes trivial once stateless computers [1] are a thing. > > > But I would still want an encrypted boot, if I was going to use > > aem, and key on a external usb disk, which unfortunately means I > > could not use a sys-usb. Am I wrong about this? Does this change > > in 4.0? > > It is possible to use AEM along with USB qube, you just have to > disable the early hiding of USB devices from dom0. But once Qubes is > fully booted and sys-usb started, you get the full USB qubes protecion. > > > So this is where the what fits into you "security model" What are > > you more concered about. I assumed we had to choose between aem vs > > sys-usb? For people travelling with laptops in strange places > > where physical compromise is more likely aem is a good option. > > Some people would prolly not just buy a new laptop but know when to > > destroy theirs too lol. > > The only trade-off for AEM regarding USB devices is that the USB stick > you buy to install AEM on could be compromised already (straight from > the factory, or intercepted & infected during shipping). And since you > need to plug it directly into dom0 in order to perform the install, it > could exploit USB or filesystem drivers and gain control of dom0. > > So it is kind of a trust-on-first-use scenario for the installation > step only. > > > Cheers, > Patrik > > > [1] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJZpZpBAAoJEFwecd8DH5rlE4gP/3WFFUmqb8ChECEgfgKeDRlz > VdLWPVuG8mnIr8SWeSCbkmgTA4fz1F6BWCv4puTDpADMc/HyXzrxkl6hxPBnSgdb > Rr01lGXkAda0EcSkhEUcuViCTed+yMf2y7gSJdJJrFnWiomeNft3Bq4KlpqA3t86 > r9oofbkH161bGsED8NdTlLFz+uE68gZq7D/ba+xWWJnBM/YT/lWdI29wwZhoJgPn > x6sm4BNE5szbBOwFfV5JXAtCQ8E9K4bF0M8Frvh7DUAa3MsZim3iOmgmavo86Mbm > hLkjN/N4ujxKd3n6YZuA4tqgx4UOxpQWET8jHTMxgHuVd2Dwt6jpl7Uic+3PXoXt > zmoj4BLLhC3vY+8ghPEY7TYNViYCAmAe2LcrNxI4nfUxihLvttR9Nnfut6ENqvDj > oIxRDiDRCWA/ZyC7I9C1ZPiFZ1Jyzy34aFfVF6YCESSvnfI+xGn7XFs+EpVunmiA > jnSxQJTK2Y5Pqh8SLWuMGNPEGr7MF/ekKmIlepn372ftL++2D04kuHvKzn9ZQdun > rC3v7yGuFHHca6Cakj4ks9q4cZ012g2Ch6hE2S8WcTZkEbeequMNEtGYT+9BuWpr > GlLmg5EffaMBxKP6WZuiv6okXyJnVCdBctpxC3qmTeRX4pTn4eaQsr4iXbCkfRnV
Re: [qubes-users] Options for securing /boot
On Thursday, September 7, 2017 at 9:15:31 AM UTC-4, cooloutac wrote: > On Tuesday, August 29, 2017 at 1:09:36 PM UTC-4, Leo Gaspard wrote: > > On 08/29/2017 04:01 PM, cooloutac wrote: > > > On Monday, August 28, 2017 at 6:36:08 PM UTC-4, Leo Gaspard wrote: > > >> Just encrypting /boot would bring little, as it would still be possible > > >> to modify the unencrypted part of GRUB (that decrypts /boot) to have it > > >> overwrite the /boot with malicious kernel images (or even to not use the > > >> ones provided). > > >> > > >> The options I know of are (from IMO strongest to weakest): > > >> * AEM, for knowing when someone tampered with /boot > > >> * SecureBoot, for restricting the allowed-to-boot images (I don't know > > >> about its ease of use with qubes, though) > > >> * locking your bootloader with a password and disallow external boot > > >> > > >> I'd think having all these protections at the same time would be best, > > >> using secureboot mostly to avoid having to ditch the laptop after AEM > > >> says it's no longer trustworthy (because it may stop the attacker before > > >> it can even make the laptop no longer trustworthy). > > > > > > secureboot can do more then restricting boot images, it can restrict > > > unsigned drivers too. Thats the part Joanna doesn't like because she > > > does not trust who will maintain the list of signed drivers. I say I'm > > > already putting just as much trust into alot of other things like my > > > banks ssl cert when connecting to my bank account. > > > > > > We are already trusting everything coming from upstream when we update... > > > > Well it can, but the issue with secureboot I remember reading about in > > the AEM post [1] is that it assumes no security vulnerability in all the > > bootchain (which could be used to trick eg. grub to run another image > > than the one you expect it to), while AEM only assumes no security > > vulnerability in the TPM. > > > > That's why I was putting secureboot forward only as a limited way to > > prevent malicious modifications, in parallel with AEM, that would still > > be used as a more secure way of checking secureboot worked correctly. > > > > [1] https://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html > > well after hacking teams bios exploit was said to be stopped by secure boot > it became a big target last year. there has been a couple exploits for > windows, which have all been patched. But None of them relate to linux at > all. Although nothing is 100%, nor will there ever be. I believe the one exploit had to do with driver test signing in win10, another was leaked keys. Neither would affect a linux secure boot. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/967af6a4-edee-436b-98ec-c817a6380292%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On Tuesday, August 29, 2017 at 1:09:36 PM UTC-4, Leo Gaspard wrote: > On 08/29/2017 04:01 PM, cooloutac wrote: > > On Monday, August 28, 2017 at 6:36:08 PM UTC-4, Leo Gaspard wrote: > >> Just encrypting /boot would bring little, as it would still be possible > >> to modify the unencrypted part of GRUB (that decrypts /boot) to have it > >> overwrite the /boot with malicious kernel images (or even to not use the > >> ones provided). > >> > >> The options I know of are (from IMO strongest to weakest): > >> * AEM, for knowing when someone tampered with /boot > >> * SecureBoot, for restricting the allowed-to-boot images (I don't know > >> about its ease of use with qubes, though) > >> * locking your bootloader with a password and disallow external boot > >> > >> I'd think having all these protections at the same time would be best, > >> using secureboot mostly to avoid having to ditch the laptop after AEM > >> says it's no longer trustworthy (because it may stop the attacker before > >> it can even make the laptop no longer trustworthy). > > > > secureboot can do more then restricting boot images, it can restrict > > unsigned drivers too. Thats the part Joanna doesn't like because she does > > not trust who will maintain the list of signed drivers. I say I'm already > > putting just as much trust into alot of other things like my banks ssl cert > > when connecting to my bank account. > > > > We are already trusting everything coming from upstream when we update... > > Well it can, but the issue with secureboot I remember reading about in > the AEM post [1] is that it assumes no security vulnerability in all the > bootchain (which could be used to trick eg. grub to run another image > than the one you expect it to), while AEM only assumes no security > vulnerability in the TPM. > > That's why I was putting secureboot forward only as a limited way to > prevent malicious modifications, in parallel with AEM, that would still > be used as a more secure way of checking secureboot worked correctly. > > [1] https://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html well after hacking teams bios exploit was said to be stopped by secure boot it became a big target last year. there has been a couple exploits for windows, which have all been patched. But None of them relate to linux at all. Although nothing is 100%, nor will there ever be. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e7436627-706d-4d12-9230-54bc456d1ee5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On 08/30/2017 11:49 AM, wordswithn...@gmail.com wrote: On Tuesday, August 29, 2017 at 7:16:16 PM UTC-4, steve.coleman wrote: If your laptop contains an active TPM and a TCG Opal 2.0 compliant SED (SSD or spinning platter) drive, then you can create a range, install the bootstrap/OS, and then mark that range as read-only. After doing that *nothing* will be able to write to that area without the password unlocking that range first, even Dom0 root user, but then it will also need to be unlocked using that same password at the appropriate moment during any update to the bootstrap/Xen code during appropriate Dom0 updates. This same range can also protect the partition table, MBR, and boot menu, etc. Multiple ranges can be set with different attributes/encryption keys. The tool you would need for doing this is "msed" (name given in my fedora distro) or "sedutil" (from the drive trust alliance) which allows you to talk to the drive via sata (not usb afaik) to encrypt or protect defined ranges that you set up. Just be careful to learn/test on a test system, because if you create an encrypted range everything previously there disappears instantly, including partitions. Its the world fastest way I know to completely wipe a drive, flip one bit in the key, poof. Like magic. You can always reset back to the factory default erasing everything on the drive. Calculate your ranges, partition, setup encryption ranges, and install stuff, then finally mark your /boot range as read-only. Don't encrypt your /boot or you will need to install Pre-Boot-Authentication (PBA) and supply a password at boot time. Sedutil source and docs https://github.com/Drive-Trust-Alliance This is interesting. I suppose this would be a way to secure your system, and then you could add AEM over it? That way you are using the security features of the hardware, but not trusting them. As far as "trusting" the drive, you first need a TPM for this to even work, so not all the apples are in one basket. The key itself is not stored anywhere on the drive, but only a partial entropy seed value which when combined with the users password the drive can then generate the required key on the fly. If used for encrypting your data, all that work is done within the drive hardware thus freeing up your host cpu for other things. If you are the paranoid belt and suspenders kind you can also encrypt your data before it goes to the drive where it gets encrypted yet again automatically. Layers of security are always better. It is possible to have the drive bound and unlocked by a specific TPM/PCR value generated during a trusted boot process. That way not only is your drive not writable by the adversary, but the drive itself must be physically in that specific machine/TPM otherwise it remains as useful to the adversary as a paperweight. In the context of xkcd, even beating you over the head for a password won't help if its not in a correctly booted known state of that specific machine/TPM combination. http://imgs.xkcd.com/comics/security.png For the ultra-ultra-ultra paranoid you can even have a hidden partition table such that it exposes the real drive partitioning only after the drive is unlocked (aka. the 'done bit is set' to expose the shadow MBR). This way you can boot readonly into a stripped down ISO image OS with AEM/trusted boot to check for any extra devices connected, then use the PCR magic hash to finally unlock and expose the real partition table, and then boot again into the actual R/W OS partition. That's the use-case that I'm working on for a pet project of mine. I would think that Whonix devs might like to play with that kind of scenario for providing absolute "plausible deniability" when that subsystem is not in use. When you don't need it, you could not even tell that the partition exists, just unallocated sectors on the drive with (encrypted) garbage bytes in it. Lots of creative things can be done with it, and if you buy a current model SSD it likely comes with Opal 2.0 for free. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8b31845f-cc21-fd9e-f180-43fc5bdd802c%40jhuapl.edu. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/30/2017 05:46 PM, wordswithn...@gmail.com wrote: >> Plus, you always need to disconnect all untrusted USB devices >> while rebooting Qubes, regardless of whether you have USB qube >> set up or not. >> > > I just want to make sure that this is not always the case - > according to https://www.qubes-os.org/doc/usb/, if you create the > USB VM automatically during install, then Qubes will be set to hide > USB devices from dom0 on boot. > >> (Note: Beginning with R3.2, rd.qubes.hide_all_usb is set >> automatically if you opt to create a USB qube during >> installation. This also occurs automatically if you choose to >> create a USB qube using the qubesctl method, which is the first >> pair of steps in the linked section.) > The USB controllers are hidden only from dom0 (via Xen's PCI device blacklisting). BIOS or GRUB can, however, still process the device descriptors or filesystem headers during early boot stages and get exploited. Cheers, Patrik -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZpuS2AAoJEFwecd8DH5rllxMP/3wgSi7gD+2kVnbILbYhcrWn uqzLLYc0xie9B6ou7YwE8ZTDobY5VNDD8hfX5H51fDInhYcdmvkBio1Rd9nXePGO 4II9UYZdpQiKMtRSYpZ2tnjhp1ITtA755hSZOknJZ95o/HPsxqIVg3DYQeBT12jd ZGHNTIQX8OGGJ9NgR6D9dOPhTA4zJemiH7vlD+3zHV8AbMHCgbicOaN6ETNQoB2A 482QsQOERtRjM0qtyvTBhH/UGqQzwtbcTy4HV+3MBQZv3m3UgPXMoUpCVPAXRDqY VZvWPAS2nBayxyQ+2GCxFVFfej1YSfPTcUXfrRfxdbgSuAvmPwBPPrVOWRx8Q3QV NBHeucjLKVS2B/U7AU3OFKj+M5nacMGgMNIIWgNIerzXEq3/QO9M2VNSbc2odzHr PBzI2EGVPxR+OZcnN6QbXBAc+isY+02wWCiL1jtcTZ8WiDi6ZdMZpoGB98hCitCU 82s6aTQjcPm0/39+fUjywuPFne5bom4OIXKVz8W7IO1bTwDSPEUsJWnQMxnn5cJW fZXlm+ILyz55O02Ub6Rz08iK6nlBnjndRZ0P5ne/bawviWk7QVdpATjeVrAVzNKU hmmdQsxG58IXz8WxOIz2kbn+AeNYajkqWf8zLdgseJTUCA2K1m+LhLPWUuQO6uRf H9+OeJz6OMu0vDaN7lhh =LakE -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/950fe2ab-7185-dfb3-d0df-173405c3fe53%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-users] Options for securing /boot
On Tuesday, August 29, 2017 at 7:16:16 PM UTC-4, steve.coleman wrote: > If your laptop contains an active TPM and a TCG Opal 2.0 compliant SED > (SSD or spinning platter) drive, then you can create a range, install > the bootstrap/OS, and then mark that range as read-only. > > After doing that *nothing* will be able to write to that area without > the password unlocking that range first, even Dom0 root user, but then > it will also need to be unlocked using that same password at the > appropriate moment during any update to the bootstrap/Xen code during > appropriate Dom0 updates. This same range can also protect the partition > table, MBR, and boot menu, etc. Multiple ranges can be set with > different attributes/encryption keys. > > The tool you would need for doing this is "msed" (name given in my > fedora distro) or "sedutil" (from the drive trust alliance) which allows > you to talk to the drive via sata (not usb afaik) to encrypt or protect > defined ranges that you set up. > > Just be careful to learn/test on a test system, because if you create an > encrypted range everything previously there disappears instantly, > including partitions. Its the world fastest way I know to completely > wipe a drive, flip one bit in the key, poof. Like magic. You can always > reset back to the factory default erasing everything on the drive. > > Calculate your ranges, partition, setup encryption ranges, and install > stuff, then finally mark your /boot range as read-only. Don't encrypt > your /boot or you will need to install Pre-Boot-Authentication (PBA) and > supply a password at boot time. > > Sedutil source and docs > https://github.com/Drive-Trust-Alliance > This is interesting. I suppose this would be a way to secure your system, and then you could add AEM over it? That way you are using the security features of the hardware, but not trusting them. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8935704e-0147-4df9-8504-b8bd731ad4d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
> Plus, you always need to > disconnect all untrusted USB devices while rebooting Qubes, regardless > of whether you have USB qube set up or not. > I just want to make sure that this is not always the case - according to https://www.qubes-os.org/doc/usb/, if you create the USB VM automatically during install, then Qubes will be set to hide USB devices from dom0 on boot. >(Note: Beginning with R3.2, rd.qubes.hide_all_usb is set automatically if you >opt to create a USB qube during installation. This also occurs automatically >if you choose to create a USB qube using the qubesctl method, which is the >first pair of steps in the linked section.) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/82488fb4-7482-464c-a977-fd4fa06707bf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
If your laptop contains an active TPM and a TCG Opal 2.0 compliant SED (SSD or spinning platter) drive, then you can create a range, install the bootstrap/OS, and then mark that range as read-only. After doing that *nothing* will be able to write to that area without the password unlocking that range first, even Dom0 root user, but then it will also need to be unlocked using that same password at the appropriate moment during any update to the bootstrap/Xen code during appropriate Dom0 updates. This same range can also protect the partition table, MBR, and boot menu, etc. Multiple ranges can be set with different attributes/encryption keys. The tool you would need for doing this is "msed" (name given in my fedora distro) or "sedutil" (from the drive trust alliance) which allows you to talk to the drive via sata (not usb afaik) to encrypt or protect defined ranges that you set up. Just be careful to learn/test on a test system, because if you create an encrypted range everything previously there disappears instantly, including partitions. Its the world fastest way I know to completely wipe a drive, flip one bit in the key, poof. Like magic. You can always reset back to the factory default erasing everything on the drive. Calculate your ranges, partition, setup encryption ranges, and install stuff, then finally mark your /boot range as read-only. Don't encrypt your /boot or you will need to install Pre-Boot-Authentication (PBA) and supply a password at boot time. Sedutil source and docs https://github.com/Drive-Trust-Alliance On 08/26/2017 11:39 AM, cyberian@national.shitposting.agency wrote: Does Qubes offer a method of securing /boot? not just against USB evil maid attacks, but from tampering in general? for example, while a laptop is off, what would stop a malicious user from live booting to an arbitrary distro and altering kernel or xen images located on the unencrypted /boot partition? Does qubes offer options for encrypting /boot? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/85467fc2-f40d-163d-1be2-e79604b1430d%40jhuapl.edu. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/29/2017 07:38 PM, David Hobach wrote: > On 08/29/2017 06:32 PM, cooloutac wrote: >> On Tuesday, August 29, 2017 at 12:25:51 PM UTC-4, cooloutac >> wrote: >>> On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara >>> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency wrote: > Leo Gaspard, > > I have read about AEM but have never used it, it seems like > it is geared towards protecting from USB's with malicious > firmware on them. > > Does AEM actually verify the integrity of /boot before > using? This is what I am looking for, either a method of > encrypting /boot or even better, a secure method to verify > its integrity during boot > AEM does verify the integrity of /boot using the TPM seal/unseal operation. If any of the boot components change, AEM falls back to regular, unmeasured boot -- the user is expected to notice this and cease using the potentially-compromised system (the lack of explicit indication of failed AEM boot is deliberate, see the last FAQ item at [1]). The security provided by AEM is much more stronger than encrypted /boot could ever offer, because as already pointed out, there is always a little first-stage bootloader stub on the disk unencrypted and it would be easy to overwrite it with a malicious version that would intercept the encryption passphrase and exfiltrate it using eg. unused disk sectors. If someone did the above with AEM, the TPM would refuse to useal the AEM secret as the platform state would be different. > > You still have to trust the TPM manufacturer, some closed source > Intel blob and some ITL code, i.e. I'd definitely test changes to > /boot & your BIOS to cause the TPM to deny revealing the secret if > I had to rely on it - the cheapest implementation is an > "everything's ok" on every request after all... Well, of course. You always have to trust *something*. The ultimate goal is to reduce the trusted code base to bare minimum and provide methods for end-users to verify that the code running actually *is* the one advertised by vendor (eg. ITL). > So the strongest method remains OpSec & physical security. This can > also prevent things. Layered security is the best approach, yes. > Moreover the fewest people tend to buy new hardware once they > detect a change via their TPM even though that would be the only > reasonable reaction. So if you don't plan to do that, I'd forget > about AEM. Reasonable reaction always depends on the sophistication level of adversary you're trying to defend against (ie. your defense "budget"). Nation states? Burn the laptop. Opportunistic black-hats? You'll be fine simply reinstalling. Cheers, Patrik -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZpakTAAoJEFwecd8DH5rl1ewP/1Ewz/i4wEEAUizlgDzstwlf 41/2PVh6bvhzb+QhK95O7UxtbHhqFF4NttrkAzlQw7Uwsi/l6i0tRuvAZu7tLTqw KfaQj2F2lGm3GVSNwhuVH2NcZaZ5U3FpBk4/PcP/ONBoLp0blxlIbEvfEfScP9Ly xW1T7sbINqS76qKh42ds9hf8FYrN8vrHMxRYfLZAlmXNZvTIvMpF1YwiZyHiDdrQ vprfXU9dPHEjUN63f22G+CaDCYYXdk/Pb7QDAbA0YuN1tQyxgkgZMB2Ks37A0UD7 vDQBiM91ynU703QOVDr8Icn0otshv/RR+GFxfJPugA+3YUjYN+dOY5c1qAaM4bVZ QoCoe2ApFpEt2HCKq5grm1cge6LEK+d4ym6sjB9PoL4/T4FMq2fnO6s+xoIlvWZZ 1FmQVJtTEmuiaMOHtwxLaM80sD6s/9cq/w7fIMlba86uFlesNOgpkDfm9SoYtQYc 94RT6CAd7CyThn+lhTH3YGNrt320cP/fFPTp4gjHQOf9su7vjtrN7tKVD6o6bD1n PlbRqw40SQRovtTSR5UPJEMlqbScC91aeL/glDXNuXEcz+Jz+YvmHiAi/UCz79k9 XwEc/2wjD5xMw+hmajaXNQOOnUA5VRNJNLuPBOxrZxxBpZef7SV0lcf5WqDkdhq9 QA8qanASHTTQo3y5r9JA =cZ7m -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/37ed7d3f-921e-8cac-adb0-df3e0c1897cd%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-users] Options for securing /boot
On 08/29/2017 06:32 PM, cooloutac wrote: On Tuesday, August 29, 2017 at 12:25:51 PM UTC-4, cooloutac wrote: On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency wrote: Leo Gaspard, I have read about AEM but have never used it, it seems like it is geared towards protecting from USB's with malicious firmware on them. Does AEM actually verify the integrity of /boot before using? This is what I am looking for, either a method of encrypting /boot or even better, a secure method to verify its integrity during boot AEM does verify the integrity of /boot using the TPM seal/unseal operation. If any of the boot components change, AEM falls back to regular, unmeasured boot -- the user is expected to notice this and cease using the potentially-compromised system (the lack of explicit indication of failed AEM boot is deliberate, see the last FAQ item at [1]). The security provided by AEM is much more stronger than encrypted /boot could ever offer, because as already pointed out, there is always a little first-stage bootloader stub on the disk unencrypted and it would be easy to overwrite it with a malicious version that would intercept the encryption passphrase and exfiltrate it using eg. unused disk sectors. If someone did the above with AEM, the TPM would refuse to useal the AEM secret as the platform state would be different. You still have to trust the TPM manufacturer, some closed source Intel blob and some ITL code, i.e. I'd definitely test changes to /boot & your BIOS to cause the TPM to deny revealing the secret if I had to rely on it - the cheapest implementation is an "everything's ok" on every request after all... So the strongest method remains OpSec & physical security. This can also prevent things. Moreover the fewest people tend to buy new hardware once they detect a change via their TPM even though that would be the only reasonable reaction. So if you don't plan to do that, I'd forget about AEM. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e6756da2-fc92-085c-b3ee-df45a2ed1379%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] Options for securing /boot
On 08/29/2017 04:01 PM, cooloutac wrote: > On Monday, August 28, 2017 at 6:36:08 PM UTC-4, Leo Gaspard wrote: >> Just encrypting /boot would bring little, as it would still be possible >> to modify the unencrypted part of GRUB (that decrypts /boot) to have it >> overwrite the /boot with malicious kernel images (or even to not use the >> ones provided). >> >> The options I know of are (from IMO strongest to weakest): >> * AEM, for knowing when someone tampered with /boot >> * SecureBoot, for restricting the allowed-to-boot images (I don't know >> about its ease of use with qubes, though) >> * locking your bootloader with a password and disallow external boot >> >> I'd think having all these protections at the same time would be best, >> using secureboot mostly to avoid having to ditch the laptop after AEM >> says it's no longer trustworthy (because it may stop the attacker before >> it can even make the laptop no longer trustworthy). > > secureboot can do more then restricting boot images, it can restrict > unsigned drivers too. Thats the part Joanna doesn't like because she does > not trust who will maintain the list of signed drivers. I say I'm already > putting just as much trust into alot of other things like my banks ssl cert > when connecting to my bank account. > > We are already trusting everything coming from upstream when we update... Well it can, but the issue with secureboot I remember reading about in the AEM post [1] is that it assumes no security vulnerability in all the bootchain (which could be used to trick eg. grub to run another image than the one you expect it to), while AEM only assumes no security vulnerability in the TPM. That's why I was putting secureboot forward only as a limited way to prevent malicious modifications, in parallel with AEM, that would still be used as a more secure way of checking secureboot worked correctly. [1] https://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7f3bc3ea-d715-5630-bdd5-8eb1d1047086%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/29/2017 06:25 PM, cooloutac wrote: > On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara > wrote: On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency > wrote: Leo Gaspard, I have read about AEM but have never used it, it seems like it is geared towards protecting from USB's with malicious firmware on them. Does AEM actually verify the integrity of /boot before using? This is what I am looking for, either a method of encrypting /boot or even better, a secure method to verify its integrity during boot > > AEM does verify the integrity of /boot using the TPM seal/unseal > operation. If any of the boot components change, AEM falls back to > regular, unmeasured boot -- the user is expected to notice this and > cease using the potentially-compromised system (the lack of > explicit indication of failed AEM boot is deliberate, see the last > FAQ item at [1]). > > The security provided by AEM is much more stronger than encrypted > /boot could ever offer, because as already pointed out, there is > always a little first-stage bootloader stub on the disk > unencrypted and it would be easy to overwrite it with a malicious > version that would intercept the encryption passphrase and > exfiltrate it using eg. unused disk sectors. > > If someone did the above with AEM, the TPM would refuse to useal > the AEM secret as the platform state would be different. > > The feature protecting dom0 from malicious USB devices [2] serves > a different purpose and is not related to AEM. Plus, you always > need to disconnect all untrusted USB devices while rebooting Qubes, > regardless of whether you have USB qube set up or not. > > > Cheers, Patrik > > > [1] > https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html [2] > https://www.qubes-os.org/doc/usb/ > > my problem is unfortunately i can't keep buying new pc's. SO maybe > its all for naught for me.. Also AEM does not seem as reliable as > secureboot. Alot of issues on threads with some people. It seems > complicated. even false alarms. But I really do think they are > supposed to compliment each other. trusted boot and measured boot > yes? AEM definitely comes in handy for people who would find it > nescessary to buy new equipment. Well, it depends... If you can be reasonably sure that the attacker did not modify any firmware (eg. the network card), you could simply reinstall Qubes from a trusted install media and restore VMs from a backup. This becomes trivial once stateless computers [1] are a thing. > But I would still want an encrypted boot, if I was going to use > aem, and key on a external usb disk, which unfortunately means I > could not use a sys-usb. Am I wrong about this? Does this change > in 4.0? It is possible to use AEM along with USB qube, you just have to disable the early hiding of USB devices from dom0. But once Qubes is fully booted and sys-usb started, you get the full USB qubes protecion. > So this is where the what fits into you "security model" What are > you more concered about. I assumed we had to choose between aem vs > sys-usb? For people travelling with laptops in strange places > where physical compromise is more likely aem is a good option. > Some people would prolly not just buy a new laptop but know when to > destroy theirs too lol. The only trade-off for AEM regarding USB devices is that the USB stick you buy to install AEM on could be compromised already (straight from the factory, or intercepted & infected during shipping). And since you need to plug it directly into dom0 in order to perform the install, it could exploit USB or filesystem drivers and gain control of dom0. So it is kind of a trust-on-first-use scenario for the installation step only. Cheers, Patrik [1] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZpZpBAAoJEFwecd8DH5rlE4gP/3WFFUmqb8ChECEgfgKeDRlz VdLWPVuG8mnIr8SWeSCbkmgTA4fz1F6BWCv4puTDpADMc/HyXzrxkl6hxPBnSgdb Rr01lGXkAda0EcSkhEUcuViCTed+yMf2y7gSJdJJrFnWiomeNft3Bq4KlpqA3t86 r9oofbkH161bGsED8NdTlLFz+uE68gZq7D/ba+xWWJnBM/YT/lWdI29wwZhoJgPn x6sm4BNE5szbBOwFfV5JXAtCQ8E9K4bF0M8Frvh7DUAa3MsZim3iOmgmavo86Mbm hLkjN/N4ujxKd3n6YZuA4tqgx4UOxpQWET8jHTMxgHuVd2Dwt6jpl7Uic+3PXoXt zmoj4BLLhC3vY+8ghPEY7TYNViYCAmAe2LcrNxI4nfUxihLvttR9Nnfut6ENqvDj oIxRDiDRCWA/ZyC7I9C1ZPiFZ1Jyzy34aFfVF6YCESSvnfI+xGn7XFs+EpVunmiA jnSxQJTK2Y5Pqh8SLWuMGNPEGr7MF/ekKmIlepn372ftL++2D04kuHvKzn9ZQdun rC3v7yGuFHHca6Cakj4ks9q4cZ012g2Ch6hE2S8WcTZkEbeequMNEtGYT+9BuWpr GlLmg5EffaMBxKP6WZuiv6okXyJnVCdBctpxC3qmTeRX4pTn4eaQsr4iXbCkfRnV ODlfYMpurBuNhFfuwiSw =ANmo -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To
Re: [qubes-users] Options for securing /boot
On Tuesday, August 29, 2017 at 12:25:51 PM UTC-4, cooloutac wrote: > On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency wrote: > > > Leo Gaspard, > > > > > > I have read about AEM but have never used it, it seems like it is > > > geared towards protecting from USB's with malicious firmware on > > > them. > > > > > > Does AEM actually verify the integrity of /boot before using? This > > > is what I am looking for, either a method of encrypting /boot or > > > even better, a secure method to verify its integrity during boot > > > > > > > AEM does verify the integrity of /boot using the TPM seal/unseal > > operation. If any of the boot components change, AEM falls back to > > regular, unmeasured boot -- the user is expected to notice this and > > cease using the potentially-compromised system (the lack of explicit > > indication of failed AEM boot is deliberate, see the last FAQ item at > > [1]). > > > > The security provided by AEM is much more stronger than encrypted > > /boot could ever offer, because as already pointed out, there is > > always a little first-stage bootloader stub on the disk unencrypted > > and it would be easy to overwrite it with a malicious version that > > would intercept the encryption passphrase and exfiltrate it using eg. > > unused disk sectors. > > > > If someone did the above with AEM, the TPM would refuse to useal the > > AEM secret as the platform state would be different. > > > > The feature protecting dom0 from malicious USB devices [2] serves a > > different purpose and is not related to AEM. Plus, you always need to > > disconnect all untrusted USB devices while rebooting Qubes, regardless > > of whether you have USB qube set up or not. > > > > > > Cheers, > > Patrik > > > > > > [1] https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html > > [2] https://www.qubes-os.org/doc/usb/ > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v2 > > > > iQIcBAEBCAAGBQJZpYp/AAoJEFwecd8DH5rlYLsP/iV4ZHkYPAzWp8aNHMXaZ4sc > > 1yZaYE4v2jvdnVdOV2Y7Rxny+4wKAhv3W/XDgW+PDc5HkM41+OyA516/rzapZk/t > > /Qa3og/ciZwT0DTMaB31mJ+1mj6IYyPfxOk0tKfK8zNp6UwzlNPrE0mhkT8nTt32 > > M85Bcju5ighXVPyMD8c1v+y6eRLrFTPN9tsfMTH/PUOP/ogPjNbLByz/W3zAoVyO > > CvylzRiJM2XfGDdYrAF1qcOQi3bkgxiL29Wy3C8fDbfkBcDMz3Br7NOpYtZSpetH > > umpEp0RcRybmlXszp2i2GItzRCIdPNAd1QtWCK6lT41CbiNlm+QHwd9Z3mzWZgRN > > JaikqWN6haLRORZO5r+vhFb5mRrV5y9uWblXFPQrsgkkUCM7UtmK9jfnFqFSQbO2 > > yP6ork3mUuGzHZzt7oc2PfpjYE55CU/wxM6C10QErZvA0+eDYzhkx+Rh/Eaoporz > > Ad2zF0G0BBUjJ0mt4HPpomL5fTAZoZnoqEFK1Xe7m7VYDklINIgVGYjhi4Ektbma > > VSW6PfXTUs9Be816pxFSCg9n8GlU0fsdp/1xFitRWCUv69aV7jFs+YsCn+XhuZzF > > vjqLp97hDDElv8Gzd5/R/tuQmmdmvXmJN3olp++mnjLCceIHq6JTlT3KTAgX/sFB > > jKp0HqjSdwU7USBWIo7B > > =nrKy > > -END PGP SIGNATURE- > > my problem is unfortunately i can't keep buying new pc's. SO maybe its all > for naught for me.. Also AEM does not seem as reliable as secureboot. Alot of > issues on threads with some people. It seems complicated. even false alarms. > But I really do think they are supposed to compliment each other. trusted > boot and measured boot yes? AEM definitely comes in handy for people who > would find it nescessary to buy new equipment. > > But I would still want an encrypted boot, if I was going to use aem, and key > on a external usb disk, which unfortunately means I could not use a sys-usb. > Am I wrong about this? Does this change in 4.0? > > So this is where the what fits into you "security model" What are you more > concered about. I assumed we had to choose between aem vs sys-usb? For > people travelling with laptops in strange places where physical compromise is > more likely aem is a good option. Some people would prolly not just buy a > new laptop but know when to destroy theirs too lol. Doesn't everyone destroy hdd's and phones when they bricked our outdated and you done with them like Hillary? I always tell myself i'm going to and just have them stacked in a box, cause nothing really that sensitive on there. But I feel it should be good common practice. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b5421ba2-b301-4851-87f0-4e5ca698c8bf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency wrote: > > Leo Gaspard, > > > > I have read about AEM but have never used it, it seems like it is > > geared towards protecting from USB's with malicious firmware on > > them. > > > > Does AEM actually verify the integrity of /boot before using? This > > is what I am looking for, either a method of encrypting /boot or > > even better, a secure method to verify its integrity during boot > > > > AEM does verify the integrity of /boot using the TPM seal/unseal > operation. If any of the boot components change, AEM falls back to > regular, unmeasured boot -- the user is expected to notice this and > cease using the potentially-compromised system (the lack of explicit > indication of failed AEM boot is deliberate, see the last FAQ item at > [1]). > > The security provided by AEM is much more stronger than encrypted > /boot could ever offer, because as already pointed out, there is > always a little first-stage bootloader stub on the disk unencrypted > and it would be easy to overwrite it with a malicious version that > would intercept the encryption passphrase and exfiltrate it using eg. > unused disk sectors. > > If someone did the above with AEM, the TPM would refuse to useal the > AEM secret as the platform state would be different. > > The feature protecting dom0 from malicious USB devices [2] serves a > different purpose and is not related to AEM. Plus, you always need to > disconnect all untrusted USB devices while rebooting Qubes, regardless > of whether you have USB qube set up or not. > > > Cheers, > Patrik > > > [1] https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html > [2] https://www.qubes-os.org/doc/usb/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJZpYp/AAoJEFwecd8DH5rlYLsP/iV4ZHkYPAzWp8aNHMXaZ4sc > 1yZaYE4v2jvdnVdOV2Y7Rxny+4wKAhv3W/XDgW+PDc5HkM41+OyA516/rzapZk/t > /Qa3og/ciZwT0DTMaB31mJ+1mj6IYyPfxOk0tKfK8zNp6UwzlNPrE0mhkT8nTt32 > M85Bcju5ighXVPyMD8c1v+y6eRLrFTPN9tsfMTH/PUOP/ogPjNbLByz/W3zAoVyO > CvylzRiJM2XfGDdYrAF1qcOQi3bkgxiL29Wy3C8fDbfkBcDMz3Br7NOpYtZSpetH > umpEp0RcRybmlXszp2i2GItzRCIdPNAd1QtWCK6lT41CbiNlm+QHwd9Z3mzWZgRN > JaikqWN6haLRORZO5r+vhFb5mRrV5y9uWblXFPQrsgkkUCM7UtmK9jfnFqFSQbO2 > yP6ork3mUuGzHZzt7oc2PfpjYE55CU/wxM6C10QErZvA0+eDYzhkx+Rh/Eaoporz > Ad2zF0G0BBUjJ0mt4HPpomL5fTAZoZnoqEFK1Xe7m7VYDklINIgVGYjhi4Ektbma > VSW6PfXTUs9Be816pxFSCg9n8GlU0fsdp/1xFitRWCUv69aV7jFs+YsCn+XhuZzF > vjqLp97hDDElv8Gzd5/R/tuQmmdmvXmJN3olp++mnjLCceIHq6JTlT3KTAgX/sFB > jKp0HqjSdwU7USBWIo7B > =nrKy > -END PGP SIGNATURE- my problem is unfortunately i can't keep buying new pc's. SO maybe its all for naught for me.. Also AEM does not seem as reliable as secureboot. Alot of issues on threads with some people. It seems complicated. even false alarms. But I really do think they are supposed to compliment each other. trusted boot and measured boot yes? AEM definitely comes in handy for people who would find it nescessary to buy new equipment. But I would still want an encrypted boot, if I was going to use aem, and key on a external usb disk, which unfortunately means I could not use a sys-usb. Am I wrong about this? Does this change in 4.0? So this is where the what fits into you "security model" What are you more concered about. I assumed we had to choose between aem vs sys-usb? For people travelling with laptops in strange places where physical compromise is more likely aem is a good option. Some people would prolly not just buy a new laptop but know when to destroy theirs too lol. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5148d2df-885a-4484-862f-93b679fc81b0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/29/2017 04:50 PM, cyberian@national.shitposting.agency wrote: > Leo Gaspard, > > I have read about AEM but have never used it, it seems like it is > geared towards protecting from USB's with malicious firmware on > them. > > Does AEM actually verify the integrity of /boot before using? This > is what I am looking for, either a method of encrypting /boot or > even better, a secure method to verify its integrity during boot > AEM does verify the integrity of /boot using the TPM seal/unseal operation. If any of the boot components change, AEM falls back to regular, unmeasured boot -- the user is expected to notice this and cease using the potentially-compromised system (the lack of explicit indication of failed AEM boot is deliberate, see the last FAQ item at [1]). The security provided by AEM is much more stronger than encrypted /boot could ever offer, because as already pointed out, there is always a little first-stage bootloader stub on the disk unencrypted and it would be easy to overwrite it with a malicious version that would intercept the encryption passphrase and exfiltrate it using eg. unused disk sectors. If someone did the above with AEM, the TPM would refuse to useal the AEM secret as the platform state would be different. The feature protecting dom0 from malicious USB devices [2] serves a different purpose and is not related to AEM. Plus, you always need to disconnect all untrusted USB devices while rebooting Qubes, regardless of whether you have USB qube set up or not. Cheers, Patrik [1] https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html [2] https://www.qubes-os.org/doc/usb/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZpYp/AAoJEFwecd8DH5rlYLsP/iV4ZHkYPAzWp8aNHMXaZ4sc 1yZaYE4v2jvdnVdOV2Y7Rxny+4wKAhv3W/XDgW+PDc5HkM41+OyA516/rzapZk/t /Qa3og/ciZwT0DTMaB31mJ+1mj6IYyPfxOk0tKfK8zNp6UwzlNPrE0mhkT8nTt32 M85Bcju5ighXVPyMD8c1v+y6eRLrFTPN9tsfMTH/PUOP/ogPjNbLByz/W3zAoVyO CvylzRiJM2XfGDdYrAF1qcOQi3bkgxiL29Wy3C8fDbfkBcDMz3Br7NOpYtZSpetH umpEp0RcRybmlXszp2i2GItzRCIdPNAd1QtWCK6lT41CbiNlm+QHwd9Z3mzWZgRN JaikqWN6haLRORZO5r+vhFb5mRrV5y9uWblXFPQrsgkkUCM7UtmK9jfnFqFSQbO2 yP6ork3mUuGzHZzt7oc2PfpjYE55CU/wxM6C10QErZvA0+eDYzhkx+Rh/Eaoporz Ad2zF0G0BBUjJ0mt4HPpomL5fTAZoZnoqEFK1Xe7m7VYDklINIgVGYjhi4Ektbma VSW6PfXTUs9Be816pxFSCg9n8GlU0fsdp/1xFitRWCUv69aV7jFs+YsCn+XhuZzF vjqLp97hDDElv8Gzd5/R/tuQmmdmvXmJN3olp++mnjLCceIHq6JTlT3KTAgX/sFB jKp0HqjSdwU7USBWIo7B =nrKy -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/38703b18-acec-7c59-d2ec-257a84e9021e%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-users] Options for securing /boot
Leo Gaspard, I have read about AEM but have never used it, it seems like it is geared towards protecting from USB's with malicious firmware on them. Does AEM actually verify the integrity of /boot before using? This is what I am looking for, either a method of encrypting /boot or even better, a secure method to verify its integrity during boot -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/77614078-04f4-42b1-b57b-b22bd54103d9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On Monday, August 28, 2017 at 6:36:08 PM UTC-4, Leo Gaspard wrote: > Just encrypting /boot would bring little, as it would still be possible > to modify the unencrypted part of GRUB (that decrypts /boot) to have it > overwrite the /boot with malicious kernel images (or even to not use the > ones provided). > > The options I know of are (from IMO strongest to weakest): > * AEM, for knowing when someone tampered with /boot > * SecureBoot, for restricting the allowed-to-boot images (I don't know > about its ease of use with qubes, though) > * locking your bootloader with a password and disallow external boot > > I'd think having all these protections at the same time would be best, > using secureboot mostly to avoid having to ditch the laptop after AEM > says it's no longer trustworthy (because it may stop the attacker before > it can even make the laptop no longer trustworthy). > > > On 08/28/2017 09:48 PM, Unman wrote: > > On Sat, Aug 26, 2017 at 08:39:23AM -0700, > > cyberian@national.shitposting.agency wrote: > >> Does Qubes offer a method of securing /boot? not just against USB evil > >> maid attacks, but from tampering in general? > >> > >> for example, while a laptop is off, what would stop a malicious user from > >> live booting to an arbitrary distro and altering kernel or xen images > >> located on the unencrypted /boot partition? > >> > >> Does qubes offer options for encrypting /boot? > >> > > > > The Fedora installer wont allow an encrypted boot partition, but there's > > nothing stopping you from encrypting /boot after installation. You will, > > of course, have to reconfigure grub to decrypt the new /boot, but that's > > straightforward. > > > > > > secureboot can do more then restricting boot images, it can restrict unsigned drivers too. Thats the part Joanna doesn't like because she does not trust who will maintain the list of signed drivers. I say I'm already putting just as much trust into alot of other things like my banks ssl cert when connecting to my bank account. We are already trusting everything coming from upstream when we update... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/17709195-8382-493a-abe0-3fe3d5b5c713%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
Just encrypting /boot would bring little, as it would still be possible to modify the unencrypted part of GRUB (that decrypts /boot) to have it overwrite the /boot with malicious kernel images (or even to not use the ones provided). The options I know of are (from IMO strongest to weakest): * AEM, for knowing when someone tampered with /boot * SecureBoot, for restricting the allowed-to-boot images (I don't know about its ease of use with qubes, though) * locking your bootloader with a password and disallow external boot I'd think having all these protections at the same time would be best, using secureboot mostly to avoid having to ditch the laptop after AEM says it's no longer trustworthy (because it may stop the attacker before it can even make the laptop no longer trustworthy). On 08/28/2017 09:48 PM, Unman wrote: > On Sat, Aug 26, 2017 at 08:39:23AM -0700, > cyberian@national.shitposting.agency wrote: >> Does Qubes offer a method of securing /boot? not just against USB evil maid >> attacks, but from tampering in general? >> >> for example, while a laptop is off, what would stop a malicious user from >> live booting to an arbitrary distro and altering kernel or xen images >> located on the unencrypted /boot partition? >> >> Does qubes offer options for encrypting /boot? >> > > The Fedora installer wont allow an encrypted boot partition, but there's > nothing stopping you from encrypting /boot after installation. You will, > of course, have to reconfigure grub to decrypt the new /boot, but that's > straightforward. > > > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3bb3a4b8-f63d-5ccd-bdbb-7905c725901e%40gaspard.io. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On Sat, Aug 26, 2017 at 08:39:23AM -0700, cyberian@national.shitposting.agency wrote: > Does Qubes offer a method of securing /boot? not just against USB evil maid > attacks, but from tampering in general? > > for example, while a laptop is off, what would stop a malicious user from > live booting to an arbitrary distro and altering kernel or xen images located > on the unencrypted /boot partition? > > Does qubes offer options for encrypting /boot? > The Fedora installer wont allow an encrypted boot partition, but there's nothing stopping you from encrypting /boot after installation. You will, of course, have to reconfigure grub to decrypt the new /boot, but that's straightforward. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170828194846.vgnomwjwpl4f6zeg%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Options for securing /boot
Does Qubes offer a method of securing /boot? not just against USB evil maid attacks, but from tampering in general? for example, while a laptop is off, what would stop a malicious user from live booting to an arbitrary distro and altering kernel or xen images located on the unencrypted /boot partition? Does qubes offer options for encrypting /boot? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1735810b-d749-43de-a80d-54c8cc2f362c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
