Options for securing /boot
cybe...@national.shitposting.agency
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?
cooloutac
This is one reason dual booting is not recommended. There is not much you can do. Maybe disable external boot in bios and make a bios password and lock the case? Don't think that would matter though for remote attacks if dom0 is compromised. Also won't matter if your system has ME/Vpro enabled cause then an attacker then wouldn't need any os at all to comporomise the bios or /boot.
Although not all, I still think secure boot is the answer for alot of these type of situations. Its so beneficial even Richard Stallman said its ok to use as a security feature in its current state. Even the closed source proprietary argument doesn't make any sense anymore regarding secure boot. Why some people are still against it I'm not sure.
I don't think AEM is a good alternative at all. I keep feeling like we should be able to do both. Joanna's argument against secure boot relates to driver signing which secure boot can verify, and how we have to trust whoever is running the sort of certificate authority.
But I'm already trusting ssl certs all over the web, which is alot worse. I still think its better then nothing. I think the real issue is that secure boot is probably very complicated to implement and the ITL team have other priorities.
I'm not trying to have privacy as much from the government, as I am security from everyone else.
Unman
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.
Leo Gaspard
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).
cooloutac
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...
cybe...@national.shitposting.agency
I currently have upgraded to 4.0rc1 and love the choice to use HVM over PV.
The reason I was thinking about is the scenario that I use a disposable, live-boot linux the next time I go to this location. If the live-boot linux session were hijacked somehow, the Qubes /boot volume would be exposed.
Now with the release of Qubes 4.0 I would probably be better off just using Qubes, but if I could encrypt /boot I think I would be better off using the disposable live-boot method.
I like the idea suggested by Unman, this is exactly what I wanted to do with Grub2, I just did not want to break anything in Qubes by doing so.
Has anyone had any experience using Grub2 to encrypt the /boot partition and can confirm that it wont break anything with Qubes?
cybe...@national.shitposting.agency
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
Patrik Hagara
Hash: SHA256
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-----
cybe...@national.shitposting.agency
Much appreciated.
cooloutac
the vm failed to return all money, I'm not sure of the exact message, happens to all of us in Qubes, its not too suspicious. You can always just wipe the vm and make another one if you get worried. I usually keep qubes manager on top at all times so I can see when a yellow triangle appears near a vm.
Also a common one is if the vm failes to start qrexec or something oh god i'm terrible with the file names. This can happen cause race conditions like if you start it before another one starts that it needs or loading another vm at same time. nothing to be too alarmed about unless other things are also happening on that vm. like other error messages.
cooloutac
don't know what I will do though when they remove qubes-manager in 4.0 lol.
cooloutac
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.
cooloutac
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.
Patrik Hagara
Hash: SHA256
> On Tuesday, August 29, 2017 at 11:38:59 AM UTC-4, Patrik Hagara
> 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.
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?
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.
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
Version: GnuPG v2
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-----
Leo Gaspard
> 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).
>
>
> We are already trusting everything coming from upstream when we update...
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
David Hobach
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.
Patrik Hagara
Hash: SHA256
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.
> 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.
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
Version: GnuPG v2
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-----
Steve Coleman
(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
wordsw...@gmail.com
> 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.)
wordsw...@gmail.com
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.
Patrik Hagara
Hash: SHA256
blacklisting). BIOS or GRUB can, however, still process the device
descriptors or filesystem headers during early boot stages and get
exploited.
Cheers,
Patrik
Version: GnuPG v2
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-----
Steve Coleman
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.
cooloutac
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.
cooloutac
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.
cooloutac
Doesn't Qubes assume the netcard will be compromised, hence untrusted.
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?
Patrik Hagara
Hash: SHA256
> On Tuesday, August 29, 2017 at 12:46:04 PM UTC-4, Patrik Hagara
> untrusted.
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?
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 stick).
In case the available version does not do this, one possible
work-around is disabling sys-usb VM auto-start and start it manually
after unplugging the AEM stick. This should IMO be the recommended
thing to do anyway, as otherwise it is difficult and potentially
insecure to update AEM/Xen/kernel stored on the stick, as you need to
shut down sys-usb and manually re-assign the USB controller to dom0,
which, if sys-usb was compromised and somehow altered the USB
controller incapable of doing a proper PCI Function Level Reset (AFAIK
this HW feature is commonly broken, especially for GPUs), it could
gain control of dom0.
Cheers,
Patrik
Version: GnuPG v2
TMJTRJkczaBC38i/yNvN2vTDst7EArQYyViyKL1gSdTlbkkaDy1gvg3loav0Nc3I
a6Bqnp046uY04152QFCaONFw/TyfN5eLLUYrLfKwtB5TIEVY7bBRkuMkbTnJO+DB
VzTdtKY6vCAaFm30e8GDhj/9bfwTz0Y8hPTpJTCZ37BcYl52OjPhQ3VsrRjVorf8
3JtfxlJXMuU3Ap6vaM+HdhoJKKjraAasNYlwuJXjPWzBpuWYWEmMFohfkCdFr1N/
Gli4q4zS/QUHChxCSTHY5q4SOfAGWcBugGlWpW0GEgbi+bmXB4SAsFTmMDhg1nXo
A85n0/idbJU5d7xOzTrfaA+uDAXueAktnACjTZ9CTplMGv0hBGOY9dp8N3a+UTHr
dipgjZDpc+FByZLR1wZ89899T+lDDnzCU38/knhCsmlnxdhCd1mzspjWIir/Ngfs
C/WKc5P4gHFEJNQmsU3lEAFX80dvG7NcYo8zEwppGYFQY8afpepvsifLHl8YnEdX
xuR9BRKd626KiHEAPxXAHjCfJOkM+l3Oyq+hg8GDvJft6YjTarfPA2c/52y7hZej
UW/pYuKJbK+Nkwsqxu8p6I1qf/MtWf6HsI+m5+e33FKnu/qY+oA+j1ETM1aOnN1I
BYXLyrZLwh+4dhWknEU8
=RDNz
-----END PGP SIGNATURE-----
cooloutac
only problem with remembering to start the sys-usb is we all forget sometimes.
cooloutac
though maybe for the next final release I will try aem too tks for the info. Although probably should only be doing it once I buy new hardwar. Its probably already too late for me lol, but i'm sure other changes could potentially happen as well.
Tai...@gmx.com
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.
Leo Gaspard
> 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.
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.
Tai...@gmx.com
> 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).
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.
cooloutac
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?
Tai...@gmx.com
> 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?
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.
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.