RFC: Public key encryption of dmesg by the kernel

From: Dan Aloni <[email protected]>

Signed-off-by Dan Aloni <[email protected]>

---
 certs/system_keyring.c        | 56 ++++++++++++++++++++++++++++++++++++++++++-
 include/keys/system_keyring.h |  3 +++
 2 files changed, 58 insertions(+), 1 deletion(-)

certs/system_keyring.c +6 -1

index 6251d1b27f0c..ff7c18d8e67c 100644
@@ -131,6 +131,8 @@ static __init int system_trusted_keyring_init(void)
  */
 device_initcall(system_trusted_keyring_init);
 
+static char *first_asymmetric_key_description;
+
 /*
  * Load the compiled-in list of X.509 certificates.
  */

@@ -172,8 +174,11 @@ static __init int load_system_certificate_list(void)
 			pr_err("Problem loading in-kernel X.509 certificate (%ld)\n",
 			       PTR_ERR(key));
 		} else {
+			first_asymmetric_key_description =
+				kstrdup(key_ref_to_ptr(key)->description,
+					GFP_KERNEL);
 			pr_notice("Loaded X.509 cert '%s'\n",
-				  key_ref_to_ptr(key)->description);
+				  first_asymmetric_key_description);
 			key_ref_put(key);
 		}
 		p += plen;

certs/system_keyring.c +14 -0

