aboutsummaryrefslogtreecommitdiff
path: root/i18n/fr_FR/docs/gnulinux/grub_hardening.md
blob: a7fdb5399f7ad7fbc528377815af5e7dbdc79872 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
---
title: GRUB hardening
...

Ce guide traite des nombreuses façons dont vous pouvez renforcer votre
configuration GRUB pour la sécurité. Ces étapes sont optionnelles, mais
hautement recommandées par le projet Libreboot.

Démarrage sécurisé de GRUB avec GPG
=========================

    Nous utiliserons l'implémentation libre du standard GPG pour le chiffrement et
la signature/vérification des données et ainsi permettant de vérifier la signature d'un kernel Linux
lors du démarrage. 
Plus d'information à propos de GPG peuvent être trouvée sur le [site web du projet GPG](https://www.gnu.org/software/gnupg/).
GRUB a quelques fonctionnalités de GPG nativement, notamment pour la vérification des signatures.

Ce tutoriel présume que vous avez une image Libreboot (rom) que vous souhaitez
modifier, que nous nommerons dès à présent comme "my.rom". Nous allons ici
modifier grubtest.cfg, celà veut dire que la signature et la protection par mot
de passe marchera après basculement sur celui-ci (grubtest.cfg) dans le menu principal
de démarrage, et le bousillage (bricking) dû à une mauvaise configuration sera impossible.
Dès lors que vous êtes satisfait avec le paramétrage, pensez-bien à transférer votre nouvelle
configuration dans votre grub.cfg pour sécuriser votre machine.


Premièrement, extrayez l'ancien grubtest.cfg de my.rom et enlevez le de celle-ci:

    cbfstool my.rom extract -n grubtest.cfg -f my.grubtest.cfg
    cbfstool my.rom remove -n grubtest.cfg

Liens utiles :

