Annotation of wikisrc/security/cgdroot.mdwn, revision 1.19
1.16 maxv 1: [[!meta title="Root Filesystem Encryption"]]
1.1 khorben 2:
1.8 khorben 3: 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 named after CGD, the "cryptographic device driver", which implements encryption for storage in the NetBSD kernel.
1.1 khorben 4:
1.9 khorben 5: The mechanism described here still requires one unencrypted partition to boot from (typically `wd0a`). Full disk encryption would make 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 modified to send the passphrase away, allowing an attacker with a disk dump to recover the data.
1.1 khorben 6:
1.10 khorben 7: The NetBSD Guide contains [an entire section about CGD][2].
8:
1.1 khorben 9: The boot process
10: ----------------
11:
1.9 khorben 12: Instead of booting the GENERIC kernel normally and using the root filesystem directly as usual, a special kernel module containing a memory disk is loaded at boot-time. This minimal filesystem image will then be the actual root filesystem, where the decryption process takes place.
1.1 khorben 13:
1.9 khorben 14: The boot partition on disk needs to contain:
1.4 leot 15:
1.3 leot 16: * [[!template id=man name="boot" section="8"]], the second-stage bootloader
17: * [[!template id=man name="boot.cfg" section="5"]], the configuration file for the bootloader (optional)
1.1 khorben 18: * a GENERIC kernel
19: * the `cgdroot.kmod` kernel module
1.8 khorben 20: * the configuration file for CGD, `cgd.conf`
1.15 riastrad 21: * the CGD parameters file for the volume, named after its partition (like `wd0f`), which determines how the encryption key is derived and verified
1.1 khorben 22:
1.3 leot 23: Once loaded the memory disk mounts the `wd0a` partition onto `/etc/cgd`, and asks for the encryption passphrase as usual (with [[!template id=man name="cgdconfig" section="8"]]). If successful, the `cgd0a` volume configured is mounted on `/altroot`, and [[!template id=man name="init" section="8"]] is told via [[!template id=man name="sysctl" section="7"]] to chroot into this volume before actually booting. The system then starts normally.
1.1 khorben 24:
25: In practice the memory disk remains the real root, and the regular system is
26: really ran from a chroot in `/altroot`.
27:
28: Obtaining the kernel module
29: ---------------------------
30:
1.19 ! sevan 31: The `cgdroot.kmod` kernel module is part of the regular NetBSD releases since NetBSD 7.0. It can be found in the `<arch>/installation/miniroot` folder from the release. For instance, for the amd64 architecture of the 7.0.1 release, download it at [cdn.netbsd.org/pub/NetBSD/NetBSD-7.0.1/amd64/installation/miniroot/cgdroot.kmod](http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.0.1/amd64/installation/miniroot/cgdroot.kmod).
1.1 khorben 32:
33: Configuring the kernel module
34: -----------------------------
35:
36: The kernel module needs to be available in the boot partition, alongside the desired kernel. The bootloader configuration in `/boot.cfg` should be modified to load the module, as in this example:
1.3 leot 37:
38: [[!template id=filecontent name="/boot.cfg" text="""
1.1 khorben 39: menu=Boot normally:rndseed /etc/entropy-file;load /cgdroot.kmod;boot /netbsd.gz -z
1.3 leot 40: """]]
1.1 khorben 41:
42: Building the kernel module
43: --------------------------
44:
45: The kernel module can be compiled in two steps from within the source tree for the NetBSD base system, once the distribution has been built. Change to the `distrib/<arch>/ramdisks/ramdisk-cgdroot` and use `nbmake-<arch>` to build:
46:
1.3 leot 47: [[!template id=programlisting text="""
1.2 khorben 48: src/distrib/amd64/ramdisks/ramdisk-cgdroot$ /path/to/tooldir/bin/nbmake-amd64
1.1 khorben 49: [...]
50: create ramdisk-cgdroot/ramdisk-cgdroot.fs
51: Calculated size of `ramdisk-cgdroot.fs.tmp': 5120000 bytes, 85 inodes
52: Extent size set to 4096
53: ramdisk-cgdroot.fs.tmp: 4.9MB (10000 sectors) block size 4096, fragment size 512
54: using 1 cylinder groups of 4.88MB, 1250 blks, 96 inodes.
55: super-block backups (for fsck -b #) at:
56: 32,
57: Populating `ramdisk-cgdroot.fs.tmp'
58: Image `ramdisk-cgdroot.fs.tmp' complete
1.3 leot 59: """]]
1.1 khorben 60:
61: Then the kernel module can be built:
62:
1.3 leot 63: [[!template id=programlisting text="""
1.2 khorben 64: src/distrib/amd64/kmod-cgdroot$ /path/to/tooldir/bin/nbmake-amd64
1.3 leot 65: """]]
1.1 khorben 66:
1.13 khorben 67: It will be found in `/path/to/objdir/distrib/amd64/kmod-cgdroot/cgdroot.kmod`.
68:
1.1 khorben 69: Caveats
70: -------
71:
1.5 khorben 72: 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.
1.1 khorben 73:
1.18 alnsn 74: Firmware that can be loaded later (e.g. microcode in `sysutils/intel-microcode-netbsd` package) can be found only if the corresponding paths in the `hw.firmware.path` sysctl variable are adjusted to start with `/altroot`.
1.17 alnsn 75:
1.12 khorben 76: 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 (e.g. with [[!template id=man name="tpm" section="4"]]). Alternatively, it is possible to boot from a removable medium (e.g. USB stick), which can be protected against tampering attacks (e.g. secure storage, read-only volume...).
1.1 khorben 77:
1.6 khorben 78: It is also possible to boot a Xen DOM0 system with root filesystem encryption. However, Xen-enabled NetBSD kernels currently do not support loading modules at boot-time. The memory disk has to be placed directly inside the kernel instead (with [[!template id=man name="mdconfig" section="8"]] or a new kernel configuration).
79:
1.14 khorben 80: It should really be possible to install NetBSD this way with [[!template id=man name="sysinst" section="8"]]. Unfortunately this is not supported yet.
81:
1.1 khorben 82: References
83: ----------
84:
1.4 leot 85: * [Full Disk Encryption with cgd (well, almost)][1]
1.10 khorben 86: * [The cryptographic device driver (CGD)][2]
1.4 leot 87:
1.3 leot 88: [1]: https://mail-index.netbsd.org/current-users/2013/03/21/msg022311.html "Full Disk Encryption with cgd (well, almost)"
1.10 khorben 89: [2]: http://www.netbsd.org/docs/guide/en/chap-cgd.html "The cryptographic device driver (CGD)"
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb
![[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