|
version 1.4, 2016/06/22 07:54:00
|
version 1.5, 2016/06/22 08:54:30
|
|
Line 3 Root filesystem encryption
|
Line 3 Root filesystem encryption
|
| |
|
| It is possible to run NetBSD with [complete root filesystem encryption][1], thanks to the `cgdroot.kmod` kernel module. It really is a memory disk (also knows as RAM disk) that is expected to be loaded in the kernel while booting. |
It is possible to run NetBSD with [complete root filesystem encryption][1], thanks to the `cgdroot.kmod` kernel module. It really is a memory disk (also knows as RAM disk) that is expected to be loaded in the kernel while booting. |
| |
|
| It still requires one unencrypted partition to boot from (typically `wd0a`). |
Full disk encryption makes it more difficult for an attacker to modify the unencrypted part of the disk to plant a backdoor. With only partial encryption, the original [[!template id=man name="cgdconfig" section="8"]] binary may be modifiedto send the passphrase away, allowing an attacker with a disk dump to recover the data. |
| |
|
| |
The mechanism described here still requires one unencrypted partition to boot from (typically `wd0a`). |
| |
|
| The boot process |
The boot process |
| ---------------- |
---------------- |
| |
|
| Instead of booting normally the GENERIC kernel and using the root filesystem, a |
Instead of booting normally the GENERIC kernel and using the root filesystem, a kernel module is loaded at boot-time containing a memory disk. This minimal filesystem image is then considered the actual root filesystem. |
| kernel module is loaded at boot-time containing a memory disk. It contains a |
|
| minimal filesystem image, which is then considered the actual root filesystem: |
|
| |
|
| The boot partition on disk only needs to contain: |
The boot partition on disk only needs to contain: |
| |
|
|
Line 67 src/distrib/amd64/kmod-cgdroot$ /path/to
|
Line 67 src/distrib/amd64/kmod-cgdroot$ /path/to
|
| Caveats |
Caveats |
| ------- |
------- |
| |
|
| The biggest (known) issue with this setup occurs when firmware needs to be loaded early in the boot process (such as graphics drivers for the console). At the moment they need to be built as part of the memory disk. Some network interfaces, of which some wireless devices in particular, also require loading firmware to work properly. |
The biggest (known) issue with this setup occurs when firmware needs to be loaded early in the boot process (such as graphics drivers for the console). At the moment they need to be provided as part of the memory disk. Some network interfaces, of which some wireless devices in particular, also require loading firmware to work properly. |
| |
|
| This setup is not entirely safe against physical attacks. An attacker can modify the boot process to store the passphrase for later retrieval, or insert a backdoor while booting. |
This setup is not entirely safe against physical attacks. An attacker can modify the boot process to store the passphrase for later retrieval, or insert a backdoor while booting. To defend against such attacks, the bootloader, kernel and ramdisk all need to be signed and their integrity checked before booting (eg with [[!template id=man name="tpm" section="4"]]). Alternatively, it is possible to boot from a removable medium (eg USB stick), which can be protected against tampering attacks (eg secure storage, read-only volume...). |
| |
|
| References |
References |
| ---------- |
---------- |
![[BACK]](/icons/back.gif){kind=icon}
Return to cgdroot.mdwn CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [NetBSD Developer Wiki] / wikisrc / security