Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #190272 > unrolled thread

GRUB and boot partition

Back to article view | Back to linux.debian.user

Contents

  GRUB and boot partition microsoft gaofei <wangziheng@outlook.com> - 2017-12-26 03:40 +0100
    Re: GRUB and boot partition Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 10:50 +0100
      Re: GRUB and boot partition <tomas@tuxteam.de> - 2017-12-26 11:40 +0100
        Re: GRUB and boot partition Reco <recoverym4n@gmail.com> - 2017-12-26 11:50 +0100
          Re: GRUB and boot partition <tomas@tuxteam.de> - 2017-12-26 12:00 +0100
            Re: GRUB and boot partition Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 12:30 +0100
              Re: GRUB and boot partition <tomas@tuxteam.de> - 2017-12-26 12:40 +0100
            Re: GRUB and boot partition Reco <recoverym4n@gmail.com> - 2017-12-26 14:00 +0100
              Re: GRUB and boot partition Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 14:30 +0100
                Re: GRUB and boot partition Reco <recoverym4n@gmail.com> - 2017-12-26 14:50 +0100
                Re: GRUB and boot partition <tomas@tuxteam.de> - 2017-12-26 15:00 +0100
        Re: GRUB and boot partition Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 12:20 +0100
          Re: GRUB and boot partition <tomas@tuxteam.de> - 2017-12-26 12:30 +0100
            Re: GRUB and boot partition Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 12:40 +0100
              Re: GRUB and boot partition <tomas@tuxteam.de> - 2017-12-26 12:50 +0100

#190272 — GRUB and boot partition

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#190277

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

Indeed the Debian installer does not allow an encrypted /boot partition. 
IMO it should be treated as a (strong) warning, not as a blocking error.

You can still manage to have /boot encrypted on Debian with extra manual 
steps. The Debian 8 installer had a flaw that could be exploited : it 
did not detect when /boot was an LVM logical volume in an encrypted PV. 
But this trick does not seem to work any more with the Debian 9 installer.

Note however that in any case, the early part of GRUB cannot be 
encrypted. It is that part which asks for the passphrase. If you use 
encryption only for confidentiality (in case of loss or theft of the 
computer), it probably does not matter that /boot is not encrypted, 
because it usually does not contain any sensitive data. But if you use 
encryption for tamper-proof, then encrypting /boot is not enough, 
because someone with physical access to the computer could tamper with 
the unencrypted part of GRUB and modify it to install a keylogger, 
rootkit...

[toc] | [prev] | [next] | [standalone]

#190279

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCJh0ACgkQBcgs9XrR2kaKHgCfd4gQR/kFEAuYIb+EHKgj/gzw
Lt4An2c+umNQMn8yDQ8GddyzO6WquVDM
=dHDa
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#190280

	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].
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.

[1] http://searchsecurity.techtarget.com/definition/evil-maid-attack
[2] https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html

Reco

[toc] | [prev] | [next] | [standalone]

#190281

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

The only things which might help against an evil maid attack [1] are:
secure boot (tying your bootable to secure firmware) [3], or carrying
your boot media (e.g. SD card) with you, be it Grub+crypto, be it
Grub+kernel+initramfs. Again, not much difference.

> 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 :-)

I'm not really happy about the path the bootloader has taken, having to
understand different file systems, having a module system, etc.

Cheers

[1] http://searchsecurity.techtarget.com/definition/evil-maid-attack
[2] https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html
[3] Given the games we've seen Intel play with their Management
   Engine lately... would you trust them with that secure boot
   thing? I know wouldn't. And no, AMD ain't better.

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCK4YACgkQBcgs9XrR2kYWyQCeK01kZYgaeBxKDC9+0WQNpybr
Q1QAn3foaKmg4w4SqAqTmRP+ugX1OZsK
=0Qk0
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#190285

Le 26/12/2017 à 11:59, tomas@tuxteam.de a écrit :
> 
> The only things which might help against an evil maid attack [1] are:
> secure boot (tying your bootable to secure firmware)

Only if you replacy the default keys with your own key in the firmware. 
Any signed GRUB provided by Ubuntu, RedHat or openSUSE is accepted by 
UEFI secure boot with the default Microsoft key.

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

As explained in my previous reply, the difference is only in 
convenience. You need the boot media to be present and writable when 
updating when updating the kernel, initramfs and GRUB config file if 
/boot is stored on it. On the other hand, if /boot is stored (and 
encrypted) on the main disk, you do not need the boot media to be 
present and writable.

[toc] | [prev] | [next] | [standalone]