-   [manuel GRUB](https://www.gnu.org/software/grub/manual/html_node/Security.html#Security)
-   [pages 'info' GRUB](http://git.savannah.gnu.org/cgit/grub.git/tree/docs/grub.texi)
-   [Espace de stockage connectés en SATA considerés dangereux.](../../faq.md#hddssd-firmware)
-   [Tutoriel sécurité GRUB sur Coreboot](https://www.coreboot.org/GRUB2#Security)

Mot de passe GRUB
=============

La sécurité de ce paramétrage dépend d'un bon mot de passe GRUB car
la vérification de signature GPG peut être désactiver à travers la console
interactive:
    set check_signatures=no

C'est une bonne chose dans le fait où celà permet d'occasionnellement 
démarrer des liveCDs non signés et autres. Vous devriez penser à fournir
les signatures sur une clef USB, mais actuellement le code de
vérification de signature recherche </chemin/vers/fichier>.sig quand il veut
vérifier </chemin/vers/fichier> et alors donc il n'est pas possible de fournir
des signatures dans un endroit différent.

Notez que ça n'est pas votre mot de passe LUKS, mais c'est un mot de passe



GRUB Password
=============

The security of this setup depends on a good GRUB password as GPG
signature checking can be disabled through the interactive console:

    set check_signatures=no

This is good in that it allows you to occasionally boot unsigned liveCDs
and such. You may think of supplying signatures on an usb key, but the
signature checking code currently looks for
</path/to/filename>.sig when verifying </path/to/filename>
and as such it is not possible to supply signatures in an alternate
location.

Note that this is not your LUKS password, but it's a password that you
have to enter in order to use "restricted" functionality (such as
console). This protects your system from an attacker simply booting a
live USB and re-flashing your firmware. *This should be different than
your LUKS passphrase and user password.*

Use of the *diceware method* is recommended, for generating secure
passphrases (as opposed to passwords). Diceware method involves using
dice to generate random numbers, which are then used as an index to pick
a random word from a large dictionary of words. You can use any language
(e.g. English, German). Look it up on a search engine. Diceware method
is a way to generate secure passphrases that are very hard (almost
impossible, with enough words) to crack, while being easy enough to
remember. On the other hand, most kinds of secure passwords are hard to
remember and easier to crack. Diceware passphrases are harder to crack
because of far higher entropy (there are many words available to use,
but only about 50 commonly used symbols in pass*words*).

-->
The GRUB password can be entered in two ways:

-   plaintext
-   protected with [PBKDF2](https://en.wikipedia.org/wiki/Pbkdf2)

We will (obviously) use the later. Generating the PBKDF2 derived key is
done using the `grub-mkpasswd-pbkdf2` utility. You can get it by
installing GRUB version 2. Generate a key by giving it a password:
    grub-mkpasswd-pbkdf2

Its output will be a string of the following form:

    grub.pbkdf2.sha512.10000.HEXDIGITS.MOREHEXDIGITS

Now open my.grubtest.cfg and put the following before the menu entries
(prefered above the functions and after other directives). Of course use
the pbdkf string that you had generated yourself:

    set superusers="root"
    password_pbkdf2 root grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711

Obviously, replace it with the correct hash that you actually got for
the password that you entered. Meaning, not the hash that you see above!

As enabling password protection as above means that you have to input it
on every single boot, we will make one menu entry work without it.
Remember that we will have GPG signing active, thus a potential attacker
will not be able to boot an arbitrary operating system. We do this by
adding option `--unrestricted` to a menuentry definition:

    menuentry 'Load Operating System (incl. fully encrypted disks)  [o]' --hotkey='o' --unrestricted {
    ...

Another good thing to do, if we chose to load signed on-disk GRUB
configurations, is to remove (or comment out) `unset superusers` in
function try\_user\_config:

    function try_user_config {
       set root="${1}"
       for dir in boot grub grub2 boot/grub boot/grub2; do
          for name in '' autoboot_ libreboot_ coreboot_; do
             if [ -f /"${dir}"/"${name}"grub.cfg ]; then
                #unset superusers
                configfile /"${dir}"/"${name}"grub.cfg
             fi
          done
       done
    }

Why? We allowed booting normally without entering a password above. When
we unset superusers and then load a signed GRUB configuration file, we
can easily use the command line as password protection will be
completely disabled. Disabling signature checking and booting whatever
an attacker wants is then just a few GRUB commands away.

As far as basic password setup is concerned we are done and we can now
move on to signing.

GPG keys
========

First generate a GPG keypair to use for signing. Option RSA (sign only)
is ok.

Warning: GRUB does not read ASCII armored keys. When attempting to
trust ... a key filename it will print error: bad signature

    mkdir --mode 0700 keys
    gpg --homedir keys --gen-key
    gpg --homedir keys --export-secret-keys --armor > boot.secret.key # backup
    gpg --homedir keys --export > boot.key

Now that we have a key, we can sign some files with it. We have to sign:

-   a kernel
-   (if we have one) an initramfs
-   (if we wish to transfer control to it) an on-disk grub.cfg
-   grubtest.cfg (this is so one can go back to grubtest.cfg after
    signature checking is enforced. You can always get back to grub.cfg
    by pressing ESC, but afterwards grubtest.cfg is not signed and it
    will not load.

Suppose that we have a pair of `my.kernel` and `my.initramfs` and an
on-disk `libreboot_grub.cfg`. We sign them by issuing the following
commands:

    gpg --homedir keys --detach-sign my.initramfs
    gpg --homedir keys --detach-sign my.kernel
    gpg --homedir keys --detach-sign libreboot_grub.cfg
    gpg --homedir keys --detach-sign my.grubtest.cfg

Of course some further modifications to my.grubtest.cfg will be
required. We have to trust the key and enable signature enforcement (put
this before menu entries):

    trust (cbfsdisk)/boot.key
    set check_signatures=enforce

What remains now is to include the modifications into the image (rom):

    cbfstool my.rom add -n boot.key -f boot.key -t raw
    cbfstool my.rom add -n grubtest.cfg -f my.grubtest.cfg -t raw
    cbfstool my.rom add -n grubtest.cfg.sig -f my.grubtest.cfg.sig -t raw

... and flashing it.

Copyright © 2017 Fedja Beader <fedja@protonmail.ch>\

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License Version 1.3 or any later
version published by the Free Software Foundation
with no Invariant Sections, no Front Cover Texts, and no Back Cover Texts.
A copy of this license is found in [../fdl-1.3.md](../fdl-1.3.md)