Die MZLA Technologies Corporation hat mit Thunderbird 91.6.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.6.1

Mit dem Update auf Thunderbird 91.6.1 hat die MZLA Technologies Corporation ein Update außer der Reihe für seinen Open Source E-Mail-Client veröffentlicht und behebt damit mehrere Fehler der Vorgängerversion. Diese lassen sich in den Release Notes (engl.) nachlesen. Dies schließt auch eine geschlossene Sicherheitslücke ein.

Der Beitrag Thunderbird 91.6.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

In Teil 1 dieser Artikelserie habe ich mein Ansinnen ausführlich beschrieben. Dieser Teil widmet sich der Entwicklung einer Ansible-Rolle zum Deployment des Nextcloud-Apache-Container-Images.

In den folgenden Abschnitten beschreibe ich die Einrichtung eines Python Virtual Environments, die Installation von Ansible in dem zuvor erstellten Environment und die Installation der Ansible-Collection containers.podman, bevor ich mich abschließend der eigentlichen Ansible-Rolle widme.

Python Virtual Environments für Ansible

Zur Einrichtung habe ich mich an den englischsprachigen Artikel „How to set up and use Python virtual environments for Ansible“ von Gineesh Madapparambath gehalten. Die notwendigen Schritte werden hier kurz und bündig dokumentiert.

[t14s ~]$ python3 --version
Python 3.9.7

[t14s ~]$ mkdir python-venv
[t14s ~]$ cd !$
cd python-venv

[t14s python-venv]$ python3 -m venv ansible-core2.x
[t14s python-venv]$ source ansible-core2.x/bin/activate
(ansible-core2.x) [jkastning@t14s python-venv]$ python3 -m pip install --upgrade pip
Requirement already satisfied: pip in ./ansible-core2.x/lib/python3.9/site-packages (21.0.1)
Collecting pip
  Downloading pip-21.3.1-py3-none-any.whl (1.7 MB)
     |████████████████████████████████| 1.7 MB 2.3 MB/s 
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 21.0.1
    Uninstalling pip-21.0.1:
      Successfully uninstalled pip-21.0.1
Successfully installed pip-21.3.1

(ansible-core2.x) [t14s python-venv]$ python3 -m pip install ansible-core
Collecting ansible-core
[...]