#190286

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Dec 26, 2017 at 12:26:35PM +0100, Pascal Hambourg wrote:

[...]

> As explained in my previous reply, the difference is only in
> convenience. You need the boot media to be present and writable when
> updating when updating the kernel [...]

Yes, I see your point. Then, this one cuts both ways...

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCMu8ACgkQBcgs9XrR2kbDtQCfd8QyQBBPDEVRE0ytvuXtv9Mq
NJMAn3ZgzhugBAUCtX4C4+ihwO8TsBvX
=LO8n
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#190293

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

[toc] | [prev] | [next] | [standalone]

#190295

Le 26/12/2017 à 13:58, Reco a écrit :
> On Tue, Dec 26, 2017 at 11:59:18AM +0100, tomas@tuxteam.de wrote:
>>>>
>>>> Is there any inherent advantage to having /boot encrypted?
> 
>> The only things which might help against an evil maid attack [1] are:
>> secure boot (tying your bootable to secure firmware) [3],
> 
> 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.

I read that some UEFI implementations allow the user to manage secure 
boot keys. Carefully choose your hardware.

Oh, by the way I forgot twice to mention another situation when an 
encrypted /boot would provide an advantage : when the machine has a 
platform firwmare which supports LUKS encryption, such as CoreBoot, then 
the on-disk boot components could be entirely encrypted.

[toc] | [prev] | [next] | [standalone]

#190297

On Tue, Dec 26, 2017 at 02:24:24PM +0100, Pascal Hambourg wrote:
> Le 26/12/2017 à 13:58, Reco a écrit :
> > On Tue, Dec 26, 2017 at 11:59:18AM +0100, tomas@tuxteam.de wrote:
> > > > > 
> > > > > Is there any inherent advantage to having /boot encrypted?
> > 
> > > The only things which might help against an evil maid attack [1] are:
> > > secure boot (tying your bootable to secure firmware) [3],
> > 
> > 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.
> 
> I read that some UEFI implementations allow the user to manage secure boot
> keys. Carefully choose your hardware.

I'd use term 'elusive' to describe that kind of UEFI implementation.

Everything that can be bought here (I'm talking about x86 consumer-grade
hardware, of course) respects MSFT signing key only. If you're lucky,
your hardware has CSM (aka BIOS emulation mode).


> Oh, by the way I forgot twice to mention another situation when an encrypted
> /boot would provide an advantage : when the machine has a platform firwmare
> which supports LUKS encryption, such as CoreBoot, then the on-disk boot
> components could be entirely encrypted.

... and about the only trouble you have then is to locate that ThinkPad
x220 (the only relatively modern laptop model that supports CoreBoot
without a hassle I know of). Or a Chromebook if they still but SeaBIOS
inside those.

If you're preferring conventional desktop PC - you're out of luck with
CoreBoot.

Reco

[toc] | [prev] | [next] | [standalone]

#190299

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Dec 26, 2017 at 02:24:24PM +0100, Pascal Hambourg wrote:

[...]

> I read that some UEFI implementations allow the user to manage
> secure boot keys. Carefully choose your hardware.
> 
> Oh, by the way I forgot twice to mention another situation when an
> encrypted /boot would provide an advantage : when the machine has a
> platform firwmare which supports LUKS encryption, such as CoreBoot,
> then the on-disk boot components could be entirely encrypted.

