Aktion: Feed

Auch verfügbar in English, Français, Русский


{{feed
	url="https://...[|https://...|https://...]"
	[title="News feed title|no"]
		"text" - displayed as title
		"no" - means show no title
		empty title - title taken from feed
	[max="x"]
	[time=1]
		1 - show time tag of feed item
		0 - hide time tag of feed item (default)
	[nomark=1]
		1 - makes feed header h3 and feed-items headers h4
		0 - makes it all default
}}	

siehe auch: Externe Feeds Einbinden

Beispiel

{{feed url="https://news.opensuse.org/feed/"}}


XML

Feed Title: openSUSE News


Dropping pcr-oracle in user space Full Disk Encryption

Introduction

In user space Full Disk Encryption (FDE), as opposed to the boot loader based FDE, developers for openSUSE supported signed policy and NVIndex policy from the beginning when Trusted Platform Module 2 (TPM2) is used.

With this signed policy, we deliver a JSON file in the EFI System Partition (ESP) that is being read during the initrd stage by systemd-cryptsetup. This file contains the hash policy, which basically describes the expected values of the PCR registers of the TPM2 (measured boot). Together with the policy, we will find a signature that will be validated by the TPM2, and if the PCR values and the signatures are valid, then the TPM2 will unseal the password for the encrypted hard disk, and the boot process can continue.

This method is simple and very flexible. We can update the policy to generate new predictions (for example if a new kernel was installed). Using a private key, that can be stored in the encrypted side of the system, we can sign it and install in the ESP. Another advantage is that we can generate multiple files that support multiple valid configurations, which can represent different snapshots, kernels, or initrd installed in the system.

But one limitation of this method is that we are not protected against a rollback attack. Some one can copy the JSON file (the ESP is not encrypted), together with the kernel and the initrd and wait until some CVE is published for this configuration. After that, the assets can be copied back to the ESP and the signature of the policy will be still valid as far as the TPM2 is concerned. Technically, this can be resolved generating a new private key and enrolling again the devices, but this is not ideal.

systemd-pcrlock provides a new alternative, known as NVIndex policy, which store the policy in the TPM2 non-volatile RAM under a password (recovery PIN). This approach is a bit better for our case, as it resolves the rollback attack. This method is used by default if the TPM2 support it, but because policyAuthorizeNV was introduced in TPM2 Revision 1.38 ten years ago (2016), not all devices can do that. sdbootutil fallbacks to pcr-oracle (signed policy) if NVIndex policy cannot be used.

The next version of sdbootutil will drop pcr-oracle.

Motivation

Basically it is time to do that. The rollback attack is a good argument to avoid signed policies, but we need to factor the maintenance of pcr-oracle for multiple boot loaders (GRUB2 and systemd-boot).

The way that pcr-oracle works means that any change in the event log order or structure needs to be addressed in the source code, but with systemd-pcrlock it is a matter of generating some JSON files stored in /var/lib/pcrlock.d and updating the TPM2 policy in the right moment.

This difference makes pcr-oracle stay behind in the current support, making in effectively broken for any metric.

Migration

The good news is that if you have a TPM2 produced after 2016, you can migrate to systemd-pcrlock very easily. sdbootutil still recognize systems registered with pcr-oracle and can unenroll them. The migration process is as easy as:

  # sdbootutil unenroll --method=tpm2 #  sdbootutil enroll --ask-pin --method=tpm2 

If sadly your TPM2 revision is older, the password enrollment is always available:

  # sdbootutil unenroll --method=tpm2 #  sdbootutil enroll --method=password 

Further Documentation


{{feed url="https://www.flickr.com/services/feeds/photos_public.gne?tags=art&format=rss_200" max=1 time=1}}


XML

Feed Title: Pool von Japan Through the Eyes of Others


Maneki-neko (招き猫)

Éric B. hat dem Pool ein Foto hinzugefügt:

Maneki-neko (招き猫)

The Maneki-neko ("beckoning cat") is a popular Japanese talisman, commonly depicted as a ceramic or plastic cat raising its paw to attract luck, fortune, and customers to businesses. Originating in the Edo period, these figurines are often placed near entrances, featuring different paws and colors to symbolize specific types of prosperity, such as wealth (gold), safety (black), or happiness (white).

Paw Meaning: The right paw raised is believed to attract money and fortune, often used in businesses. The left paw raised is thought to invite people or customers.

--

Le Maneki-neko (« chat qui invite ») est un talisman japonais populaire, généralement représenté sous la forme d'un chat en céramique ou en plastique levant la patte pour attirer la chance, la fortune et les clients vers les commerces. Originaires de l'époque d'Edo, ces figurines sont souvent placées près des entrées et arborent différentes pattes et couleurs pour symboliser des types spécifiques de prospérité, tels que la richesse (or), la protection (noir) ou le bonheur (blanc).

Signification des pattes : On pense que la patte droite levée attire l'argent et la fortune, elle est donc souvent utilisée dans les entreprises. La patte gauche levée est censée inviter les gens et les clients.