+ */
+static struct key *get_first_asymmetric_key(struct key *keyring)
+{
+	key_ref_t ref;
+
+	ref = keyring_search(make_key_ref(keyring, 1),
+	          &key_type_asymmetric,
+		  first_asymmetric_key_description);
+	if (IS_ERR(ref)) {
+		switch (PTR_ERR(ref)) {
+		case -EACCES:
+		case -ENOTDIR:
+		case -EAGAIN:
+			return ERR_PTR(-ENOKEY);

certs/system_keyring.c +19 -0

+ * keyring, or return the first key in that keyring.
+ *
+ * @id_0: The first ID to look for or NULL.
+ * @id_1: The second ID to look for or NULL.
+ *
+ * The preferred identifier is the id_0 and the fallback identifier is
+ * the id_1. If both are given, the lookup is by the former, but the
+ * latter must also match. If none are given, the first key is returned.
+ */
+struct key *find_trusted_asymmetric_key(const struct asymmetric_key_id *id_0,
+					const struct asymmetric_key_id *id_1)
+{
+	struct key *keyring = builtin_trusted_keys;
+	if (!id_0 && !id_1) {
+		return get_first_asymmetric_key(keyring);
+	}
+
+	return find_asymmetric_key(keyring, id_0, id_1, false);
+}

From: Dan Aloni <[email protected]>

This commit enables the kernel to encrypt the free-form text that is generated by printk() before it is brought up to dmesg in userspace.

The encryption is made using one of the trusted public keys which are kept built-in inside the kernel. These keys are presently also used for verifying kernel modules and userspace-supplied firmwares.

Signed-off-by Dan Aloni <[email protected]>

---
 include/uapi/linux/kmsg.h |  18 ++
 init/Kconfig              |  10 ++
 kernel/printk/printk.c    | 422 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 450 insertions(+)
 create mode 100644 include/uapi/linux/kmsg.h

include/uapi/linux/kmsg.h new file +7 -0

new file mode 100644
index 000000000000..ae74f026d727
@@ -0,0 +1,18 @@
+#ifndef _LINUX_UAPI_KMSG_H
+#define _LINUX_UAPI_KMSG_H
+
+#include <linux/ioctl.h>
+#include <linux/types.h>
+
+struct kmsg_ioctl_get_encrypted_key {

include/uapi/linux/kmsg.h new file +1 -0

+#endif /* _LINUX_DN_H */

kernel/printk/printk.c +0 -0

index b9006617710f..c50b9cb60b82 100644
@@ -744,12 +755,33 @@ static ssize_t msg_print_ext_body(char *buf, size_t size,
 	return p - buf;

From: Dan Aloni <[email protected]>

Example execution:

dmesg | dmesg-decipher <private-key.pem>

Signed-off-by Dan Aloni <[email protected]>

---

tools/kmsg/dmesg-decipher.c new file +1 -0

new file mode 100644
index 000000000000..c7149fe7dc17
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0

tools/kmsg/dmesg-decipher.c new file +10 -0

+ */
+
+#include <openssl/pem.h>
+#include <openssl/pkcs7.h>
+#include <openssl/err.h>
+
+#include <stdbool.h>
+#include <stdint.h>
+#include <string.h>
+#include <regex.h>

tools/kmsg/dmesg-decipher.c new file +18 -0

+int main(int argc, char **argv)
+{
+	BIO *tbio = NULL;
+	RSA *rsa;
+	int ret = 1;
+	char line[0x1000];
+	uint8_t enc_sess_key[0x200];
+	uint8_t sess_key[0x200] = {0, };
+	bool got_key = false;
+
+	OpenSSL_add_all_algorithms();
+	ERR_load_crypto_strings();
+
+	regex_t session_key_regex;
+	regex_t message_regex;
+
+	ret = regcomp(&session_key_regex, session_key_pattern, REG_EXTENDED);
+	if (ret) {

tools/kmsg/dmesg-decipher.c new file +2 -0

+		return -1;
+	}

From: Dan Aloni <[email protected]>

Signed-off-by Dan Aloni <[email protected]>

---
 Documentation/admin-guide/dmesg-encryption.rst | 77 ++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100644 Documentation/admin-guide/dmesg-encryption.rst

Documentation/admin-guide/dmesg-encryption.rst new file +9 -0

new file mode 100644
index 000000000000..4a3d087b7f98
@@ -0,0 +1,77 @@
+Kernel message encryption
+-------------------------
+
+.. CONTENTS
+..
+.. - Overview
+.. - Reason for encrypting dmesg
+.. - Compile time and run time switches
+.. - Limitations

Documentation/admin-guide/dmesg-encryption.rst new file +56 -1

+
+The first line being read by a ``dmesg`` opener will be an artificial line containing an encrypted symmetric encryption session key, in RSA PKCS#1 format. The other lines are messages encrypted under an AES-128-GCM scheme. All binary ciphertext is hex-encoded, so that the ciphertext solely comprises of printable characters.
+
+===========
+Limitations
+===========
+
+There are various limitations one need to consider when enabling dmesg encryption:
+
+  * The metadata of kernel messages is not part of the encryption (timestamp, log facility, log severity).
+  * The seldom accompanying dictionary is also not part of the encryption.
+  * Any output to any system console, happening when printk() itself is executing, is also not encrypted. A potential attacker can load up ``netconsole`` and have kernel messages being sent as plaintext to other machines. Hopefully, on embedded devices, all system consoles are under strict control of the developers.
+  * The syslog system call is barred from reading kmsg. Its present users are few, as the system call's interface is mostly a fallback to an inaccessible ``/dev/kmsg``. This is only an implementation limitation and that may be addressed.
+  * kmsg buffers will still be saved as plaintext inside kdumps. The assumption is that having an access to read a kdump is equivalent to full kernel access anyway.
+
+===========================
+Reason for encryption dmesg
+===========================
+
+For years, dmesg has contained data which could be utilized by vulnerability exploiters, allowing for privilege escalations. Developers may leave key data such as pointers, indication of driver bugs, and more.
+
+The feature is mostly aimed for device manufacturers who are not keen on revealing the full details of kernel execution, bugs, and crashes to their users, but only to their developers, so that local programs running on the devices cannot use the data for 'rooting' and executing exploits.
+
+==================================
+Compile time and run time switches
+==================================
+
+In build time, this feature is controlled via the ``CONFIG_KMSG_ENCRYPTION`` configuration variable.
+
+In run time, it can be turned off by providing `kmsg.encrypt=0` as a boot time parameter.
+
+================
+Decrypting dmesg
+================
+
+A supplied program in the kernel tree named ``dmesg-decipher``, uses the OpenSSL library along with the paired private key of the encryption, in order to decipher an encrypted dmesg.
+
+An innocuous dmesg invocation will appear as such (with the ciphertexts shortened here for the brevity of this document)::
+
+    [    0.000000] K:7c7da3617b6f...f4098e2425af00
+    [    0.000000] M:36ae318532e...61686821b3ab,16,12
+    [    0.000000] M:7fca10...154e035,16,12
+    ....
+
+The artificial ``K:`` message is generated per opening of ``/dev/kmsg``. It contains the encrypted session key. The encrypted dmesg lines follows it (prefix ``M:``).
+
+Provided with the private key, deciphering a dmesg output should be a straight-forward process.
+
+For example, one can save an encrypted dmesg to ``dmesg.enc`` in one machine, then transfer it to another machine which contains access to the PEM with the decrypting private key, and use the the following command::
+
+    cat dmesg.enc | ./tools/kmsg/dmesg-decipher certs/signing_key.pem
+
+    [    0.000000] Linux version 4.15.0-rc5+ (dan@jupiter) (gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)) #109 SMP Sat Dec 30 18:32:25 IST 2017
+    [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.0-rc5-dan+ root=UUID=f48b37ec-fcb8-4689-b12e-58703db3cb21 ro rhgb quiet LANG=en_US.UTF-8
+    [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
+    ...
--

2.13.6

From: Dan Aloni <[email protected]>

Signed-off-by Dan Aloni <[email protected]>

---
 Documentation/admin-guide/dmesg-encryption.rst | 77 ++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100644 Documentation/admin-guide/dmesg-encryption.rst

Documentation/admin-guide/dmesg-encryption.rst new file +6 -0

new file mode 100644
index 000000000000..4a3d087b7f98
@@ -0,0 +1,77 @@
+Kernel message encryption
+-------------------------
+
+.. CONTENTS
+..
+.. - Overview

Documentation/admin-guide/dmesg-encryption.rst new file +12 -0

+
+  * The metadata of kernel messages is not part of the encryption (timestamp, log facility, log severity).
+  * The seldom accompanying dictionary is also not part of the encryption.
+  * Any output to any system console, happening when printk() itself is executing, is also not encrypted. A potential attacker can load up ``netconsole`` and have kernel messages being sent as plaintext to other machines. Hopefully, on embedded devices, all system consoles are under strict control of the developers.
+  * The syslog system call is barred from reading kmsg. Its present users are few, as the system call's interface is mostly a fallback to an inaccessible ``/dev/kmsg``. This is only an implementation limitation and that may be addressed.
+  * kmsg buffers will still be saved as plaintext inside kdumps. The assumption is that having an access to read a kdump is equivalent to full kernel access anyway.
+
+===========================
+Reason for encryption dmesg
+===========================
+
+For years, dmesg has contained data which could be utilized by vulnerability exploiters, allowing for privilege escalations. Developers may leave key data such as pointers, indication of driver bugs, and more.

Documentation/admin-guide/dmesg-encryption.rst new file +9 -0

+
+For example, one can save an encrypted dmesg to ``dmesg.enc`` in one machine, then transfer it to another machine which contains access to the PEM with the decrypting private key, and use the the following command::
+
+    cat dmesg.enc | ./tools/kmsg/dmesg-decipher certs/signing_key.pem
+
+    [    0.000000] Linux version 4.15.0-rc5+ (dan@jupiter) (gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)) #109 SMP Sat Dec 30 18:32:25 IST 2017
+    [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.0-rc5-dan+ root=UUID=f48b37ec-fcb8-4689-b12e-58703db3cb21 ro rhgb quiet LANG=en_US.UTF-8
+    [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
+    ...

Documentation/admin-guide/dmesg-encryption.rst line 16

Quoted 11 lines · Dan Aloni

From: Dan Aloni <[email protected]>

Signed-off-by Dan Aloni <[email protected]>

---
 Documentation/admin-guide/dmesg-encryption.rst | 77 ++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100644 Documentation/admin-guide/dmesg-encryption.rst

+========

Documentation/admin-guide/dmesg-encryption.rst new file +3 -0

+Overview
+========
+

Please hard wrap long lines so that they are readable in 80 columns. Some people still read .rst files like they are text files.

Quoted 15 lines · Randy Dunlap

Documentation/admin-guide/dmesg-encryption.rst line 16

Quoted 11 lines · Dan Aloni

From: Dan Aloni <[email protected]>

Signed-off-by Dan Aloni <[email protected]>

---
 Documentation/admin-guide/dmesg-encryption.rst | 77 ++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)
 create mode 100644 Documentation/admin-guide/dmesg-encryption.rst

+========

Documentation/admin-guide/dmesg-encryption.rst new file +3 -0

+Overview
+========
+

Please hard wrap long lines so that they are readable in 80 columns. Some people still read .rst files like they are text files.

Thanks very much for all the reviews in this reply and others, your suggestions are incorporated in the next version. A reviewed-by is in order?

From: Dan Aloni <[email protected]>

Hi All,

There has been a lot of progress in recent times regarding the removal of sensitive information from dmesg (pointers, etc.), so I figured - why not encrypt it all? However, I have not found any existing discussions or references regarding this technical direction.

I am not sure that desktop and power users would like to have their kernel message encrypted, but there are scenarios such as in mobile devices, where only the developers, makers of devices, may actually benefit from access to kernel prints messages, and the users may be more protected from exploits.

Quoted 9 lines · Dan Aloni

From: Dan Aloni <[email protected]>

Hi All,

There has been a lot of progress in recent times regarding the removal of sensitive information from dmesg (pointers, etc.), so I figured - why not encrypt it all? However, I have not found any existing discussions or references regarding this technical direction.

Quoted 5 lines

I am not sure that desktop and power users would like to have their kernel message encrypted, but there are scenarios such as in mobile devices, where only the developers, makers of devices, may actually benefit from access to kernel prints messages, and the users may be more protected from exploits.

What is the benefit of your approach compared to setting dmesg_restrict=1 or something like that and letting userland decide who should get access to raw dmesg output and in what form?

From: Dan Aloni <[email protected]>

Hi All,

There has been a lot of progress in recent times regarding the removal of sensitive information from dmesg (pointers, etc.), so I figured - why not encrypt it all? However, I have not found any existing discussions or references regarding this technical direction.

I am not sure that desktop and power users would like to have their kernel message encrypted, but there are scenarios such as in mobile devices, where only the developers, makers of devices, may actually benefit from access to kernel prints messages, and the users may be more protected from exploits.