Granted. But if I were *that* deep in the thicket, I'd either shell
out the 5K for a PowerPC workstation (which doesn't seem to have all
that ME stuff... or they don't tell you?) *or* wait for lowRISC or
similar. Doing encrypted-to-the-bottom in view of Intel ME or
AMD TrustZone has a bit of a futile taste to me.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCU5gACgkQBcgs9XrR2kbj9wCZAd7YWlsxOiJA5JlA0XBe3/D+
LQcAnjNhBcZ8HjM2Wm9rcpyVDSlM4iz4
=5ed9
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#190283

Le 26/12/2017 à 11:36, tomas@tuxteam.de a écrit :
> 
> On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote:
>> Note however that in any case, the early part of GRUB cannot be
>> encrypted [...]
> 
> Is there any inherent advantage to having /boot encrypted?

I can imagine a few situations.

- When you can enforce the early stage of GRUB integrity by storing it 
on removable or read-only boot media, checking it with trusted 
computing, TPM...
You could extend this to the whole /boot directory contents instead of 
encrypting it but parts of it such as the kernel image, initramfs and 
grub.cfg change quite often, while GRUB itself seldom changes. An 
alternative to /boot encryption is to sign its contents so that GRUB 
early stage can check the files when loading them.

- When you need to store sensitive data in /boot, such as passphrases 
for other encrypted volumes.

[toc] | [prev] | [next] | [standalone]

#190284

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Dec 26, 2017 at 12:10:52PM +0100, Pascal Hambourg wrote:
> Le 26/12/2017 à 11:36, tomas@tuxteam.de a écrit :
> >
> >On Tue, Dec 26, 2017 at 10:42:46AM +0100, Pascal Hambourg wrote:
> >>Note however that in any case, the early part of GRUB cannot be
> >>encrypted [...]
> >
> >Is there any inherent advantage to having /boot encrypted?
> 
> I can imagine a few situations.
> 
> - When you can enforce the early stage of GRUB integrity by storing
> it on removable or read-only boot media, checking it with trusted
> computing, TPM...
> You could extend this to the whole /boot directory contents instead
> of encrypting it but parts of it such as the kernel image, initramfs
> and grub.cfg change quite often, while GRUB itself seldom changes.
> An alternative to /boot encryption is to sign its contents so that
> GRUB early stage can check the files when loading them.
> 
> - When you need to store sensitive data in /boot, such as
> passphrases for other encrypted volumes.

In the days you measure (small) external media in gigabytes, this
argument has lost a lot of push. My whole boot at the moment is
37M, the smallest SD card I can come up at home is 256M, and we
kicked it out of our point-n-shoot camera because... 4G.

But yes, on some specialized hardware that might make a difference.
FWIW, /boot/grub is 9.1M (yikes! didn't I say I don't like how fat
the boot loader has become? How long until it needs dbus?), which
is an upper bound to the size of grub's "non-unencrypted" part
(dunno by how much).

Small embedded systems tend to have syslinux, though, or whatever
else you use on Arm ;-P

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCMYMACgkQBcgs9XrR2kYfNQCeLOeymSZxg4nghp+aEzUfmogJ
7HcAniw/ih+7TlWk5aNP21UQeJemAKoH
=Fvh7
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#190287

Le 26/12/2017 à 12:24, tomas@tuxteam.de a écrit :
> 
> On Tue, Dec 26, 2017 at 12:10:52PM +0100, Pascal Hambourg wrote:
>> Le 26/12/2017 à 11:36, tomas@tuxteam.de a écrit :
>>>
>>> Is there any inherent advantage to having /boot encrypted?
>>
>> I can imagine a few situations.
>>
>> - When you can enforce the early stage of GRUB integrity by storing
>> it on removable or read-only boot media, checking it with trusted
>> computing, TPM...
>> You could extend this to the whole /boot directory contents instead
>> of encrypting it but parts of it such as the kernel image, initramfs
>> and grub.cfg change quite often, while GRUB itself seldom changes.
>> An alternative to /boot encryption is to sign its contents so that
>> GRUB early stage can check the files when loading them.
>>
>> - When you need to store sensitive data in /boot, such as
>> passphrases for other encrypted volumes.
> 
> In the days you measure (small) external media in gigabytes, this
> argument has lost a lot of push.

What does storage size have to do with these situations ?

> But yes, on some specialized hardware that might make a difference.
> FWIW, /boot/grub is 9.1M (yikes! didn't I say I don't like how fat
> the boot loader has become?

You can remove all the unneeded modules for features that you do not use.

[toc] | [prev] | [next] | [standalone]

#190289

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Dec 26, 2017 at 12:33:36PM +0100, Pascal Hambourg wrote:
> Le 26/12/2017 à 12:24, tomas@tuxteam.de a écrit :

[...]

> >In the days you measure (small) external media in gigabytes, this
> >argument has lost a lot of push.
> 
> What does storage size have to do with these situations ?

The other way around: if you keep the unencrypted bits in a separate
(or somehow specially secured) medium, a strict limitation on its
size might favour smaller (i.e. half a bootloader only) over fatter
(i.e. a whole bootloader plus a kernel plus an initramfs) solutions.

> >But yes, on some specialized hardware that might make a difference.
> >FWIW, /boot/grub is 9.1M (yikes! didn't I say I don't like how fat
> >the boot loader has become?
> 
> You can remove all the unneeded modules for features that you do not use.

Yes, yes, I know. Still... I don't like this overcomplex Grub. Scope
creep, if you ask me. Dealing with the "lower half" seems more than
enough. But there are tastes for everything :-)

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlpCNiIACgkQBcgs9XrR2kYipQCfRSacDjIkHtzJj4h4wsQaz5VL
ju0An3UU+Pfuu5ogh8AdDKomtTKbV2Dt
=qoVI
-----END PGP SIGNATURE-----

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web