(ansible-core2.x) [t14s python-venv]$ ansible --version
ansible [core 2.11.6] 
  config file = None
  configured module search path = ['/home/tronde/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/tronde/python-venv/ansible-core2.x/lib64/python3.9/site-packages/ansible
  ansible collection location = /home/tronde/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/tronde/python-venv/ansible-core2.x/bin/ansible
  python version = 3.9.7 (default, Aug 30 2021, 00:00:00) [GCC 11.2.1 20210728 (Red Hat 11.2.1-1)]
  jinja version = 3.0.2
  libyaml = True

Damit ist die Installation von ansible-core abgeschlossen. Im folgenden Code-Block wird geprüft, ob Ansible sich grundsätzlich mit dem Zielsystem verbinden und dort einen Python-Interpreter identifizieren kann.

(ansible-core2.x) [t14s python-venv]$ ansible -i hosts --private-key ~/.ssh/ansible_id_rsa -m ping example.com
example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Installation der Ansible-Collection containers.podman

Um Podman auf dem Zielsystem konfigurieren zu können, wird die genannte Ansible-Collection benötigt, welche mit folgendem Befehl installiert werden kann. Der Code-Block zeigt zusätzlich die Ausgabe während der Installation.

(ansible-core2.x) [t14s ansible-core2.x]$ ansible-galaxy collection install containers.podman
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://galaxy.ansible.com/download/containers-podman-1.8.2.tar.gz to /home/tronde/.ansible/tmp/ansible-local-8729oh0om8w3/tmp7tv2yrae/containers-podman-1.8.2-9rw3fd1y
Installing 'containers.podman:1.8.2' to '/home/tronde/.ansible/collections/ansible_collections/containers/podman'
containers.podman:1.8.2 was installed successfully

Ansible-Rolle: Deployment von Nextcloud und MariaDB als Pod

Nextcloud benötigt für den Betrieb eine Datenbank. Hierfür könnte man eine integrierte SQLite nutzen. Dies wird jedoch nur für kleine Umgebungen empfohlen. Während der Entstehung dieses Artikels wird MariaDB als Datenbank-Backend vom Nextlcoud-Projekt empfohlen. Daher habe ich mich entschieden, das Nextcloud-Image zusammen mit einem MariaDB-Container zu deployen. Dazu greife ich auf die beiden folgenden Container-Repositorien zurück:

• Nextcloud (Official Image) — https://hub.docker.com/_/nextcloud
• MariaDB (Official Image) — https://hub.docker.com/_/mariadb

Das Grundgerüst bzw. die Verzeichnisstruktur für die Ansible-Rolle wurde erstellt mit:

$ ansible-galaxy role init --offline ansible_role_deploy_nextcloud_with_mariadb_pod

Die aktuelle Version der Ansible-Rolle ist auf GitHub zu finden. Ich werde ihre Bestandteile hier im Einzelnen vorstellen.

Die Variablen in defaults/main.yml

In der Datei defaults/main.yml habe ich Standardwerte für Variablen definiert, die geeignet sind, eine funktionsfähige Nextcloud-Instanz zu initialisieren. Die Bezeichner der Variablen sind dabei der Dokumentation der verwendeten Container-Repositorien entnommen.

In Zeile 4-7 und 10 werden die Namen für Podman-Volumes definiert, welche die persistent zu speichernden Daten aufnehmen werden.

     1	---
     2	# defaults file for ansible_role_deploy_nextcloud_with_mariadb_pod
     3	# Podman volumes for Nextcloud
     4	NC_HTML: nc_html
     5	NC_APPS: nc_apps
     6	NC_CONFIG: nc_config
     7	NC_DATA: nc_data
     8	
     9	# Podman volume for MariaDB
    10	MYSQL_DATA: mysql_data

Die Zeilen 13-17 definieren Variablen für die MariaDB-Instanz, wie z.B. Namen der Datenbank, Benutzername und Passwörter für diese Datenbank und den DB-Host. Diese werden neben dem MariaDB-Container auch von dem Nextcloud-Container benötigt, um eine Verbindung zur Datenbank herstellen zu können.

    12	# MySQL/MariaDB vars
    13	MYSQL_DATABASE: nc_db
    14	MYSQL_USER: nextcloud
    15	MYSQL_PASSWORD: ToPSeCrEt2021!
    16	MYSQL_ROOT_PASSWORD: ToPSeCrEt2021!
    17	MYSQL_HOST: 127.0.0.1
    18	
    19	# Vars for MariaDB container
    20	MARIADB_CONMON_PIDFILE: /tmp/mariadb_conmon.pid
    21	MARIADB_IMAGE: docker.io/library/mariadb:10.5.7
    22	MARIADB_NAME: nc_mariadb

Zeile 20-22 definiert Variablen, die für den MariaDB-Container benötigt werden. Hier wird z.B. die Version des Container-Images (MARIADB_IMAGE) und ein Name für die Container-Instanz (MARIADB_NAME) festgelegt.

Die folgenden Zeilen widmen sich den Variablen für den Nextcloud-Container. Dort werden in den Zeilen 25 u. 26 Benutzername und Passwort für den Nextcloud-Admin definiert, gefolgt von einigen Variablen, welche bei Nutzung eines Reverse-Proxy benötigt werden und SMTP-Variablen, welche der Nextcloud den Mailversand ermöglichen.

    24	# Nextcloud vars
    25	NEXTCLOUD_ADMIN_USER: nc_admin
    26	NEXTCLOUD_ADMIN_PASSWORD: VSnfD2021!
    27	NEXTCLOUD_OVERWRITEPROTOCOL: ""
    28	NEXTCLOUD_OVERWRITECLIURL: ""
    29	NEXTCLOUD_TRUSTED_DOMAINS: ""
    30	
    31	# SMTP vars
    32	SMTP_HOST: smtp.example.com
    33	SMTP_SECURE: tls # ssl to use SSL, or tls zu use STARTTLS
    34	SMTP_PORT: 587 # (25, 465 for SSL, 587 for STARTTLS)
    35	SMTP_AUTHTYPE: LOGIN
    36	SMTP_NAME: bob@example.com
    37	SMTP_PASSWORD: MailSecret1!
    38	MAIL_FROM_ADDRESS: no-reply@example.com
    39	MAIL_DOMAIN: "@example.com"

Bei den SMTP-Variablen handelt es sich um Beispiel-Werte. Diese müssen an die konkrete Umgebung angepasst werden.

Es folgen nun noch ein paar Variablen, welche dem Pod und dem Nextcloud-Container einen Namen geben, sowie die Version des zu verwendenden Nextcloud-Container-Images festlegen.

    41	# Vars for podman-pod(1)
    42	POD_NAME: nc_pod
    43	POD_PORT: 127.0.0.1:40231:80
    44	POD_INFRA_CONMON_PIDFILE: /tmp/nc_pod_infra.pid
    45	
    46	# Vars for Nextcloud container
    47	NC_CONMON_PIDFILE: /tmp/nc_conmon.pid
    48	NC_IMAGE: docker.io/library/nextcloud:23-apache
    49	NC_NAME: nextcloud

Durch POD_PORT: 127.0.0.1:40231:80 wird definiert, dass der Port 40231 an das Loopback-Interface gebunden und mit Port 80 des Pods verknüpft wird. Mit dieser Einstellung ist die Nextcloud-Instanz nur von dem Host aus erreichbar, auf dem sie ausgebracht wurde. Möchte man sie auch von anderen Hosts aus erreichbar machen, kann man entweder den Teil mit 127.0.0.1: weglassen oder einen Reverse-Proxy wie z.B. NGINX verwenden. Ich empfehle an dieser Stelle letzteres.

Hinweis: In defauts/main.yml stehen Passwörter im Klartext. Diese sind mit der Veröffentlichung der Ansible-Rolle allgemein bekannt und sollten gegen solche ersetzt werden, die geheimgehalten werden. Dies kann z.B. geschehen, in dem man die entsprechenden Variablen in vars/main.yml oder host_vars/hostname neu definiert. Es bietet sich an, diese zusätzlich mit Ansible-Vault zu verschlüsseln.

Die Tasks in tasks/main.yml

Im vorstehenden Abschnitt wurden die Variablen definiert, welche für die nun folgenden Tasks benötigt werden. Diese sind in tasks/main.yml definiert und werden im folgenden wieder abschnittsweise erläutert.

     1	---
     2	# tasks file for ansible_role_deploy_nextcloud_with_mariadb_pod
     3	- name: Main folder, needed for updating
     4	  containers.podman.podman_volume:
     5	    state: present
     6	    name: "{{ NC_HTML }}"
     7	    recreate: no
     8	    debug: no
     9	
    10	- name: Volume for installed/modified apps
    11	  containers.podman.podman_volume:
    12	    state: present
    13	    name: "{{ NC_APPS }}"
    14	    recreate: no
    15	    debug: no
    16	
    17	- name: Volume for local configuration
    18	  containers.podman.podman_volume:
    19	    state: present
    20	    name: "{{ NC_CONFIG }}"
    21	    recreate: no
    22	    debug: no
    23	
    24	- name: Volume for the actual data of Nextcloud
    25	  containers.podman.podman_volume:
    26	    state: present
    27	    name: "{{ NC_DATA }}"
    28	    recreate: no
    29	    debug: no
    30	
    31	- name: Volume for the MySQL data files
    32	  containers.podman.podman_volume:
    33	    state: present
    34	    name: "{{ MYSQL_DATA }}"
    35	    recreate: no
    36	    debug: no

Die ersten Zeilen enthalten Tasks, durch welche die Podman-Volumes zur persistenten Datenspeicherung auf dem Zielsystem erstellt werden. Diese Tasks sind, wie für Ansible üblich, deklarativ und idempotent. Existiert ein Volume bereits, liefert der entsprechende Task ein ‚OK‘ zurück, da keine Aktionen erforderlich sind.

Die folgenden Zeilen erstellen den Podman-Pod und fügen ihm einen Nextcloud- sowie einen MariaDB-Container hinzu. Die Dokumentation der verwendeten Module findet sich in Punkt 5 und 6 im Abschnitt Quellen und weiterführende Links.

    38	- name: Create the podman-pod(1)
    39	  containers.podman.podman_pod:
    40	    debug: no
    41	    infra: yes
    42	    infra_conmon_pidfile: "{{ POD_INFRA_CONMON_PIDFILE }}"
    43	    publish: "{{ POD_PORT }}"
    44	    name: "{{ POD_NAME }}"
    45	    state: started
    46	
    47	- name: Create MariaDB container
    48	  containers.podman.podman_container:
    49	    debug: yes
    50	    conmon_pidfile: "{{ MARIADB_CONMON_PIDFILE }}"
    51	    image: "{{ MARIADB_IMAGE }}"
    52	    image_strict: yes
    53	    pod: "{{ POD_NAME }}"
    54	    recreate: yes
    55	    state: started
    56	    name: "{{ MARIADB_NAME }}"
    57	    env:
    58	      MYSQL_USER: "{{ MYSQL_USER }}"
    59	      MYSQL_PASSWORD: "{{ MYSQL_PASSWORD }}"
    60	      MYSQL_ROOT_PASSWORD: "{{ MYSQL_ROOT_PASSWORD }}"
    61	      MYSQL_DATABASE: "{{ MYSQL_DATABASE }}"
    62	    volume: "{{ MYSQL_DATA }}:/var/lib/mysql:Z"
    63	
    64	- name: Wait for DB to initilize
    65	  wait_for:
    66	    timeout: 20
    67	
    68	- name: Create Nextcloud container
    69	  containers.podman.podman_container:
    70	    debug: no 
    71	    conmon_pidfile: "{{ NC_CONMON_PIDFILE }}"
    72	    image: "{{ NC_IMAGE }}"
    73	    image_strict: yes
    74	    pod: "{{ POD_NAME }}"
    75	    recreate: yes
    76	    state: started
    77	    name: "{{ NC_NAME }}"
    78	    env:
    79	      MYSQL_DATABASE: "{{ MYSQL_DATABASE }}"
    80	      MYSQL_USER: "{{ MYSQL_USER }}"
    81	      MYSQL_PASSWORD: "{{ MYSQL_PASSWORD }}"
    82	      MYSQL_HOST: "{{ MYSQL_HOST }}"
    83	      NEXTCLOUD_ADMIN_USER: "{{ NEXTCLOUD_ADMIN_USER }}"
    84	      NEXTCLOUD_ADMIN_PASSWORD: "{{ NEXTCLOUD_ADMIN_PASSWORD }}"
    85	      NEXTCLOUD_TRUSTED_DOMAINS: "{{ NEXTCLOUD_TRUSTED_DOMAINS }}"
    86	      SMTP_HOST: "{{ SMTP_HOST }}"
    87	      SMTP_SECURE: "{{ SMTP_SECURE }}"
    88	      SMTP_PORT: "{{ SMTP_PORT }}"
    89	      SMTP_AUTHTYPE: "{{ SMTP_AUTHTYPE }}"
    90	      SMTP_NAME: "{{ SMTP_NAME }}"
    91	      SMTP_PASSWORD: "{{ SMTP_PASSWORD }}"
    92	      MAIL_FROM_ADDRESS: "{{ MAIL_FROM_ADDRESS }}"
    93	      MAIL_DOMAIN: "{{ MAIL_DOMAIN }}"
    94	      OVERWRITEPROTOCOL: "{{ NEXTCLOUD_OVERWRITEPROTOCOL }}"
    95	      OVERWRITECLIURL: "{{ NEXTCLOUD_OVERWRITECLIURL }}"
    96	    volume:
    97	      - "{{ NC_HTML }}:/var/www/html:Z"
    98	      - "{{ NC_APPS }}:/var/www/html/custom_apps:Z"
    99	      - "{{ NC_CONFIG }}:/var/www/html/config:Z"
   100	      - "{{ NC_DATA }}:/var/www/html/data:Z"

In Zeile 64-66 habe ich einen Task definiert, der einfach nur 20 Sekunden wartet. Dies wurde erforderlich, da ich Laufzeitprobleme feststellen konnte, wenn der Nextcloud-Container startet, bevor die Datenbank im MariaDB-Container initialisiert war. Dieses Konstrukt ist nicht schön und ich bin für Verbesserungsvorschläge offen.

Zwischenfazit

Die Erstellung der Ansible-Rolle hat länger gedauert, als angenommen. Dies liegt nur zum Teil in meiner spärlichen Freizeit begründet. Einen größeren Einfluss darauf hatte die Dokumentation zum Nextcloud-Repository. Diese geht davon aus, dass man ein Dockerfile bzw. Docker-Compose verwendet. So war noch etwas Internet-Recherche erforderlich, um den Pod letztendlich ans Laufen zu bringen.

Dieser Artikel beschäftigte sich mit den Tag-1-Aufgaben, an deren Ende eine Nextcloud-Instanz ausgebracht wurde, welche an einen Reverse-Proxy angebunden werden kann.

Im nächsten Artikel gehe ich auf die Konfiguration des NGINX-Reverse-Proxy ein. Hierbei habe ich einige Überraschungen erlebt, welche mich an der Reife des Projekts [2] zweifeln lassen.

Quellen und weiterführende Links

1. Nextcloud System Requirements — https://docs.nextcloud.com/server/latest/admin_manual/installation/system_requirements.html
2. Nextcloud (Official Image) — https://hub.docker.com/_/nextcloud
3. MariaDB (Official Image) — https://hub.docker.com/_/mariadb
4. GitHub Tronde/ansible_role_deploy_nextcloud_with_mariadb_pod
5. podman_pod – Manage Podman pods
6. podman_container – Manage podman containers

Mozilla bereitet den Start seines nächsten Premium-Angebotes vor. Dieses richtet sich vor allem an Webentwickler. Der Start soll bereits im März sein, auch im deutschsprachigen Raum.

Mozilla ist vor allem für seine kostenlosen Produkte wie den Browser Firefox bekannt. Um den Nutzern zusätzliche Mehrwerte zu bieten, aber auch um die finanzielle Abhängigkeit von Suchmaschinen-Anbietern zu reduzieren, setzt Mozilla vermehrt auch auf kostenpflichtige Premium-Angebote wie das Mozilla VPN oder Firefox Relay Premium. Mozillas nächstes Premium-Angebot richtet sich in erster Linie an Webentwickler.

MDN Plus – Entwickler-Dokumentation mit Zusätzen

Die kostenfreie Entwickler-Dokumentation MDN Web Docs, ehemals Mozilla Developer Network, dürfte vermutlich jedem bekannt sein, der bereits mit dem Thema Webentwicklung in Berührung kam. Immerhin ist dies wohl für viele die Anlaufstelle Nummer Eins, wenn es um Themen wie HTML, CSS und JavaScript geht. Und um das direkt klarzustellen: Die MDN Web Docs werden weiterhin kostenlos bleiben. Allerdings wird Mozilla mit MDN Plus ein kostenpflichtiges Zusatzangebot schaffen.

Das Angebot selbst dürfte nicht jeden überraschen, immerhin testete Mozilla bereits im vergangenen Sommer eine Frühversion von MDN Plus. Das Versprechen: Monatliche Artikel mit besonderem Tiefgang zu bestimmten Themen von Branchen-Experten sowie Features, um mehr für sich persönlich aus den MDN Web Docs herauszuholen. Bereits mit Ende des Experiments kündigte Mozilla an, dass man an einem offiziellen Launch arbeiten wird.

Das wissen wir bereits über MDN Plus

Wie meine Recherchen ergeben haben, steht der offizielle Launch von MDN Plus unmittelbar bevor. Bereits ab dem 9. März 2022 dürfte es soweit sein. Zu den Start-Ländern gehören neben Deutschland, Österreich und der Schweiz auch die USA, Kanada, das Vereinigte Königreich, Frankreich, Italien, Spanien, Belgien, die Niederlande, Irland, Malaysia, Neuseeland sowie Singapur.

Neben den bereits erwähnten zusätzlichen Inhalten soll es mehrere Features für Plus-Nutzer geben. Dazu zählt die Möglichkeit, die MDN Web Docs offline nutzen zu können, sich seine persönliche Sammlung anlegen zu können, auf die man von jedem Gerät aus zugreifen kann, sich über Änderungen bestimmter Artikel benachrichten lassen zu können, sowie Themes, um die Plattform ein Stück weit dem eigenen Geschmack anpassen zu können. Wobei nicht unerwähnt bleiben soll, dass man mit seinem Beitrag nicht nur diese zusätzlichen Inhalte und Features bezahlt, sondern eben auch die MDN Web Docs als Plattform damit unterstützt, die von Mozilla seit über 16 Jahren kostenlos bereitgestellt wird.

Der Preis soll nach meinen Informationen bei 10 USD pro Monat respektive 100 USD pro Jahr liegen. Bei uns dürfte die gleichen Zahlen dann vermutlich als Euro-Preise gelten, wenn man von Mozillas bisherigen Premium-Produkten ausgeht.

Der Beitrag Exklusiv: Mozillas nächstes Premium-Angebot richtet sich an Entwickler erschien zuerst auf soeren-hentzschel.at.

Ubuntu 22.04 wirft seine Schatten voraus und die Derivate folgen. Nun nehmen auf die elementary-Entwickler Version 7 in den Blick, das auf Ubuntu 22.04 aufsetzen wird. Ein paar Gedanken dazu.

Bekanntermaßen finde ich die Pantheon Shell eine wirklich tolle Desktopumgebung und das insbesondere seit mit Fedora, Arch Linux und openSUSE (OBS) auch andere Distributionen diese ausliefern. Es ist ganz erstaunlich, was da aus kleinen Anfängen gewachsen ist und im Gegensatz zu anderen GNOME-Sprösslingen haben die Entwickler sich hier gleichermaßen emanzipiert, wie auch ein augenscheinlich gutes Verhältnis zu GNOME bewahrt. Deutlich kritischer ist meine Sicht auf die Distribution elementary OS. Momentan fahre ich noch ein Experiment mit elementary OS 6 und Flatpaks, dessen Ausgang weiterhin offen ist.

In ihren monatlichen Berichten haben die elementary-Entwickler Ende Januar die Verlagerung des Fokus auf elementary OS 7 angekündigt. Das ist einerseits nachvollziehbar, weil man vermutlich eine extrem lange Distanz zwischen Ubuntu-Release und elementary-Release vermeiden möchte. Wir erinnern uns: Beim letzten Mal benötigte man über ein Jahr, um eine neue Version auf neuer Ubuntu-Basis zu veröffentlichen. Andererseits ist Version 6 damit weniger als ein Jahr nach Veröffentlichung schon wieder ein Auslaufmodell. Die Erfahrung lehrt, dass die elementary-Entwickler es nicht hinbekommen, mehrere Stränge parallel zu pflegen. Elementary OS 6 wird somit nur noch die nötigsten Bugfixes erhalten.

Dank der Flatpaks erhalten die Anwender trotzdem noch Updates für die Anwendungen und der Übergang auf die kommende Version dürfte hier weniger steinig sein. Schließlich sind die Flatpaks für Version 6 auch unter Version 7 lauffähig und das App Center bleibt daher gut gefüllt. Vermutlich hat elementary hier früh aus richtige Pferd gesetzt, schließlich will auch Flathub demnächst eine Bezahlfunktion einführen.

Andere Bereiche lassen einen da deutlich mehr zweifeln. Aktuell gibt es keine Upgraderoutine, um von einer elementary-Version auf die Nächte zu aktualisieren. Die Entwickler nehmen diese zwar in den Blick, aber selbst wenn diese – was sie ja nicht versprechen – bis Version 7 kommen sollte, sind Funktionen bei elementary am Anfang selten so ausgereift, dass diese wirklich alltagstauglich sind. Weiterhin verstehe ich nicht, warum man immer noch auf Ubuntu als Basis setzt. Die Sollbruchstellen sind kaum noch zu übersehen. Ubuntu setzt auf Snaps, elementary auf Flatpak. Ubuntu will bei 22.04 noch weitestgehend auf Gtk4-Apps verzichten, elementary möchte vollständig auf Gtk4-Apps wechseln. Man kann sich durchaus fragen, wie lange das noch gut geht.

Licht und Schatten sind wie immer bei elementary ganz nah beieinander.

Der Artikel elementary OS nimmt Version 7 in den Blick erschien zuerst auf [Mer]Curius

hugo new site uxgch
hugo new theme uxgch

title: "Sinn des Lebens"
date: 2007-05-27T13:10:31+02:00
draft: false
tags: [ "tv", "sinn", "leben" ]
aliases: [ "/1180264231.htm" ] # magic

location / {
  rewrite ^/(tagcloud|holidays|recipes)\.fcgi$ /$1 permanent;
  rewrite ^/tagcloud_(.*)\.htm$ /tags/$1 permanent;
  rewrite ^/linkdump\.xml$ /linkdump/rss.xml permanent;
  rewrite ^/(linux|vegan)\.xml$ /tags/$1/rss.xml permanent;
  rewrite ^/yh\.xml$ /block/rss.xml permanent;
  rewrite ^/all\.xml$ /rss.xml permanent;
}

{{ $style := resources.Get "css/style.scss" | toCSS }}
{{ $lightbox := resources.Get "css/lightbox2/lightbox.min.css" }}
{{ $fontawesome := resources.Get "fontawesome.scss" | toCSS }}
{{ $opensans := resources.Get "open-sans.scss" | toCSS }}
{{ $css := slice $fontawesome $opensans $lightbox $style | resources.Concat "css/bundle.css" | minify }}
{{ if ne hugo.Environment "development" -}}
  {{ $css = $css | fingerprint -}}
{{ end -}}
<link rel="stylesheet" href="{{ $css.RelPermalink }}">

Fr, 18. Februar 2022, Ralf Hersel

Ubuntu Touch OTA-22 ist heute erschienen und führt Unterstützung von FM-Radio ein, um echten analogen Radioempfang auf unterstützten Geräten zu ermöglichen. Im Moment ist nur die Daemon-Implementierung in der OTA-22-Version enthalten, während eine FM-Radio-Anwendung in den nächsten Wochen im App Store verfügbar sein sollte.

Ubuntu Touch OTA-22 bringt auch gute Nachrichten für Besitzer anderer Geräte dank der Implementierung von WebGL-Unterstützung, die ein schnelleres 3D-Rendering ermöglicht. Darüber hinaus folgen die QQC2-Apps nun dem Systemthema und die Kameraunterstützung wurde in den Morph-Webbrowser integriert, sodass die Nutzer nun endlich Videoanrufe tätigen können.

"Dies ist wahrscheinlich die wichtigste Funktion dieses OTAs", so UBports. "Viele Leute haben uns gebeten, Videoanrufe als Option anzubieten. Jetzt läuft noch immer im Browser, aber wir denken, dass es bereits eine grosse Erleichterung sein kann. Und es ist der Türöffner für Videogespräche in Apps."

Es gibt auch gute Nachrichten für Volla Phone X-Besitzer im OTA-22-Update, das Unterstützung für den Fingerabdruckleser hinzufügt und verschiedene Probleme behebt, die Nutzer mit der vorherigen Version hatten. Dies alles ist möglich dank des Wechsels zu einer neueren Basis für das System-Image, Halium 10.

Darüber hinaus können OnePlus 5 und OnePlus 5T-Besitzer jetzt einen vollständigen Ubuntu Touch-Port geniessen, der sofort funktioniert, und Google Pixel 3a und Google Pixel 3a XL-Besitzer erhalten mit diesem Update eine bessere Klangqualität und Lautstärkeregelung sowie einen sogenannten "Booster-Modus" aktiviert, der die Anzahl der CPUs begrenzt und andere Batteriesparoptionen konfiguriert, wenn der Bildschirm ausgeschaltet ist.

Zu guter Letzt fügt das OTA-22-Update dem Begrüssungsbildschirm (Sperrbildschirm) Unterstützung für die Rotation sowie ein neues Layout für die Notrufleiste am unteren Rand hinzu, und die Dialer-App erhielt eine automatische Vervollständigung des Wähltastenfelds, damit man schneller auf Kontakte zugreifen kann.

Ausserdem wurden einige Bugs beseitigt, um das Beschneiden von MMS-Bildern in der Messaging-App zu verhindern, den Shader-Cache für QML zu verbessern, den Fingerabdruckleser auf OnePlus 5T-Geräten funktionsfähig zu machen und zu ermöglichen, dass sie in den Ruhezustand zurückkehren, wenn eine Push-Benachrichtigung eintrifft, sowie die Kamerarechte auf einigen Geräten durchzusetzen.

Das Ubuntu Touch OTA-22-Update wird jetzt auf alle unterstützten Geräte ausgerollt.

Quelle: https://ubports.com/de/blog/ubports-blogs-nachrichten-1/post/ubuntu-touch-ota-22-release-3835

Fr, 18. Februar 2022, Lioh Möller

Es gibt eine Vielzahl von grafische Markdown Editor für Linux, mit unterschiedlichen Schwerpunkten. Zettlr vereint die Fähigkeiten eines mächtigen Bearbeitungsprogramms mit einer Verschlagwortungsfunktion und vielen weiteren Extras. Insbesondere bei komplexen Texten, helfen diese dabei, die Übersicht zu behalten.

Tags lassen sich pro Dokument hinzufügen. Die zentrale Suche ermöglicht das schnelle Auffinden zuvor definierter Schlagwörter.

Eine weitere Möglichkeit stellt der sogenannte Zettelkasten dar. Mit dessen Hilfe lassen sich interne Dokumente verlinken, ähnlich wie bei einem Wiki. Bei einem Klick auf einen solchen Link mit gedrückter Ctrl-Taste wird das Zieldokument angezeigt und gleichzeitig in der Seitenleiste eine Volltextsuche nach dem Wort durchgeführt.

Zettlr bietet Exportmöglichkeiten in gängige Formate, welche mittels Pandoc/LaTeX realisiert wurden. Die Anwendung integriert eine vollwertige Rechtschreibkorrektur und bietet einen Dark-Mode, welcher sich bei Bedarf auch zeitgesteuert aktivieren lässt.

Der integrierte und optional nutzbare Pomodoro-Timer hilft dabei, die Bildschirmzeit zu reduzieren und Pausen einzuhalten.

Es stehen Pakete für Debian und Fedora, sowie AppImages zum Download zur Verfügung.

Download: https://www.zettlr.com/download
Git-Repository: https://github.com/Zettlr/Zettlr

Mozilla hat mit Firefox 97.0.1 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht.

Download Mozilla Firefox 97.0.1

Mit dem Update auf Firefox 97.0.1 blockiert Mozilla die aktuelle Version einer von der Sicherheits-Software WebRoot SecureAnywhere injizierten DLL-Datei unter Windows, da diese zur völligen Unbenutzbarkeit von Firefox führen konnte. WebRoot wird das Problem in einem zukünfigten Update seiner Sicherheits-Software beheben.

Außerdem hat Mozilla einen Fehler behoben, der für manche Nutzer mit deaktivierter Sitzungswiederherstellung fälschlicherweise zu einem Bildschirm beim Firefox-Start führte, der aussagte, dass Firefox die Tabs nicht wiederherstellen konnte.

Behoben wurde auch ein Fehler, der auf der Video-Plattform Hulu dafür sorgte, dass der Bild-im-Bild-Modus nicht aktiviert werden konnte und das Video stattdessen pausierte. Ein anderes behobenes Problem betrifft die Video-Plattform TikTok, wo es sein konnte, dass Videos, welche von der Profilseite eines Nutzers geöffnet werden sollten, nicht öffneten.

Schließlich wurde noch eine Absturzursache behoben, welche ausschließlich Windows 7 betroffen hat, sowie eine weitere Absturzursache, welche ausschließlich Linux betroffen hat.

Der Beitrag Mozilla veröffentlicht Firefox 97.0.1 erschien zuerst auf soeren-hentzschel.at.

Mi, 16. Februar 2022, Lioh Möller

Kinoite gehören zur Mineralklasse der 'Silikate und Germanate'. Der bläulich-silbern schimmernde Glanz hat wohl die Entwickler des Fedora-Abkömmlings zur Namensgebung inspiriert.

Ähnlich wie Fedora Silverblue gehört Kinoite zu den sogenannten immutable Systemen, das heisst das Basissystem ist grundsätzlich unveränderlich. Die Distributionen unterscheiden sich vorwiegend in der Wahl der Standard-Desktopumgebung. Im Gegensatz zu Silverblue, kommt bei Kinoite KDE Plasma zum Einsatz. Grundlegende Mechanismen wie rpm-ostree sind auch dort gültig.

Die Installation erfolgt mit dem von Fedora bekannten Anaconda Installationsprogramms, wobei die Einrichtung der Benutzerkonten von Silverblue abweicht. Der Root-Account ist standardmässig deaktiviert, der anzulegende Benutzer erhält allerdings erst nach Auswahl der entsprechenden Option, die Möglichkeit Administratoren-Rechte zu erlangen. Wurde dies nicht aktiv konfiguriert, lässt sich die Installation nicht starten.

Wurde diese Hürde erst einmal genommen, präsentiert sich Kinoite mit einem leicht angepassten KDE Plasma Desktop. Damit einher geht die grafische Softwareverwaltung mit dem Programm Discover. Wie auch bei Silverblue ist das Flathub Repository standardmässig nicht aktiviert. Die Möglichkeit 3rd Party Repositories über einen Assistenten zu integrieren, wie es bei Silverblue der Fall ist, gibt es nicht. Sobald Flathub anhand der offiziellen Anleitung des Projektes eingebunden wurde, lassen sich Applikationen aus dem Repository über Discover installieren und das System so erweitern.

Damit stellt Kinoite eine verlässliche Alternative für Nutzer des KDE Plasma Desktops dar und hebt sich aufgrund der neuen Systemarchitektur von klassischen Linux-Distributionen ab.

Quelle: https://kinoite.fedoraproject.org/

Mi, 16. Februar 2022, Lioh Möller

Fedora Silverblue und Kinoite sind primär auf die Nutzung von Flatpaks ausgelegt. Dennoch kann es in einigen Fällen notwendig sein, RPM Pakete zu installieren. Möglich macht dies rpm-ostree, welches die benötigten Anwendungen als Overlay einbinden kann.

Bisher bietet rpm-ostree keine integrierte Suche, wie beispielsweise dnf. Sollte der Paketname unbekannt sein, kann dnf in einer toolbox zur Hilfe genommen werden.

Falls bisher noch keine toolbox erzeugt wurde, lässt sich dies mit dem folgenden Befehl nachholen:

toolbox create -y

Die dnf Suche lässt sich daraufhin innerhalb der toolbox wie folgt ausführen:

toolbox run dnf search nano

Nachdem der passende Paketname ermittelt wurde, erfolgt die eigentliche Installation mit rpm-ostree:

rpm-ostree install nano

Die Änderungen werden nach einem Neustart des Systems appliziert.

Alternativ lässt sich die experimentelle Funktion apply-live nutzen:

sudo rpm-ostree ex apply-live

Di, 15. Februar 2022, Ralf Hersel

In den letzten Wochen haben wir einige Beiträge zum Thema 'Linux für Einsteiger' geschrieben und in diesem Artikel ein Fazit gezogen. Es wurden 9 verschiedene Distros mit unterschiedlichen Konzepten und Desktop-Umgebungen betrachtet. Bei der Vorauswahl haben wir nur solche Systeme in Erwägung gezogen, die wir für Einsteiger:innen geeignet hielten. Deshalb gab es keine Gewinner und Verlierer, sondern eine Palette an Distributionen, die wir empfohlen haben.

Nach einigem Nachdenken, bin ich zum Schluss gekommen, dass die Desktop-Umgebung für Anfänger:innen wichtiger ist, als die darunter liegende Distribution. Dem mag man widersprechen, weil es nicht lange dauert, bis die Anwender die Unterschiede entdecken. Dennoch, der erste Eindruck zählt, und dieser wird von der Oberfläche und nicht vom Unterbau geprägt.

'Seeing is believing', sagt der Volksmund. Man muss etwas sehen, um es zu glauben; sichtbare Fakten lassen sich nicht leugnen. Die Einsteigerin sieht den Installationsprozess, die Einführung und den Desktop. Bei der aktuellen Aufmerksamkeitsspanne, die bei wenigen Minuten liegt, müssen diese Erfahrungen ausreichen, um einen Einsteiger von der gewählten Distro/Desktop-Kombination zu überzeugen.

'The Linux Experiment' zu diesem Thema

Der grosse Vorteil von GNU/Linux-Distributionen und den Desktop-Umgebungen, ist deren Vielfalt. Das muss man nicht als Verwirrung, sondern als freie Auswahl ansehen. Auch beim Wocheneinkauf schätzt man die Wahl zwischen den Barbecue-Sossen, Joghurts und Pasta-Sorten.

Daher empfehle ich in diesem Nachtrag, sich an den grossen und etablierten Desktop-Umgebungen zu orientieren. Diese sind:

• KDE-Plasma : Windows-ähnlich mit vielen Einstellungsmöglichkeiten
• GNOME-Shell : Modern und auf das Wesentliche reduziert
• Xfce : Solide, klassisch zu bedienen und für ältere Computer geeignet

Selbstverständlich gibt es weitere Desktops, die für spezielle Anwendungsfälle besser geeignet sind. Das geht jedoch über das hinaus, was eine Einsteigerin interessieren sollte. Denn für Euch, die in die GNU/Linux-Welt einsteigen möchtet, reicht die Auswahl zwischen diesen drei Desktops vollkommen aus. Alles andere kommt später.

Mein Tipp: schau Dir die drei Desktops an, und wähle das Erscheinungsbild, welches Dir am besten gefällt. Alle relevanten Distributionen bieten diese drei Desktop-Umgebungen an. Wenn es später um die beste Distro für Deine Zwecke geht, wendest Du Dich an die Community und lässt Dich beraten.

Unter macOS hatte ich mit LibreOffice seit einiger Zeit das Problem, dass es nur weiße Seiten ausdruckte. Auch die entsprechende Druckvorschau unter macOS war leer. Das Erzeugen von PDFs und der anschließende Druck hingegen funktionierten ohne Probleme. Die Druckvorschau zeigt nur leere Seiten Verursacht wird der Fehler wohl durch die Bibliothek Skia, bei welcher es sich um eine freie 2D…

Quelle

Dies ist der Beginn meines zweiten Container-Projekts. Nach Kanboard im Container möchte ich diesmal eine Nextcloud-Instanz als Container, zusammen mit einem Datenbank-Container, in einem Podman-Pod betreiben.

Da ein einzelner Artikel vermutlich zu lang wird, teile ich das Projekt in mehrere Artikel auf. Wie viele es genau werden, kann ich jetzt noch nicht sagen. Am Ende der Reihe werde ich hier eine Übersicht einführen und die einzelnen Teilen entsprechend miteinander verbinden.

In diesem ersten Teil geht es um meine Motivation, das eigentliche Ziel und den groben Plan.

Was Leser dieser Reihe erwartet

Ihr könnt mich durch diese Reihe begleiten und euch von meinen Erlebnissen und Erkenntnissen unterhalten lassen. Dabei dürft ihr nicht annehmen, dass es sich bei dem von mir beschriebenen Vorgehen um eine gute Praxis handelt. Hier gilt eher: Der Weg ist das Ziel.

Ihr seid herzlich eingeladen, die Artikel zu kommentieren und über das Vorgehen und Alternativen dazu zu diskutieren. Gern in der Kommentarsektion unter den jeweiligen Beiträgen oder als Artikel in euren eigenen Blogs.

Ich plane die Artikel im Wochenrhythmus, wenigstens monatlich, zu veröffentlichen. Bitte verzeiht, wenn es etwas unregelmäßig wird. Dies ist ein Hobby, dem nur begrenzt Zeit zur Verfügung steht.

Motivation

Bei Linux-Containern handelt es sich um eine Technologie, die gekommen ist, um zu bleiben. Sie hat bereits in vielen Branchen Fuß gefasst und immer mehr Projekte bieten ihre Anwendungen zusätzlich oder ausschließlich in Form von Containern an.

Als Sysadmin mittleren Alters werden mich Linux-Container sicher noch viele Jahre begleiten. Um praktische Erfahrungen mit dem Betrieb zu sammeln, möchte ich einige private Projekte in Containern betreiben.

Beruflich arbeite ich überwiegend mit RHEL. Red Hat engagiert sich stark in den Projekten Ansible und Podman, welche ich auch unter anderen Distributionen, wie z.B. Debian, einsetze. Ich möchte das Projekt als Chance nutzen, mein Wissen auch in diesen Werkzeugen zu festigen und auszubauen.

Ich spiele schon seit einiger Zeit mit dem Gedanken, wieder eine eigene Nextcloud-Instanz zu betreiben. Da auf dem zur Verfügung stehenden Server bereits eine Nextcloud-Instanz läuft und ich meine Anwendung von der bestehenden Instanz getrennt und möglichst losgelöst vom Betriebssystem betreiben möchte, habe ich mich entschieden, Nextcloud im Container zu betreiben.

Ziele

Ziel dieses Projekts sind das Deployment und der Betrieb einer Nextcloud-Instanz als Podman-Pod. Im Einzelnen sollen folgende Ziele erreicht werden:

1. Entwicklung eines wiederverwendbaren Verfahrens zum Deployment einer Nextcloud im Container
2. Persistente Speicherung von Konfigurations- und inhaltlichen Daten im Dateisystem des Hosts
3. Konfiguration eines Reverse-Proxies (NGINX) für den Zugriff auf die Nextcloud-Instanz
4. Konfiguration von Backup und Restore für Konfiguration und Inhalte der Nextcloud-Instanz
5. Konfiguration und Test automatischer durch Ansible gesteuerter Updates

Umgebung

Für die Umsetzung des Projekts steht mir ein Virtual Private Server (VPS) mit genügend Ressourcen zur Verfügung. Dieser wird in einem Rechenzentrum in Deutschland betrieben. Auf diesem sind Debian Bullseye, NGINX, ein OpenSSH-Server, Podman 3.0.1 (rootless) und Python 3.9.2 installiert. Damit erfüllt dieses System die Voraussetzungen, um mit Ansible konfiguriert zu werden und Container ausführen zu können.

Ansible selbst läuft in meiner privaten Arbeitsumgebung auf meinem Debian-PC und einem Fedora-35-Notebook.

Methodik und verwendete Werkzeuge

Zu Beginn habe ich mich etwas in der Nextcloud-Dokumentation und den verfügbaren Nextcloud-Images belesen. Besagte Dokumentation sowie die der verwendeten Werkzeuge sind im folgenden Abschnitt verlinkt.

Um die oben formulierten Ziele zu erreichen, werde ich in einem Python Virtual Environment eine Ansible-Version installieren, mit der ich die Collection containers.podman nutzen kann. Hiermit werde ich eine Ansible-Rolle entwickeln, die ich wiederverwenden kann, um Nextcloud-Instanzen in einer rootless-Podman-Umgebung zu deployen. Die Ansible-Rolle wird anschließend auf meinem GitHub-Account veröffentlicht.

Die Konfiguration von NGINX und acme.sh für die TLS-Zertifikate erfolgt manuell.

Quellen und weiterführende Links

In diesem Abschnitt liste ich Links zu Artikeln und Dokumentationen auf, welche ich im Vorfeld gelesen habe und deren Kenntnis ich für die Umsetzung als nützlich erachte. Zur besseren Übersicht gliedere ich diese in die Unterabschnitte Hintergrundwissen, Dokumentation und Eigene Artikel.

Die weiteren Artikel dieser Reihe

• Nextcloud im Container – Teil 2: Die Ansible-Rolle
• Nextcloud im Container — Teil 3: Mit Reverse-Proxy
• Nextcloud im Container — Teil 4: Hier und da klemmt es
• Nextcloud im Container – Teil 5: Backup und Restore
• Nextcloud im Container – Teil 6: Updates

Hintergrundwissen

• Architecting Containers Part 1: Why Understanding User Space vs. Kernel Space Matters; Scott McCarty (fatherlinux); July 29, 2015
• Architecting Containers Part 2: Why the User Space Matters; Scott McCarty (fatherlinux); September 17, 2015
• Architecting Containers Part 3: How the User Space Affects Your Application; Scott McCarty (fatherlinux); November 10, 2015
• A Practical Introduction to Container Terminology; Scott McCarty (fatherlinux); February 22, 2018
• Podman: Managing pods and containers in a local container runtime; Brent Baude; January 15, 2019
• Installing Nextcloud 20 on Fedora Linux with Podman; fedora MAGAZINE; DSchier; February 15, 2021
• How to set up and use Python virtual environments for Ansible; Enable Sysadmin; Gineesh Madapparambath; 2021-08-18
• https://de.wikipedia.org/wiki/Ansible
• https://de.wikipedia.org/wiki/Nextcloud
• https://de.wikipedia.org/wiki/Containervirtualisierung

Dokumentation

• https://docs.ansible.com/
• https://docs.nextcloud.com/
• https://hub.docker.com/_/nextcloud
• https://github.com/docker-library/docs/blob/master/nextcloud/README.md

Eigene Artikel

• Kanboard im Container…
• Reverse-Proxy für Kanboard im Container
• Backup und Restore im Kanboard-Container-Land
• Aktualisierung eines Kanboard-Pods

Der Sinn eines verifizierten Systemstart (engl. „verified boot“) ist sicherzustellen, dass beim Start Komponenten aus vertrauenswürdigen Quellen geladen werden und es Angreifern nicht gelingt, manipulativ in den Prozess einzugreifen. Grundsätzlich ist vieles davon Linux nicht fremd, aber wird zum Teil aktiv unterlaufen.

Einordnung und Kontext

Die Themen verifizierte Systemstart, Secure Boot und TPM beschäftigen mich momentan. Befasst man sich mit vollständig verschlüsselten Systemen, der zusätzlichen Bindung an TPM bzw. Secure Boot, zusätzlich gegeneinander durch Verschlüsselung abgeschirmten Home-Verzeichnissen und weiterführenden Fragen, wie der Sicherheit biometrischer Verfahren und welche zusätzlichen Schutzmaßnahmen durch zusätzliche Hardware-Tokes wie FIDO2 (YubiKey) möglich sind, dann ist der verifizierte Systemstart letztlich ein logisches weiteres Puzzlestück.

Natürlich handelt es sich dabei um „advanced“ Sachen. Wer sein System nicht verschlüsselt, andauernd irgendwelche Programme von Dritten herrunter lädt und sich Kernel aus irgendwelchen PPAs installiert, der hat dadurch überhaupt keinen Sicherheitsgewinn. Ich respektiere es auch, wenn man solche „Trusted Computing“-Konzepte ablehnt oder ihnen zumindest misstraut. Ich ermuntere dennoch dazu, hier nicht einfach irgendwas nachzuplappern, weil (insbesondere in der deutschen Community?) in dem Bereich viele urbane Legenden kursieren. Neben abstrakten Informationsquellen ist meine konkrete Arbeitsgrundlage für viele Experimente das Arch Linux-Wiki und das ist nun wirklich kein Vertreter von „Corporate Linux“.

Der Blick über den Tellerrand

Der verifizierte Systemstart ist dabei keinesfalls irgendwie exotisch. Systeme wie iOS oder Android haben das ebenso implementiert, wie Windows 11 oder macOS. Das Prinzip ist einfach: Es wird eine vollständige Vertrauenskette aufgebaut. Angefangen von einer vertrauenswürdigen (Hardware-)Wurzel, bei der jeweils eine geladene Stufe die nächste authentifiziert. Also von der Hardware, über den Bootloader zu den entsprechenden Systempartitionen bis hin zu den Benutzerdaten. Das entsprechende Verfahren kann z. B. hier für Android nachgelesen oder ist hier sehr anschaulich viel Windows 11 (vor allem Abbildung 1 für Leser ohne Lust auf langwierige technische Inhalte) dargestellt. Solche Verfahren können noch mit einem Rollback-Schutz und anderen Sachen kombiniert werden, aber das führt jetzt hier zu weit.

Was kann Linux theoretisch?

Folgende Boot-Abfolge kann Linux bzw professionelle Linux-Distributionen momentan theoretisch bieten:

• UEFI startet shim (was letztlich nur eine Zertifikatesammlung mit Signatur von Microsoft ist). Das kann in das s. g. „TPM boot measure“ (keine Ahnung, wie man das gut übersetzt?) einbezogen werden.
• Shim ruft den Bootloader (i. d. R. GRUB) auf, der mit einem Schlüssel des Distributors signiert ist. GRUB kann theoretisch in das „TPM boot measure“ einbezogen werden.
• Alternativ ist theoretisch der direkte Start über ein Unified Kernel Image möglich.
• Der Bootloader ruft den Kernel auf und übergibt initrd. Der Kernel ist durch den Distributor signiert, initrd ist nicht signiert oder validiert. Kernel und initrd können theoretisch in „TPM boot measure“ einbezogen werden.
• Bei verschlüsselten Systemen fragt initrd nun nach dem Passwort für die verschlüsselte Root-Partition. Es erfolgt keine Verifikation, ob initrd manipuliert oder ähnliches wurde. Es erfolgt der Übergang ins Root-Dateisystem. Die per LUKS verschlüsselte root-Partition kann an den TPM Secure Boot Status gebunden werden.
• Abschließend erfolgt eine Anmeldung des Benutzers in der Loginmaske der Desktopumgebung. Die Daten sind bereits vorher entschlüsselt, sofern der Administrator nicht eine individuelle Konfiguration mit systemd-homed, eCryptFS oder separaten LUKS-Partitionen pro Benutzer eingerichtet hat.

Was macht Linux faktisch?

• Secure Boot wurde deaktiviert, weil man irgendwo gelesen hat, dass man das tun sollte.
• TPM ist ebenfalls deaktiviert, auf der Modul-Blacklist oder wird einfach nur nicht beachtet. Selbst wenn TPM nicht deaktiviert ist, macht eine Einbeziehung in GRUB oder initrd momentan wegen des unzureichenden Implementierungsgrades keinen Sinn.
• GRUB lädt ein nicht signiertes initrd und einen nicht signierten Kernel.
• Bei verschlüsselten Systemen fragt initrd nun nach dem Passwort für die verschlüsselte Root-Partition. Es erfolgt keine Verifikation, ob initrd manipuliert oder ähnliches wurde. Es erfolgt der Übergang ins Root-Dateisystem.
• Abschließend erfolgt eine Anmeldung des Benutzers in der Loginmaske der Desktopumgebung. Die Anmeldung ist Makulatur, da die Daten bereits vorher entschlüsselt wurden, daher erfolgt oft ein einfacher Autologin.

Ist das ein Problem?

Das hängt wie bereits oben geschildert, von der Frage ab, welches Sicherungsbedürfnis man hat. Nutzt man sowieso keine Verschlüsselung, braucht man weitere Schutzmaßnahmen eh nicht. Insbesondere auf Entwicklungssystemen ohne schutzwürdige Daten verzichtet man häufiger auf Verschlüsselung. Hier kann man dann also auch nach Belieben mit nicht signierten Kernel, selbst gebauten Modulen etc. arbeiten.

Nutzt man eine Verschlüsselung nur, um Gelegenheitsblicke von neugierigen Kollegen, Freunden oder Familienmitgliedern zu entgehen, dann benötigt man weiterführende Maßnahmen ebenso eher nicht. Es sei denn man hat eine Tochter, die gerade an einer Bewerbung für den Geheimdienst als Hackerin arbeitet.

Hat man aber ein Schutzbedürfnis für sich selbst erkannt und nutzt ein vollständig verschlüsseltes Betriebssystem, um seine Daten sicher vor den Blicken professioneller Angreifer zu schützen, dann hat der aktuelle Zustand erhebliche Schwachstellen und einige zumindest seltsame Aspekte:

• Man startet ein verschlüsseltes System von einer i.d.R. unverschlüsselten boot-Partition, ohne zu prüfen, was eigentlich mit initrd und Kernel passiert ist und gibt dort das Passwort ein. Dieses Problem wird aktuell gelöst durch eine verschlüsselte Boot-Partition, was aber GRUB immer mehr aufbläht und noch unwartbarer macht als es eh schon ist.
• Das System lässt sich einfach kopieren und danach mit Brute Force so lange „quälen“ bis man drin ist. Die Verschlüsselung mit LUKS kennt dagegen keine Schutzmaßnahmen und verhindert das auch nicht.
• Man gibt ein Passwort beim Start ein, um das Betriebssystem zu entschlüsseln und entschlüsselt nebenbei die Benutzerdaten. Der eigentliche Benutzerlogin ist nur Makulatur und weil das den meisten Anwendern klar ist, überspringen sie oft auch den Benutzerlogin per Autologin.
• Benutzerdaten sind bei Multiuser-Systemen nur mit den UNIX-Rechten gegeneinander abgeschirmt und je nach Distribution nicht mal das.

Schlussbemerkung

Das Thema ist perspektivisch kein „Entweder-Oder“, sondern ein „Und“. So wie in der Vergangenheit immer die Möglichkeit bestand, nicht verschlüsselte Systeme zu nutzen, obwohl die Distributionen die LUKS-Verschlüsselung zunehmend prominenter in den Installationsroutinen platzierten, so wird auch der verifizierte Startvorgang Einzug halten für jene, die es benötigen oder dies zumindest glauben bzw. wohl eher fürchten. Alle anderen können, aber müssen dies nicht nutzen. Unstrittig ist jedoch, dass man aktuell ein bisschen hinter den anderen Betriebssystemen her rennt und nicht mal die Möglichkeiten ausreizt, die man schon hat. Spannend dürfte sein, was Enterprise-Distributionen wie SUSE Linux oder Red Hat Enterprise Linux hier in den nächsten Jahren umsetzen. Bei beiden Firmen ist man an den Themen dran.

Das war (voraussichtlich) der letzte Artikel zu diesem Thema für die nächste Zeit. Alle, die von Secure Boot, TPM, GRUB, verified Boot & Co schon genervt sind, können also entspannt in die Zukunft schauen 😉

Der Artikel Verifizierter Systemstart (Verified Boot) – Der Stand bei Linux erschien zuerst auf [Mer]Curius

Die Linux-Community, ihre Eigenheiten und komischen Ausprägungen beschäftigen mich schon länger. Das dürfte für viele Leser hier nichts Neues sein. Momentan frage ich mich aber, ob das Problem nicht sehr spezifisch die deutschsprachige Linux-Community betrifft?

Meine Beobachtung zu den Unterschieden bei Wikipedia hatte ich kürzlich schon mal hier dargelegt. Nun bin ich aufgrund eines anderen Themas auf die systemd-Artikel bei Wikipedia gestoßen. Schauen wir uns mal drei Artikel an, deren Sprache ich beherrsche:

• Deutsche Wikipedia: systemd
• Englische Wikipedia: systemd
• Spanische Wikipedia: systemd

Die Unterschiede sind eklatant. Das ist keineswegs ein „Wikipedia-Phänomen“, denn diese Artikel schreiben Prinzip-bedingt Autoren mit Affinität zum Thema Linux bzw. Mitglieder einer weiter gefassten „Linux-Community“.

Der englischsprachige Artikel ist sehr umfassend, was vermutlich an der größeren Autoren- und Leserschaft liegt. Es geht um Geschichte, technisches Design, die zugehörigen Komponenten, die Verbreitung unter den verschiedenen Linux-Distributionen und ganz am Schluss kommt die Rezeption bzw. Kritik an systemd, sowie alternative Implementierungen. Die spanischsprachige Wikipedia orientiert sich an der englischsprachigen Wikipedia, hat aber einen längeren Teil mit Anleitungscharakter und nur einen kurzen Kritikteil.

Bei der deutschen Wikipedia geht es ganz kurz um Geschichte und Funktion und dann auf knapp 7000 Zeichen um die Kritik an systemd. Dazu ist die Auswahl der Meldungen verglichen mit der englischsprachigen Version höchst tendenziös, da immer nur die Kritik und selten die Entscheidungen und Problemlösungen thematisiert werden. Repliken auf diese Kritik (Lennart Poetterings „The biggest Myths“), die in der englischsprachigen Wikipedia erwähnt werden, finden in der deutschsprachigen Wikipedia keinen Widerhall.

Der englischsprachige Leser hat am Ende der Lektüre einen guten Überblick über Geschichte, Design, Funktionen und Kritik an systemd. Dem deutschsprachigen Leser bleibt der Eindruck, eine katastrophale Technologie hätte sich irgendwie durchgesetzt.

Läuft da was falsch bei der deutschsprachigen Linux-Community? Ist das ein spezifisches Wikipedia-Problem? Mich würden da auch Meinungen bzw. Kommentare von Lesern interessieren, die vielleicht auch in anderssprachigen Linux-Communitys unterwegs sind.

Der Artikel Sonderwege der deutschsprachigen Linux-Community? erschien zuerst auf [Mer]Curius

Verschlüsselung für mobile Betriebssystem wie Android ist trivial und mit wenigen Einstellungen aktiviert. Wegen einiger Änderungen in der Vergangenheit gibt es für Android jedoch viele veraltete Informationen.

Verschlüsselung ist bei Desktop-Betriebssystemen wie Windows, Linux oder macOS eine peinliche Leerstelle. Obwohl es für alle drei Systeme leistungsfähige Lösungen gibt, verzichten alle Hersteller auf eine standardmäßige Aktivierung und Bewerben diese auch nicht aktiv. Während Windows und macOS sich wenigstens noch nachträglich verschlüsseln lassen, schauen Linux-Nutzer in die Röhre, wenn sie bei der Installation die entsprechenden Optionen nicht gesetzt haben.

Nicht so bei mobilen Betriebssystemen. Google und Apple haben in ihre Betriebssysteme für Tablets und Smartphones selbstverständlich leistungsstarke Verschlüsselungsmethoden implementiert, die im Hintergrund automatisch aktiviert werden, sobald der Anwender die Codesperre (sowie ggf. biometrische Verfahren) aktiviert. Bei Android hat Google hier in der Vergangenheit einige Änderungen vorgenommen, weshalb viele Berichte dazu veraltet sind und teils unverständliche Kürzel kursieren.

FDE: Full Disk Encryption

Die FDE-Verschlüsselung stand am Anfang. Technisch gesehen handelte es sich um eine Festplattenverschlüsselung auf Basis von dm-crypt. Insbesondere bei diesen tieferen Bereichen von Android merkt man oft die Linux-Basis, denn letztlich ist das nicht viel anderes als die LUKS-Vollverschlüsselung bei Linux.

Technisch war das natürlich etwas aufwendiger. Die Verschlüsselung erfolgte in der üblichen Blockdevice-Methode, bei der die gesamten Userdata-Partition verschlüsselt wurde. Die Verschlüsselung erfolgte mit einem einzigartigen Schlüssel, der gleichermaßen an den Benutzer-PIN gebunden und mittels TEE signiert wurde. Mit diesem Schlüssel wurden jene Bereiche verschlüsselt, in denen Android Benutzerdaten speichert.

Es gab nur ein grundlegendes Problem. Bei einem Neustart des Android-Smartphones waren viele Funktionen nicht verfügbar, bevor der Anwender seine Passphrase eingegeben hatte. Beispielsweise Wecker oder auch Telefonanrufe. Das war natürlich für ein Smartphone-Betriebssystem keine zufriedenstellende Lösung.

Diese Lösung steht nach einer längeren Übergangsphase nicht mehr zur Verfügung. Android ab Version 10 nutzt nur noch die FBE-Methode.

FBE: File Based Encryption

Um diese Beschränkungen zu beheben, hat Google ab Android 7 die dateibasierte Verschlüsselung (FBE) eingeführt. Dabei handelte es sich um eine Neuentwicklung auf Basis des für Android verwendeten Dateisystems ext4. Die Umstellung hat je nach OEM-Hersteller etwas gedauert, weshalb zwischen den Versionen 7 und 9 die Verschlüsselung je nach Konfiguration und Hersteller unterschiedlich funktioniert hat, aber heute ist FBE die Standardverschlüsselung.

Ein netter Nebenaspekt: Diese Erweiterung des ext4-Dateisystems zog mit Kernel 4.1 bzw. 4.6 (fscrypt) direkt upstream ein und kommt dadurch allen Linux-Anwendern zugute. Die Adaption verzögerte sich hier etwas, aber mit systemd-homed steht nun erstmals eine praktikable Umsetzung für den Linux-Desktop zur Verfügung.

Technisch gibt es zwei Bereiche. Den Standarspeicherplatz (Credential Encrypted = CE), der erst nach der Entschlüsselung zur Verfügung steht und den sogenannten Device Encrypted (DE) Speicher, der während des Direct Boot-Verfahrens Anwendungen ermöglicht mit begrenztem Datenzugriff zu funktionieren.

Anfänglich war ein Nachteil der FDE-Methode die fehlende Verschlüsselung der Metadaten (Berechtigungen, Dateigröße, Verzeichnis-Layout etc.). Diese berechtigte Kritik – z. B. in diesem Short Paper – kann man auch heute noch häufiger lesen, wenn es um Android-Verschlüsselung geht. Das Problem hat Google in Android 9 behoben und es ist somit nicht mehr aktuell.

Der wesentliche Unterschied für den Anwender: Mit FBE gesicherte Android-Geräte booten ganz normal in den Sperrbildschirm und bieten dort auch vor der Entschlüsselung durch den Anwender Funktionalitäten wie Anrufe, Wecker etc.

Aktivierung durch den Anwender

Sobald der Anwender einen PIN, eine Passphrase und/oder biometrische Merkmale hinterlegt hat, ist die Verschlüsselung aktiviert. Normalerweise geschieht dies bereits bei der Initialisierungsroutine. Anwender müssen mehrfache Warnungen überspringen, um ihre Geräte ohne entsprechenden Schutz nutzen zu können. Das ist meiner Ansicht nach die richtige Vorgehensweise. Überprüfen lässt sich der Status in den Einstellungen und Sicherheit und dort in Verschlüsselung und Anmeldedaten.

Hier ist wie aus dem folgenden Screenshot bei „Smartphone verschlüsseln“ der Status Verschlüsselt zu sehen. Weitere Einstellungsmöglichkeiten oder Handlungsbedarf bestehen nicht.

Der Artikel Verschlüsselung unter Android – Von FDE zu FBE erschien zuerst auf [Mer]Curius

Do, 10. Februar 2022, Lioh Möller

In den vergangenen Wochen haben wir unterschiedliche Linux-Distributionen auf Einsteigertauglichkeit getestet. Dabei kamen zuvor definierte Bewertungskriterien zum Einsatz.

Folgende Distributionen konnten wir in unsere Tests einbeziehen:

• Fedora Silverblue
• Debian GNU/Linux
• Manjaro
• Siduction
• Linux Mint LMDE
• openSUSE Leap
• Ubuntu 22.04 LTS (pre-release)
• openSUSE Tumbleweed
• ZorinOS

Natürlich stellt die Auswahl nur einen Bruchteil der verfügbaren Linux-Derivate dar. Dennoch vermittelt sie ein gutes Gesamtbild über den aktuellen Stand der Entwicklungen.

Grundsätzlich lassen sich die Distributionen in drei Bereiche aufteilen. Dazu gehören einerseits klassische Ansätze wie bei openSUSE Leap, Ubuntu LTS, Debian GNU/Linux oder ZorinOS, andererseits Rolling-Release Lösungen wie Siduction, Manjaro oder openSUSE Tumbleweed. Fedora Silverblue verfolgt als einzige Immutable Distribution in unseren Tests neue Wege und bietet aufgrund der Stabilität und reibungslosen Updatefähigkeit ein ideales System für Einsteiger.

Davon unabhängig eignen sich alle vorgestellten Lösungen gut für einen ersten Kontakt mit dem Freien Betriebssystem. Teilweise unterstützen Assistenten oder Handbücher bei der Einarbeitung.

Fast alle getesteten Distributionen sind mit den drei grossen Desktop-Umgebungen, KDE-Plasma, GNOME-Shell und Xfce verfügbar. Obwohl wir nur jeweils eine Desktop-Variante getestet haben, sollte diese nicht den Ausschlag für die Wahl eines Einsteigers geben. Alle drei Umgebungen sind gut für Um- oder Einsteiger geeignet. Hier liegt es am persönlichen Geschmack, was einem besser gefällt.

Möchte man ein System haben, welches man einfach nur benutzen kann, ohne sich tiefer mit den Konzepten von Linux auseinanderzusetzen, ist Fedora Silverblue oder ZorinOS eine gute Wahl. Siduction hingegen bietet ausführliche Dokumentationen und Anlaufstellen bei Fragen an. Ambitionierte Einsteiger können zu Manjaro oder openSUSE Tumbleweed greifen. Und wer Linux von der Basis ab kennenlernen möchte, dem sei ein Blick in den Slackware basierten Linux-Kurs empfohlen.

Die MZLA Technologies Corporation hat mit Thunderbird 91.6 ein planmäßige Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.6

Mit dem Update auf Thunderbird 91.6 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit aktuelle Sicherheitslücken. Darüber hinaus bringt das Update diverse Fehlerbehebungen der Versionsreihe 91, welche sich in den Release Notes (engl.) nachlesen lassen.

Der Beitrag Thunderbird 91.6 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Anlässlich des gestrigen Releases von KDE Plasma 5.24, das die Möglichkeit Fingerabdrücke zur Authentifizierung einzusetzen, offiziell integriert möchte ich hier noch mal explizit davor warnen. Erstens weil biometrische Daten nicht zur Authentifizierung geeignet sind und zweitens weil Linux nicht die sichere Infrastruktur dafür bietet.

Ich hatte vor etwas mehr als einem Jahr, als die Bestrebungen Fahrt aufnahmen, bereits vor dieser Methode gewarnt und möchte das hier noch mal aufgreifen. Biometrische Daten sind nicht nur ungeeignet zur Authentifizierung, sondern Linux bietet nicht die notwendige Infrastruktur, um solche Daten sicher abzulegen. Die Implementierung in Linux ist ein einziges Sicherheitsrisiko und Datenverlust eine plausible Möglichkeit. Nur weil etwas freie Software ist, darf man dem nicht blind vertrauen.

Biometrische Daten zur Authentifizierung

Der erste Punkt ist natürlich, dass man besser keine biometrischen Daten zur Authentifizierung nutzt. Sie vermitteln ein falsches Sicherheitsgefühl und beim Verlust lassen sie sich nicht ersetzen. Kursiert der eigene Fingerabdruck irgendwo, kann man sich schlecht einen neuen generieren lassen. Andererseits nutzten vor dem Aufkommen solcher Verfahren viel zu wenige Anwender sichere PINs oder Passwörter für ihre mobilen Geräte. Entweder schützte man diese gar nicht oder mit simplen Wischmustern. Fingerabdruck oder Gesichtserkennung bieten hier durchaus einen Mehrwert. Mehrwert aber nur, wenn dieser Fingerabdruck sicher gespeichert wird.

Auf keinen Fall mit Linux!

Die größte Gefahr besteht darin, dass der Fingerabdruck verloren geht bzw. gestohlen wird. Google, Apple, Microsoft – sie alle sind sich dessen bei biometrischen Daten bewusst. Alle drei Anbieter haben in ihren Geräten sogenannte Sicherheitschips verbaut (Apple: Secure Enclave; Google: Titan M; Microsoft: TPM) mit denen sie solche Daten schützen. Die Daten der Fingerabdrücke können nicht vom Gerät exportiert werden.

Irgendwer kommt jetzt bestimmt wieder mit proprietärem Code und proprietärer Hardware, der man nicht vertrauen kann. Das ist Mist, mit dem man den desolaten Zustand unter Linux schönredet! Jeder Programmierer macht Fehler, kein Code ist perfekt, manchmal muss man durch die Architektur neue Sicherheitsmethoden einbauen.

Google, Apple & Co haben diese Verfahren sehr effizient eingesetzt, bisher sind trotz milliardenfacher Nutzung keine Daten abhandengekommen. Zudem speichern diese Firmen die Fingerabdrücke nicht als Bild, sondern als Hashwert. Die Apps bekommen durch das ausgefeilte Berechtigungssystem keinen direkten Zugriff auf den Fingerabdruck selbst, sondern führt nur einen Abgleich mit dem Hash durch – grob vereinfacht erklärt. Das sind die technischen Standards zur Verarbeitung biometrischer Daten und sie sind gerade so ausreichend (eigentlich sollten wir gar keine biometrischen Daten verarbeiten!)

Linux kann gar nichts davon! Hinter solchen Frontends wie bei Plasma kommt fprint zum Einsatz, die Authentifizierung erfolgt über PAM. Linux kann momentan noch nicht ausgreift und flächendeckend mit Sicherheitschips umgehen. Die Daten werden somit einfach im System gespeichert (wo auch sonst bei den aktuellen Möglichkeiten?) und können von dort auch mit entsprechenden Rechten exportiert werden.

Und da kommt mir bitte keiner mit dem tollen Berechtigungssystem von UNIX bzw. Linux. Das ist uralt und garantiert nicht für so hoch sensible Daten entworfen worden. Ein kritischer Fehler und sudo, PolKit oder wo auch immer und und wir sitzen richtig im Dreck! Berechtigungskonzepte für Apps haben wir jenseits von Flatpak gar nicht und noch immer kommen genug Helden auf die Idee, grafische Programme mit Administratorrechten zu starten. KDE hat das gerade erst wieder offiziell für Dolphin möglich gemacht.

Ich finde es in Ordnung, wenn Linux-Anwender sagen, die misstrauen Sicherheitschips wie TPM, aber dann lassen sich halt manche Funktionen wie ein biometrisches Authentifizierungsverfahren nicht umsetzen. Man kann nicht alles haben!

Schlussbemerkung

Dieser Text ist sehr hart und sehr plakativ geschrieben und man könnte zu vielen Punkten mehr schreiben und manches differenzieren. Aber anlässlich der Veröffentlichung von KDE Plasma 5.24 gestern, sehe ich mich in der Pflicht hier eindrücklich zu warnen. Es ist schön, wenn Entwickler sich mit so etwas befassen und hier grundlegende Methoden entwickeln. Wenn ein System aber nicht die geeignete Hardware-Infrastuktur hat, dann kann man an einem gewissen Punkt nicht weiter arbeiten.

Wenn Microsoft, Apple oder Google biometrische Authentifizierungsmaßnahmen so stümperhaft umgesetzt hätten, wäre jeder IT-Experte in jeder denkbaren Weise über sie hergefallen. Bei Linux ist das wieder okay, weil es ja freie Software ist und so. Nein, einsehbarer Code schützt nicht vor allem! Wenn hier Daten verloren gehen, kommen Heartbleed, Boothole und Debians OpenSSL-Fiasko zusammen. Will sagen: Dann ist der Ruf von Linux endgültig im Eimer!

Nachtrag 09. Februar 2022:

Anscheinend bin ich mit meiner Meinung hier wenigstens nicht ganz alleine. Durch einen Kommentar auf Linuxnews bin ich auf diesen Bugreport bei Debian aufmerksam geworden, der auf eine entsprechende Diskussion im GitLab von fprint verweist. Bitte folgenden Kommentare zur Kenntnis nehmen:

There are no short-term plans to fixing this. Any attempts at encrypting the fingerprints would just be security through obscurity as the decryption would need to be made available to fprintd and would therefore be available to other processes.

The only way to currently safeguard the fingerprints is to run with SELinux, AppArmor or another LSM enabled, and made sure that only the fprintd binary has access to those saved fingerprints.

Mal abgesehen davon, dass ich selbst die dort angedachten Schutzmaßnahmen für unzureichend halte, nutzt nur Fedora / RHEL SELinux in einer ausreichenden Konfiguration.

Folgende Aussage des Entwicklers bitte sich ebenfalls Gemüte führen:

I think we might entertain such ideas if anyone can actually point to proper research that shows it is feasible. Before then, I will continue to assume that anything like that is impossible.

Bei diesem Problembewusstsein frage ich mich, ob Debakel wirklich noch die ausreichende Beschreibung ist?

Der Artikel Warnung: Nutzt keine Fingerabdruck-Authentifizierung mit Linux! erschien zuerst auf [Mer]Curius

Mi, 9. Februar 2022, Ralf Hersel

"Zorin OS ist eine auf Ubuntu basierende Linux-Distribution, die speziell für Linux-Neulinge entwickelt wurde. Sie hat eine Windows-ähnliche grafische Benutzeroberfläche und viele Programme, die denen von Windows ähneln. Zorin OS wird auch mit einer Anwendung geliefert, mit der Windows-Programme ausgeführt werden können. Das Ziel der Distribution ist es, eine Linux-Alternative zu Windows zu bieten und Windows-Benutzern alle Funktionen von Linux ohne Komplikationen zur Verfügung zu stellen", besagt die Selbstbeschreibung von Zorin OS.

Für diesen Test habe ich mich für die Variante 'Zorin OS 16 Core' entschieden. Neben dieser gibt es auch eine Pro- und eine Lite-Version. Die Unterschiede werden auf der Download-Seite erklärt. Kurz gesagt, Core verwendet die GNOME-Shell als Desktop-Umgebung, Lite nimmt Xfce und Pro bringt unter anderem einen Desktop-Layout Switcher mit und kostet 39 Euro.

Die Version 16 stammt von August 2021, hat einen 5.13er Kernel, Gnome 3.38, Python 3.5, LibreOffice 7.1 und basiert auf Ubuntu 20.04.3 LTS. Über Zorin OS haben wir bereits des Öfteren geschrieben; schaut in den Artikelindex, um die bisherigen Berichte zu lesen.

Installation

Die ISO-Datei ist 2.7 GB gross und kann von der Download-Seite bezogen werden. Da Zorin auf Ubuntu beruht, gibt es zum Installationsprozess nicht viel zu sagen. Er funktioniert und sieht so aus, wie man ihn von fast allen Ubuntu-Derivaten kennt.

Eine Sache hat mich dennoch überrascht, die 'Volkszählung'. Diese seltsam übersetzte Option für die Telemetrie stammt auch von Ubuntu und ist als Opt-out ausgelegt. Im Gegensatz zum Original gibt es während des Installationsprozesses keine Zorin-eigene Slide-Show. Stattdessen sieht man nur das Zorin-Logo.

Ich gebe 4 von 5 Punkten, wegen der 'Volkszählung' und der verpassten Chance, die Anwenderin während der Installation zu informieren/unterhalten.

Einführung

Nach dem ersten Start sieht man die stark modifizierte GNOME-Desktop-Umgebung, die (für meinen Geschmack) sehr gut aussieht. Eine Begrüssung oder Einführung gibt es leider nicht. Der Desktop bietet zwar ein modernes Design, folgt aber dem klassischen Bedienkonzept. Es gibt ein Panel mit Menü, Favoriten-Apps und den System-Tray.

Wie man im Screenshot sehen kann, sieht alles sehr klar und aufgeräumt aus. Im Panel befinden sich: Menü, Desktop-Overview, Firefox, Dateien und der Software-Manager. Im System-Tray geht es auch sauber zu: Lautstärke, Netzwerke, Einstellungen, An/Aus sind in einem Menü vereint. Rechts daneben steht der Kalender.

4 von 5 Punkten wegen der fehlenden Begrüssung und Einführung.

Vollständigkeit

Die Software-Ausstattung (im Menü) sieht folgendermassen aus:

• Büro: LibreOffice, Evolution, GNOME-Kalender und -Kontakte
• Grafik: Eye of GNOME, GNOME-Fotos, GIMP
• Hilfsprogramme: diverse, aber nicht zu viele
• Internet: Firefox, Remmina
• Multimedia: Brasero, Pitivi, Cheese, Rhythmbox, Sound Recorder, Totem
• Spiele: Solitaire, Mahjongg, Minen, Quadrapassel, Sudoku
• Systemwerkzeuge: diverse, aber nicht zu viele
• Zubehör: Aufgaben, Dateien, Karten, Text-Editor, Uhren, Wetter

Die Wahl der vorinstallierten Apps gefällt mir sehr gut; sie stellt eine gute Balance zwischen Notwendigem und Überfrachtung dar.

Das Software-Center bindet die Repositories: main, universe, restricted und multiverse ein. Ausserdem werden eine ganze Reihe von Zorin-eigenen PPAs geladen. Flatpaks und Snap-Pakete stehen ebenfalls zur Verfügung, wobei man die Einstellungen dafür in den Optionen von GNOME-Software nicht findet.

Bei den Einstellmöglichkeiten findet man die nicht-modifizierten GNOME-Settings, das Werkzeug zur GNOME-Optimierung (Tweak-Tool) fehlt, dafür gibt es die Zorin-Appearance mit Optionen für das Desktop-Konzept, Farb-Themen und weiteren Einstellungen. Das ist sehr Einsteiger-freundlich umgesetzt.

Ich gebe 5 von 5 Punkte.

Stabilität

Machen wir es kurz: Ubuntu 20.04 LTS. 5 von 5 Punkten.

Vorkonfiguration

Aus den vorherigen Kapiteln kann man bereits herauslesen, dass die Konfiguration von Zorin OS sehr gut gelungen ist. Das Design und die Benutzerfreundlichkeit schaffen den schwierigen Spagat zwischen modern, funktional, einfach zu bedienen, nicht überlastet, aber auch nicht zu sehr vernagelt. Meiner Meinung nach gehört das zu den Hauptaufgaben einer GNU/Linux-Distribution, denn, Kernel, Systemsoftware, Pakete und Desktops können alle Distros zusammenstellen; die hohe Kunst besteht in der Ausgewogenheit. Diese gelingt Zorin wie kaum einer anderen Distribution.

Klare 5 von 5 Punkten.

Update-Prozess

Machen wir es nicht ganz so kurz wie bei der Stabilität: der Ubuntu Update-Prozess ist bekannt und etabliert. Die Aktualisierungs-Einstellung, welche aus dem Software-Center heraus erreicht werden können, sind minimalistisch. Hier gibt es nur die Optionen 'Automatische Updates' und 'Benachrichtigungen bei eben diesen'; beide Optionen sind eingeschaltet. In der Aktualisierungsverwaltung können beliebige Quellen hinzugefügt und viele weitere Einstellungen gemacht werden. Es gibt keine Optionen zu Flatpaks und Snaps; für die Einsteigerin mag das aber genau das Richtige sein.

Ein Check im Terminal ergab, dass keine Snap-Pakete vorhanden sind und für Flatpaks nicht einmal die Basis installiert ist. Zu Testzwecken habe ich TextSnatcher aus dem Software-Center installiert; die App ist ein Flatpak. Wie erwartet, werden dabei zuerst einmal alle Flatpak-Voraussetzungen installiert; was in meinem Test sehr lange dauerte. Solange möchte kein Einsteiger warten. Hier wäre es besser gewesen, die Flatpak-Basis in der Distro bereitzustellen, insbesondere, da das Software-Center Flatpaks anbietet.

Dafür gebe ich 4 Punkte.

Bewertung

Fazit

'Zorin OS 16 Core' ist einer der Einsteiger-freundlichsten Distributionen, die ich bisher gesehen habe.

Zorin OS mit dunklem Thema

Obwohl ich bei den Kriterien Installation, Einführung und Update-Prozess jeweils einen Punkt vom Maximalwert abgezogen habe, ist Zorin ein Tipp für Einsteiger:innen in die wunderbare GNU/Linux-Welt. Diese Distribution schafft eine Ausgewogenheit, die ich selten gesehen habe. Zorin ist einerseits modern und schick beim Erscheinungsbild, holt den Anwender aber beim Bedienkonzept dort ab, wo er sich auskennt, nämlich bei MS-Windows.

Da Zorin 16 auf Ubuntu 20.04 aufbaut, ist damit zu rechnen, dass es in diesem Jahr eine neue Version geben wird, die auf Ubuntu 22.04 LTS setzt, und damit auch ein paar der Neuerungen von GNOME 42 abbekommen wird.

Download: https://zorin.com/os/download/

Mozilla hat Firefox 97 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Neue Farbgebungen für Firefox

Bereits jetzt nutzen mehr Nutzer ein farbiges Theme als das mit Firefox standardmäßig ausgelieferte dunkle Theme oder auch Alpenglow, das optionale Design, welches seit Firefox 81 zusätzlich ausgeliefert wird. Dafür bietet Mozilla auf seiner Erweiterungs-Plattform addons.mozilla.org eine Auswahl von zig tausenden Themes an.

Um noch mehr Nutzer auf diese Möglichkeit der Anpassung aufmerksam zu machen, hatte Mozilla Firefox 94 und folgende Versionen mit 18 zusätzlichen Themes, sogenannten Farbgebungen, ausgeliefert, welche mit dem heutigen Tag ausgelaufen sind und nicht mehr zur Auswahl stehen. Wer sich für eine dieser Farbgebungen entschieden hatte, kann diese aber noch weiterhin nutzen.

Mit Firefox 97 liefert Mozilla dafür sechs ganz neue Farbgebungen aus – auch diese sind wieder zeitlich limitiert verfügbar.

Außerdem zeigt die Add-ons-Verwaltung deaktivierte Theme nicht länger blasser an, womit die Vorschaubilder repräsentativer sind, und fügt auch kein „(deaktiviert)“ mehr hinter den Namen an. Dass Themes deaktiviert sind, wird ohnehin durch die entsprechende Überschrift klar.

Verbesserungen der Entwicklerwerkzeuge

In den Entwicklerwerkzeugen erlaubt der Inspektor bei gedrückter Shift-Taste jetzt auch die Auswahl von Elementen, welche aufgrund einer pointer-events: none-Regel ansonsten nicht auswählbar wären.

Das Farbpipette-Werkzeug funktioniert jetzt auch auf Websites, bei denen eine Content Security Policy (CSP) zuvor verursachen konnte, dass das Werkzeug nicht funktionierte.

Sonstige Neuerungen von Firefox 97

Für die Darstellung von Scroll-Leisten nutzt Firefox unter Windows jetzt den neuen Stil von Windows 11.

Unter macOS wurden Verbesserungen beim Laden von System-Schriften vorgenommen, welche unter bestimmten Voraussetzungen in einem schnelleren Öffnen und Wechseln von Tabs resultieren.

Die Verwendung der „Zum Tab wechseln“-Funktion in der Adressleiste beeinflusst jetzt auch die Gewichtung der Adressleisten-Vorschläge, so dass ein Häufiges Verwenden dieser Funktion für eine bestimmte Seite dafür sorgen kann, dass diese in den Vorschlägen zukünftig höher erscheint.

Die Passwortverwaltung unter about:logins hat eine verbesserte Tastatur-Steuerung erhalten (Pfeil rauf / runter zum Wechseln des Eintrags, Enter zum Auswählen, ESC zum Leeren des Suchfelds). Außerdem wurde die Performance des CSV-Imports von Zugangsdaten (kann in about:config via signon.management.page.fileImport.enabled aktiviert werden) signifikant verbessert.

Hardware-WebRender ist jetzt auch auf Systemen mit Lucienne-Chip von AMD standardmäßig aktiviert.

Die Option print.tab_modal.enabled, um den alten Drucken-Dialog, welcher in Firefox 86 vor knapp einem Jahr ersetzt wurde, wieder zu aktivieren, wurde entfernt. Netzwerk-Drucker, die von Firefox bislang nicht angezeigt worden sind, werden jetzt angezeigt, sofern diese innerhalb einer bestimmten Zeit gefunden werden.

Das Problem, dass auf YouTube bei Verwendung der Textsuche die Positionen der Suchergebnisse neben der Scroll-Leiste nicht angezeigt worden sind, gehört der Vergangenheit an.

Verbesserungen der Webplattform

Die CSS-Einheiten cap und ic werden ab sofort für Längenangaben unterstützt, außerdem die @-Regel @scroll-timeline und die animation-timeline-Eigenschaft. Die Eigenschaft color-adjust wurde umbenannt in print-color-adjust. Neu ist auch die Unterstützung von @layer sowie die Unterstützung für die Eigenschaft scrollbar-gutter.

In SVG-Grafiken kann das d-Attribut jetzt auch via CSS gesteuert werden.

Eine Übersicht über alle Verbesserungen der Webplattform sowie Verbesserungen für WebExtension-Entwickler gibt es wie immer in den MDN web docs.

Geschlossene Sicherheitslücken

Auch in Firefox 97 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 97 daher für alle Nutzer dringend empfohlen.

Dazu kommen wie immer weitere Fehlerbehebungen sowie sonstige Verbesserungen unter der Haube dazu.

Der Beitrag Mozilla veröffentlicht Firefox 97 erschien zuerst auf soeren-hentzschel.at.

Zu einem guten Smart Home gehört natürlich auch eine schöne „Kommandozentrale“. Obwohl das Haus ja schlau ist und alles selbst entscheiden soll, möchte man ja dennoch wissen, was gerade los ist. Der Home Assistant, eine freie und open source Software für Hausautomatisierung, bietet mit seinen Dashboards genau solche Übersichten an. Mit wenigen Klicks lassen sich die Messdaten aus dem Haus und um das Haus visualisieren.

Regenradar und weitere Wetterdaten

Das Wetter spielt natürlich eine entscheidende Rolle für das Haus und die Bewohner. Die erste Anlaufstelle für aktuelle Wetterdaten und Vorhersagen könnte beispielsweise OpenWeatherMap sein. Die API ist gut dokumentiert, die Einbindung in den Home Assistant ist reibungslos, der Dienst ist kostenlos und es fällt keine Werbung an. Einzig eine Registrierung auf der Webseite ist nötig, um den verpflichtenden API-Schlüssel zu erhalten.

Was leider fehlt, ist der Regenradar. Jede Vorhersage ist ja nur so gut, wie die, die man mit eigenen Augen sieht. Darum lohnt es sich, einen Regenradar in das Home Assistant Dashboard einzubinden.

Die meisten Regenradare lassen sich nicht besonders einfach einbinden. Und falls doch, sind sie meistens mit Werbung übersät. Um so schöner ist es, dass die Webseite morgenwirdes.de den Regenradar vom Deutschen Wetterdienst (DWD) aufbereitet und uns als animierte gif-Datei zur Verfügung stellt. Die Einbindung in den Home Assistant ist explizit erlaubt und funktioniert folgendermaßen.

Einbindung in den Home Assistant

Zunächst bastelt man sich die URL zusammen, die man für sein Dashboard braucht. Das geht relativ einfach, wenn man sich die Struktur der URL ansieht.

https://morgenwirdes.de/api/v3/gif4.php?plz=12345&delay=70&type=1&zoomlvl=1&bar=0&map=1&textcol=ffffff&bgcol=03a9f4

Die Flagge „plz“ gibt die Postleitzahl vor. Delay ist die Zeit in Millisekunden, die pro Zeitstufe angezeigt wird. Es gibt zwei Farbschemen der Karte, typ=0 oder 1. Der Zoomlvl gibt den Zoomlevel an (hier 1 für ganz Deutschland). Eine Zeitleiste (bar) und Hintergrundkarte (map) können optional eingeblendet werden. Farblich anpassen kann man die Karte mit den beiden letzten Flaggen.

In der configuration.yaml habe ich das dann als Kamera eingebunden. Das hat den Vorteil, dass die Daten immer aktualisiert werden. Würde man es als Bild einbinden, könnte es sein, dass der Regenradar nur aus dem Cache geladen wird und deshalb nicht aktuell ist.

##### Kameras und Wetterkarten
camera:
  - platform: generic
    still_image_url: 
https://morgenwirdes.de/api/v3/gif4.php?plz=12345&delay=70&type=1&zoomlvl=1&bar=0&map=1&textcol=ffffff&bgcol=03a9f4
    name: regenradar

In Lovelace, dem Dashboard von Home Assistant, fügt man nun ein Picture-Glance hinzu, schon ist das Radar da:

type: picture-glance
title: Regenradar
entities: []
camera_image: camera.regenradar

Update 15.04.2022:

Ich habe den Artikel angepasst, das Bild wird nicht mehr als normales Bild, sondern als Kamera eingebunden. Dadurch wird das Radar zuverlässiger aktualisiert.

The post Home Assistant: Animiertes Regenradar einfügen first appeared on bejonet - Linux | Smart Home | Technik.

Es gibt vor allem in Deutschland kollektive Vorbehalte gegen moderne Techniken wie TPM oder Secure Boot. Sie sind nicht exklusiv für die Linux-Gemeinschaft, aber dort besonders stark verbreitet. Diese sind nicht auf Fakten gegründet, sondern basieren auf langjährig gepflegten Mythen.

Ich beschäftige mich aktuell ja mit Themen wie TPM. Ein Thema, um das ähnlich wie um Secure Boot unfassbar viel Fear, Uncertainty and Doubt (FUD) gestreut wird. Das ist keinesfalls von Nischenphänomen, sondern findet sich an hochkarätiger Stelle.

Die englischsprachige Wikipedia schreibt in ihrem Artikel als Einleitung zu TPM:

Trusted Platform Module (TPM, also known as ISO/IEC 11889) is an international standard for a secure cryptoprocessor, a dedicated microcontroller designed to secure hardware through integrated cryptographic keys. The term can also refer to a chip conforming to the standard.

TPM is used for digital rights management (DRM), Windows Defender, Windows Domain logon, protection and enforcement of software licenses, and prevention of cheating in online games.

One of Windows 11’s system requirements is TPM 2.0. Microsoft has stated that this is to help increase security against firmware and ransomware attacks.

Und weiter:

Overview

Trusted Platform Module provides
A hardware random number generator
Facilities for the secure generation of cryptographic keys for limited uses.
Remote attestation: Creates a nearly unforgeable hash key summary of the hardware and software configuration. One could use the hash to verify that the hardware and software have not been changed. The software in charge of hashing the setup determines the extent of the summary.
Binding: Encrypts data using the TPM bind key, a unique RSA key descended from a storage key[clarification needed].
Sealing: Similar to binding, but in addition, specifies the TPM state for the data to be decrypted (unsealed).
Other Trusted Computing functions for the data to be decrypted (unsealed).

Wikipedia, Artikel „Trusted Platform Module“ unter Creative Commons Attribution-ShareAlike 3.0 Unported License (abgerufen am 08. Februar 2022.

Der deutschsprachige Artikel beginnt mit:

Das Trusted Platform Module (TPM) ist ein Chip nach der TCG-Spezifikation, der einen Computer oder ähnliche Geräte um grundlegende Sicherheitsfunktionen erweitert. Diese Funktionen können beispielsweise dem Lizenz- und Datenschutz oder der nachrichtendienstlichen Kontrolle dienen. Der Chip verhält sich in einigen Punkten wie eine fest eingebaute Smartcard, allerdings mit dem wichtigen Unterschied, dass er nicht an einen konkreten Benutzer, sondern an den lokalen Computer gebunden ist. Außer der Verwendung in PCs und Notebooks kann das TPM in PDAs, Mobiltelefonen und Unterhaltungselektronik integriert werden. Ein Gerät mit TPM, speziell angepasstem Betriebssystem und entsprechender Software bildet zusammen eine Trusted-Computing-Plattform (TC-Plattform). Eine solche „vertrauenswürdige Plattform“ kann nicht mehr entgegen den Interessen des Herstellers genutzt werden, sofern dieser Beschränkungen festgelegt hat. Ein möglicher Vorteil für einen normalen Benutzer eines solchen Systems liegt im Schutz gegen softwareseitige Manipulation durch unbefugte Dritte.

Der Chip ist aktuell überwiegend passiv und kann weder den Bootvorgang noch den Betrieb direkt beeinflussen. Er enthält einen eindeutigen kryptografischen Schlüssel und kann damit zur Identifizierung des Rechners genutzt werden. Das ist jedoch nur möglich, wenn der Eigentümer das Auslesen dieser Information auch gestattet hat. Bei x86-basierten PCs konnte das TPM bisher im BIOS vollständig deaktiviert werden, so dass keine seiner Funktionen zur Verfügung steht. Allerdings gibt es immer mehr Anwendungen, die nur auf einer TC-Plattform mit aktiviertem TPM laufen, wie es z. B. bei Windows seit der Version 11 der Fall ist.

Wikipedia (de.), Artikel „Trusted Platform Module“ unter Creative Commons Attribution-ShareAlike 3.0 Unported

Der Unterschied ist eklatant. Der deutsche Artikel enthält in der Einleitung FUD in seiner Reinform, kaschiert und versteckt im Mantel vorgeblich neutraler Beschreibung plus den Hinweis, wie man es abschalten kann.

Das selbe Spiel kann man mit Secure Boot durchspielen. Einmal der Eintrag in der deutschsprachigen Wikipedia und einmal der Eintrag in der englischsprachigen Wikipedia. Aus Gründen der Redundanz verzichte ich hier auf die Vollzitate, denn der Mechanismus ist der Gleiche. Der Abschnitt in der deutschsprachigen Wikipedia ist tendenziös, verweist auf uralte Sicherheitslücken und hinsichtlich der Zertifikate und Shim auch nicht korrekt. (Vgl. dazu auch das Zitat weiter unten aus dem Debian Wiki)

Da wundert es einen nicht, warum in Deutschland auf die Ankündigung von Microsoft, künftig in Windows 11 TPM 2.0 zur Voraussetzung zu machen, so viel Unsicherheit und Vorbehalte vorherrschten. Dabei ist das langfristig die richtige Entscheidung von Microsoft. Ein etwas überzeichneter Artikel dazu, der aber vielleicht für manchen gewinnbringend sein kann: Packungsbeilage TPM.

In einigen Kreisen – besonders gerne bei Open Source-Anhängern – herrschen bezüglich solcher Techniken wie TPM oder Secure Boot unglaubliche Vorbehalte, die teilweise auf langjährig gepflegten Mythen basieren und bei denen einem abstrakten Risiko erstaunlich selten der konkrete Nutzen gegenüber gestellt wird. Die Ursache dafür liegt meiner Ansicht nach in alten Berichten, die vor vielen Jahren Angst geschürt haben. Das ist irgendwie bei vielen Lesern – vor allem im deutschsprachigen Raum – hängen geblieben. Das hat man inzwischen selbst bei den ursächlichen Medien eingesehen, die heute kritisch auf die eigene damalige Berichterstattung schauen und festhalten, dass daran nichts dran ist.

Noch erstaunlicher ist, dass die FUD-Verbreiter in der Linux-Community sogar gegen die eigenen Knowledge-Bases – die offiziellen Wikis der Distributionen – argumentieren. Dazu kann man beispielsweise auf die tollen Artikel zu TPM und Secure Boot im Arch Linux Wiki verweisen, aber auch konservativere und auf Freiheit bedachte Distributionen wie Debian haben das längst sauber dokumentiert:

What is UEFI Secure Boot NOT?

UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve.

SB is also not meant to lock users out of controlling their own systems. Users can enrol extra keys into the system, allowing them to sign programs for their own systems. Many SB-enabled systems also allow users to remove the platform-provided keys altogether, forcing the firmware to only trust user-signed binaries.

Debian Wiki Artikel Secure Boot (zuletzt abgerufen am 08.02.2022)

Aus diesem Grund hat man viel zu lange in der Linux-Community Bausteine wie Secure Boot oder TPM links liegen gelassen und es kursieren abenteuerliche Anleitungen für Einsteiger, wie böse Secure Boot ist und was sie alles in UEFI-Settings deaktivieren sollten, bevor sie Linux installieren können.

Die Zukunft gehört solchen Technologien, denn die Sicherheitskonzepte von vor 20 Jahren sind halt auf die Bedrohungen von vor 20 Jahren gemünzt. Heute speichern wir andere Daten auf den Geräten, nutzen sie für andere Zwecke und sind anderen Bedrohungsszenarien ausgesetzt. „Mein System ist Open Source und ich gebe ein Passwort beim Start ein“ ist kein alleinig ausreichendes Sicherheitskonzept mehr. Passend zum Thema sind kürzlich die neuen Sicherheitsrichtlinien der US-Regierung herausgekommen (die natürlich weit darüber hinausgehen). Das BSI wird sicher irgendwann nachziehen und wenn man nicht wünscht, dass Linux eines Tages offiziell vor der Tür bleiben muss, weil es elementare Sicherheitsstandards nicht erfüllt, dann ist jetzt die Zeit proaktiv mit der Implementierung zu beginnen.

Mobile Plattformen und macOS haben vorgemacht, wohin die Reise geht und Windows zieht hier mit der neuen Version Windows 11 konsequent nach. Dabei schließen sie dankenswerterweise die PC-Plattform nicht ab, sondern ermöglichen es Linux ebenfalls von diesen Entwicklungen zu profitieren.

Also hört auf jedem zu raten, Secure Boot und TPM zu deaktivieren und blockiert nicht TPM über die Modul-Blacklist – es sei denn, ihr versteht wirklich, warum ihr was tut.

Der Artikel Kollektive Vorbehalte gegen TPM und Secure Boot – Ängste, Unsicherheit und Zweifel erschien zuerst auf [Mer]Curius

LUKS (dm-crypt) ist die Standardverschlüsselungsmethode. Dank systemd ist es seit Kurzem ein vollständig mit LUKS verschlüsseltes Linux-Betriebssystem mittels FIDO2 oder TPM zu entsperren. Das kann in Kombination mit anderen Schutzmechanismen Sinn ergeben.

TPM und ein modernes Sicherheitskonzept

Die Sicherheit von Linux (Sicherheit im Sinne des Schutzes der Daten vor unbefugte Einsichtnahme) ist ziemlich einfach aufgestellt. Mach eine Vollverschlüsselung und entsperre beim Hochfahren den Container und gut ist. Was mit den Daten im Standby oder bei der Benutzerabmeldung passiert, ist damit ebenso wenig klar wie Themen wie eine vollständige verifizierte Bootkette. Linux hinkt hier hinter Systemen wie Android oder Windows 11 hinterher.

Das Thema ist aber inzwischen auf der Agenda und ein wichtiger Baustein hier ist das Trusted Platform Module (TPM). Natürlich gehört dazu viel mehr, als hier jetzt aufgezeigt werden kann, aber man profitiert bereits von wichtigen Vorarbeiten wie systemd-cryptenroll.

Eine automatische Entsperrung des LUKS-Systemcontainers mittels TPM macht natürlich keinen Sinn, wenn es der einzige Schutzmechanismus ist. Ein Angreifer benötigt dann nur das Gerät, um an alle Daten zu kommen. Wenn man aber z. B. seine Benutzerdaten mittels systemd-homed verschlüsselt hat und diese bereits geschützt sind, geht es um andere Angriffsszenarien. Zum Beispiel ein sogenannter „Evil Maid“-Angriff, bei dem das Speichermedium entwendet oder ein Systemabbild erstellt wurde. Angriffe auf ein verschlüsseltes System lassen sich schließlich viel leichter mit einem solchen Abbild durchführen.

Hier kommt TPM ins Spiel, denn während die Vollverschlüsselung im Normalbetrieb nicht weiter auffällt, scheitert der Startvorgang, sobald das Speichermedium in einer anderen Hardware steckt oder – und das ist der zweite relevante Punkte – sofern jemand am Secure Boot zugange war. Was natürlich voraussetzt, dass Secure Boot aktiviert ist. Das ist leider dank einer verbreiteten Unart bei Linux oft nicht der Fall, obwohl alle ernst zunehmenden Linux-Distributionen Secure Boot unterstützen.

LUKS mit TPM entsperren am Beispiel von openSUSE

LUKS mit TPM zu entsperren ist gegenwärtig noch experimentell und sollte nur von Personen mit tiefer gehenden Linux-Kenntnissen umgesetzt werden.

Die folgende Anleitung basiert auf openSUSE Tumbleweed, weil die SUSE-Entwickler hier bereits erste relevante Vorarbeiten geleistet haben. Sie lässt sich mit Sicherheit auch auf andere moderne Linux-Distributionen übertragen.

Das relevante Werkzeug systemd-cryptenroll kann nur mit LUKS2-Containern umgehen. OpenSUSE legt bei der Installation aber immer noch einen LUKS1-Container an. Deshalb muss in einem ersten Schritt dieser LUKS konvertiert werden. Das ist einfach und klappt zuverlässig. Einfach mit einem Live-Medium starten und mit folgendem Befehl den LUKS-Container konvertieren:

# cryptsetup convert /dev/<laufwerk> --type luks2 

Konzeptionell bedingt funktioniert die Methode aktuell nur, wenn eine unverschlüsselte Boot-Partition zum Einsatz kommt. Das war bis vor Kurzem noch völliger Standard, inzwischen kann man aber LUKS-Container auch in GRUB entschlüsseln. Wegen der erheblichen Verzögerung nutze ich das jedoch nicht, weshalb das für mich keine Einschränkung ist.

Mein Partitionsszenario sieht wie folgt aus:

:~> sudo lsblk 
NAME                                                MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                                             259:0    0 476,9G  0 disk  
├─nvme0n1p1                                         259:1    0   300M  0 part  /boot/efi
├─nvme0n1p2                                         259:2    0     1G  0 part  /boot
└─nvme0n1p3                                         259:3    0 475,6G  0 part  
  └─cr_nvme-SAMSUNG_MZVLQ512HALU-000H1_S4UHNF0NA02912-part3
                                                    254:0    0 475,6G  0 crypt 
    ├─vg--system-lv--system                         254:1    0    20G  0 lvm   /var
    │                                                                          /usr/local
    │                                                                          /srv
    │                                                                          /root
    │                                                                          /opt
    │                                                                          /
    └─vg--system-lv--benutzerdaten                  254:2    0 455,6G  0 lvm   /home/gheim
                                                                               /home

Nun installiert man noch die TPM-Tools:

$ sudo zypper install tpm2.0-tools

Anschließend rollt man mittels systemd-cryptennroll TPM aus:

Die Verwendung von PCR 7 schützt nicht vor Änderungen an der /boot-Partition. Dadurch kann ein Angreifer eine modifizierte initrd booten und auf die entschlüsselten Daten zugreifen! Um auch diese in den Schutz einzubeziehen, benötigt man PCRs 2, 4, 8 und 9. Dabei müsste man nach jeder Kernel- und Bootloader-Aktualisierung sowie nach jedem Neuaufbau der initrd den Schlüssel neu hinterlegen. Das ist aktuell noch nicht praktikabel und deshalb empfehle ich hier PCR 7. Zukünftig wird das hoffentlich besser werden, das ganze Konzept ist momentan noch work in progress.

Folgende PCR Definitionen stehen theoretisch zur Verfügung:

$ sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/nvme0n1p3 ##Laufwerknamen anpassen

Danach muss man noch die /etc/crypttab modifizieren. Dort dürfte nur eine Zeile hinterlegt sein (ansonsten die entsprechende Systempartition wählen). Dort am Ende Folgendes eintragen: tpm2-device=auto. Das Ergebnis müsste in etwa wie folgt aussehen:

cr_nvme-...  UUID=b7d...  none  x-initrd.attach,tpm2-device=auto

Nun muss noch initrd neu generiert werden:

§ sudo dracut -f

Nach einem Neustart sollte nun keine Passwortabfrage beim Bootvorgang erscheinen und man direkt beim Loginbildschirm landen, wo man den verschlüsselten systemd-homed-Account anmeldet, um seine Daten zu entsperren.

Nacharbeiten und alternative Möglichkeiten

Das LUKS-Volume kann bei einem Problem mit TPM (was in diesem experimentellen Stadium nicht ausgeschlossen werden kann) immer noch mit den zusätzlich hinterlegten Passwörtern entsperrt werden. TPM belegt einfach einen Keyslot in LUKS. Wenn man sich vollständig auf TPM verlassen möchte, muss man die entsprechenden anderen Keys entfernen. Alternativ kann man auch einen langen und besonders sicheren Schlüssel als Wiederherstellungsschlüssel hinterlegen, was ich sowieso empfehle.

Alternativ lässt sich das Prozedere auch mit einem FIDO2-Stick anstelle von TPM durchführen, was vor allem Sinn macht, wenn man kein separat verschlüsseltes Home-Verzeichnis hat und stattdessen einen zweiten Faktor zur Authentifizierung des LUKS-Containers einziehen möchte. Dadurch verschiebt sich das Schutzkonzept, weshalb das nicht hier im Artikel behandelt wird. In dem hier behandelten Kontext wäre ein FIDO2-Stick eher als Schutzmaßnahme für systemd-homed geeignet – was selbstredend auch unterstützt wird. Das Vorgehen unterscheidet sich nur in wenigen Punkten vom hier geschilderten Szenario und kann dem openSUSE-Wiki entnommen werden.

Zusammengefasst

Angesichts der noch sehr jungen Werkzeuge und eher rudimentären Vorarbeiten der Distribution, funktioniert das Ganze bereits sehr gut. Die systemd-Entwickler haben einmal mehr bewiesen, was für gute Werkzeuge sie den Linux-Anwendern zur Verfügung stellen und damit alte, unzureichende und unnötig komplexe Lösungen überflüssig machen.

Die aktuelle Entwicklung ist ein Übergangsstadium hin zu einer verifizierten Kette vom Systemstart bis zum Login des Anwenders, bei der Signierung und Verschlüsselung ineinandergreifen und nur jene Teile verschlüsselt sind, die es auch sein müssen.

Der Artikel Verschlüsseltes Linux mit LUKS mittels TPM 2.0 entsperren erschien zuerst auf [Mer]Curius