[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GRUB and boot partition



On Tue, Dec 26, 2017 at 11:59:18AM +0100, tomas@tuxteam.de wrote:
> On Tue, Dec 26, 2017 at 01:47:23PM +0300, Reco wrote:
> > 	Hi.
> > 
> > On Tue, Dec 26, 2017 at 11:36:13AM +0100, tomas@tuxteam.de wrote:
> > > On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote:
> > > > Le 26/12/2017 à 02:47, microsoft gaofei a écrit :
> > > > >https://wiki.archlinux.org/index.php/GRUB#Boot_partition
> > > > >ArchWiki has carried an introduction of GRUB , it offers a feature to decrypt your partitions and you don't need to separate /boot . Debian also uses GRUB as its boot loader ,but Debian still separates /boot partition and leave it unencrypted
> > > 
> > > [...]
> > > 
> > > > Note however that in any case, the early part of GRUB cannot be
> > > > encrypted [...]
> > > 
> > > Is there any inherent advantage to having /boot encrypted?
> > 
> > Presumably it should help with scenario such as [1].
> 
> I don't see that: there must be an unencrypted bit at the beginning
> to boot and ask for the passphrase. Whether it's Grub's first stage
> (plus a bit) or it's a kernel plus initramfs, actually, shouldn't
> make a difference.

I don't see any difference too, hence I wrote 'presumably'.


> The only things which might help against an evil maid attack [1] are:
> secure boot (tying your bootable to secure firmware) [3],

There's this saying about curing a headache with an axe.
Restricted Boot (let's call the thing the way it should be called from
the start) could've solve this problem *if* it would be possible to
force it to verify the bootloader (or the kernel) signed with *user*
key.
But, the things being as they are, Restricted Boot is merely a tool to
achieve market dominance for a certain corporation.

Whenever Restricted Boot is broken or not is hardly relevant here.


> or carrying
> your boot media (e.g. SD card) with you, be it Grub+crypto, be it
> Grub+kernel+initramfs. Again, not much difference.

Indeed.

> 
> > But, as [2] shows us, the protection that's offered by encrypted boot is
> > incomplete as it relies on the fact that the bootloader (GRUB) was not
> > touched.
> 
> Seems we are in violent agreement, then :-)

True.


> [3] Given the games we've seen Intel play with their Management
>    Engine lately...

I beg your pardon? Both Intel *and* AMD play this game for last eight
years since they invented TPM chip.

> would you trust them with that secure boot thing?
> I know wouldn't. And no, AMD ain't better.

It's really strange to answer such question here, at debian-user.
It's non-free software. Nobody sane should trust non-free software.

Reco


Reply to: