Lese-Ansicht

RHEL System Roles: nbde_client

In diesem Artikel stelle ich euch die RHEL System Role nbde_client vor, mit welcher sich Hosts für Network Bound Disk Encryption (NBDE) installieren lassen. Er ist Bestandteil einer losen Serie, in der ich eine Reihe von System Roles vorstelle, mit denen häufig anfallende Aufgaben in der Systemadministration erledigt werden können.

Wer sich zuerst über die genannten Begriffe informieren möchte, lese:

Umgebung

Für das folgende Beispiel verwende ich eine Umgebung, bestehend aus:

  • Einem Ansible-Controller (RHEL 9) mit den Paketen
    • ansible-core
    • rhel-system-roles
  • Jeweils einem RHEL 8 und RHEL 9 Server mit Minimalinstallation und einem LUKS-Gerät (/dev/sdc in den Beispielen in diesem Text)

Die Installation von RHEL sowie der genannten Pakete sind nicht Bestandteil dieses Artikels. Wer hierzu einen Einstieg sucht, findet entsprechende Dokumentation unter:

Die Rolle

Durch die Installation des Pakets rhel-system-roles existiert diese Rolle bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.nbde_client/ und die Dokumentation in /usr/share/doc/rhel-system-roles/nbde_client/README.md. Letztere enthält verschiedene Beispiele für häufige Anwendungsfälle.

Anwendungsfall

In meinem Labor betreibe ich zwei NBDE-Server (TANG-Server) rhel-hetz-tang1 und rhel-hetz-tang2 sowie zwei NBDE-Clients (Clevis-Clients) rhel-hetz-clevis1 und rhel-hetz-clevis2. Die beiden NBDE-Clients besitzen jeweils ein LUKS-Device /dev/sdc, welches aktuell durch eine LUKS-Passphrase gesichert ist.

Zukünftig sollen diese LUKS-Devices durch die Kommunikation mit einem NBDE-Server entschlüsselt werden. Die LUKS-Passphrase soll entfernt werden.

Damit wird zukünftig ein Neustart der Clients aus der Ferne ermöglicht. Gleichzeitig bleibt das verschlüsselte Gerät bei Diebstahl vor unbefugtem Zugriff geschützt.

Das Playbook

Hinweis: Das folgende Playbook ist nicht idempotent. Um dies zu ändern, ist dem ersten Task eine Bedingung hinzuzufügen, damit dieser nur dann ausgeführt werden, wenn die Bedingung erfüllt ist.

Für dieses Beispiel ist die fehlende Idempotenz des Playbooks jedoch kein Problem, da grubby das Argument nur dann hinzufügt, wenn es nicht bereits vorhanden ist.

---
- hosts: clevis
  tasks:
  - name: Configure ip address for interface during early boot
    ansible.builtin.command:
      cmd: grubby --update-kernel=ALL --args='GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0 ip={{ ansible_default_ipv4.address }}::{{ ansible_default_ipv4.gateway }}:{{ ansible_default_ipv4.netmask }}::{{ ansible_default_ipv4.alias }}:none"'

  - name: Enroll Clevis clients
    include_role:
      name: rhel-system-roles.nbde_client
    vars:
      nbde_client_bindings:
        - device: /dev/sdc
          encryption_password: "{{ luks_password }}"
          password_temporary: true
          slot: 2
          servers:
            - http://rhel-hetz-tang1.example.com
            - http://rhel-hetz-tang2.example.com
  • Der erste Task stellt sicher, dass das Netzwerkinterface aktiviert und mit einer IP-Adresse konfiguriert wird; dies ist notwendig, um den Tang-Server kontaktieren zu können, da in dem genutzten Netzwerk-Segment kein DHCP verfügbar ist; Solltet ihr ein Netzwerk-Segment nutzen, in dem DHCP zur Verfügung steht, kann der erste Task entfallen
  • Um das LUKS-Device für NBDE zu konfigurieren wird die LUKS-Passphrase benötigt, welche in der Variablen luks_password steckt
  • Ich empfehle die Variable luks_password mit ansible-vault vor neugierigen Blicken zu schützen
  • Durch password_temporary: true wird die LUKS-Passphrase aus dem jeweiligen Key-Slot gelöscht, nachdem das LUKS-Device für NBDE konfiguriert wurde

Achtung (I know, the warning comes after the spell): Wenn zur Laufzeit ein Fehler auftritt und der Key-Slot mit der LUKS-Passphrase bereits gelöscht wurde, die NBDE-Konfiguration jedoch nicht erfolgreich war, verliert man Zugriff auf das LUKS-Device. In meiner Labor-Umgebung bin ich das Risiko eingegangen. In der echten Welt, müsst ihr selbst entscheiden, ob ihr mehr Vorsicht walten lasst.

Fazit

Zur Erstellung des Playbooks habe ich die Informationen aus /usr/share/doc/rhel-system-roles/nbde_client/README.md und dem Kapitel 12.18. Using the nbde_client System Role for setting up multiple Clevis clients genutzt. Bis ich festgestellt habe, dass ich auch noch den Task „Configure ip address for interface during early boot“ benötige, hat es ein wenig gedauert. Nun habe ich allerdings ein Playbook, dass ich zukünftig wiederverwenden kann.

In der erstellten Konfiguration, können die LUKS-Devices nur entschlüsselt werden, wenn mindestens einer der beiden Tang-Server im Netzwerk erreichbar ist. Wird ein so gesicherter Server gestohlen und sind die Tang-Server nicht aus dem Internet erreichbar, bleiben die Daten in der verschlüsselten Partition wie gewohnt geschützt. Es ist jedoch möglich den Server neuzustarten, ohne manuell die LUKS-Passphrase an der Konsole eingeben zu müssen.

Quellen und weiterführende Links

  1. Red Hat Enterprise Linux (RHEL) System Roles {en}
  2. Ansible Documentation: Role Directory Structure {en}
  3. Red Hat Software and Download Center {en}
  4. Die Vorteile einer Red Hat Subskription
  5. RHEL System Roles: selinux
  6. RHEL System Roles: timesync
  7. RHEL System Roles: sshd
  8. RHEL System Roles: firewall
  9. RHEL System Roles: rhc
  10. RHEL System Roles: nbde_server
  •  

Linux-Gaming: Mit welcher Distribution laufen Windows-Games am besten?

Es gibt Hunderte Linux-Distributionen, aber sinnvoll für den Einstieg sind nur wenige. Wenn es dann auch noch speziell um das Spielen von Windows-Titeln unter Linux gehen soll, engt sich der Kreis noch weiter ein. ComputerBase vergleicht die gängigen (Gaming-)Distributionen Pop!_OS, Nobara Linux sowie Arch Linux im Test.

  •  

Austria goes against Router Freedom

Austria goes against Router Freedom

The Austrian Regulatory Authority for Broadcasting and Telecommunications, RTR, has decided not to regulate the network operators with regard to Router Freedom, allowing Internet Service Providers (ISPs) to impose their equipment on consumers. For RTR, routers configured in “bridge mode” is synonymous with terminal equipment freedom. The FSFE laments this decision as a missed opportunity for Net Neutrality in Austria.

The Austrian regulator RTR has decided that it should not formally determine the position of the NTP. This means that end-users cannot freely use their modems for internet connection.

In 2016, the Net Neutrality regulation established, for the first time in Europe, freedom of terminal equipment for internet connection. It means that, in theory, consumers would be able to choose and use their own routers and modems independently from those provided by the ISPs. However, the practical realisation of this right has not followed a linear process, but has been marked by several difficulties, including the 2018 reform of EU telecom law, the implementation of technical rules, and the resistance from national regulators to interfere in the activities of operators. While several countries such as Germany, Finland, the Netherlands, and Belgium have decided on full regulatory protection of Router Freedom, other EU members have followed other paths, preferring to exclude fiber networks (as in Greece and Italy) or deciding completely against freedom of terminal equipment, as in Latvia, Denmark, and now Austria.

Consumer protection falls short

In November 2023, the Austrian telecom regulator RTR published a decision on the evaluation of Router Freedom and the position of the network termination point (NTP) (DE), a demarcation of the limits of the public and private networks. The regulator has concluded not to regulate Router Freedom due to some alleged factors, including the limited usage by end-users of private routers and the enhanced operational costs for network operators. RTR has also claimed that the mere fact that Austrian providers already offer end-users the possibility to connect their own routers to the ISP’s modem in “bridge mode” would constitute freedom of terminal equipment. This, as we explain below, is a contradiction in itself. Of particular concern is RTR’s statement affirming that there is currently insufficient evidence of significant restrictions on Router Freedom for a relevant proportion of users (page 3).

A lost opportunity for Net Neutrality

RTR’s position fails to capture the notion of Router Freedom as a fundamental aspect of Net Neutrality, as freedom of terminal equipment has a profound impact on how end-users access the Internet. Router Freedom is the hardware component of Net Neutrality, and its protection should be understood not only from the market perspective, but should embrace its nature as an essential element of the Open Internet.

Formally defining the position of the NTP at Point A would officially include the modem and router within the end-user premises, and the public network would begin from the plug on the wall. That would constitute complete freedom of terminal equipment. RTR’s decision instead only guarantees that end-users can connect their routers to ISPs’ modems in “bridge mode”. Since operators can require use of their modems inside end-users’ premises, the decision cannot be considered compliant with Router Freedom.

Early on in 2021, when Austria was in the process of implementing the reform of the telecom sector, the FSFE, together with the Austrian organisation epicenter.works, urged the Austrian government to safeguard Router Freedom in the newly adopted legislation. We warned back then that if the decision on Router Freedom were to be delegated to the national regulatory agency (RTR) this could lead to outcomes against consumer rights and interests.

In 2022, we engaged with a wide range of stakeholders, including representatives from industry and policy makers, to demonstrate why Router Freedom is important for market competition, device innovation, and sustainability. At the time, we urged RTR to seize the opportunity to establish Router Freedom in Austria by defining the NTP in a position favourable to consumer interests.

In May 2023, we sent to RTR our report on the Router Freedom survey, demonstrating how ISPs still hamper consumer freedom of choice, exercise lock-in over internet equipment, and promote proprietary devices, negatively affecting consumer welfare, security, privacy, and data protection. Although more than 13% of the participants were Austrians, the regulator has not provided feedback on this.

The vast majority of participants in our survey agreed that Router Freedom is important for freedom of choice, privacy, security, and fair competition. More than a market or tech issue, Router Freedom is a policy demand.

Besides, while other member states regulators have conducted open consultations and produced comprehensive reports and detailed studies regarding Router Freedom, RTR has not provided any relevant data, nor conducted consultation procedures where civil society stakeholders were broadly involved. This lack of transparency negatively affects the monitoring on Open Internet in the country.

The FSFE laments that RTR was not able to find a balance among business, investment considerations, and consumer protection, preferring to align themselves with telecom operators instead of taking a step towards Net Neutrality and Open Internet.

Aiming at the future: there will be room for improvement

As noted by RTR, the present decision is not definitive, and the regulator will re-evaluate this framework in the future. Neither deadlines nor a time schedule were provided, though. Although we regret the long period such regulatory decisions normally require, there will be still room for improvement, and we will continue to closely monitor the situation in Austria.

Zooming out, as an example, in a study conducted on behalf of the European Commission, Router Freedom was considered one of the priorities for the proper implementation of Net Neutrality in Europe. Regulators have to take utmost account of this freedom when designing their policies for the telecommunications sector. Besides, emerging issues regarding devices, optical fiber networks, and satellite connections are still under intense debate on different levels at the EU and member states. Aspects of sustainability of the telecom sector are also being discussed. All those elements have been monitored by the FSFE, and Router Freedom will be an important element for policy making.

Router Freedom enables the right to repair and promotes fair competition. Free Software in a router can greatly extend the device’s lifespan and increase energy management. These advantages can lead to major wins in future policy making.

The Router Freedom initiative

Router Freedom is the right that customers of any ISP are able to choose and use a private modem and router instead of equipment provided by the operator. Since 2013, the Free Software Foundation Europe has been successfully engaged with Router Freedom, promoting end-users’ freedom in many European countries. Join us and learn more about the several ways to get involved. Please consider becoming a FSFE donor; you help make possible our long-term engagement and professional commitment in defending people’s rights to control technology.

Support FSFE

  •  

SFP#22: All about "Public Money? Public Code!" with Johannes Näder

SFP#22: All about "Public Money? Public Code!" with Johannes Näder

In our 22nd Software Freedom Podcast episode, we talk with Johannes Näder, Senior Policy Project Manager at the Free Software Foundation Europe (FSFE), about "Public Money? Public Code!".

The "Public Money? Public Code!" initiative advocates for public bodies to switch to Free Software instead of spending tons of money on proprietary software. The reasons for "Public Money? Public Code!", how the initiative has evolved over the years, and how the FSFE defines its role as a watchdog within the initiative are discussed with Johannes in this episode.

Johannes has been involved with Free Software since the 1990s. In November 2022, he turned his passion for Free Software into his daily bread and started working for the Free Software Foundation Europe. He is, among other responsibilities, the current coordinator of the FSFE’s "Public Money? Public Code!" initiative.

If you have not heard of this initiative yet, or if you don’t know how best to get involved, check out our new Software Freedom Podcast episode and learn all about "Public Money? Public Code!".

Show notes

If you liked this episode and want to support our continuous work for software freedom, please help us with a donation.

Support FSFE

  •  

Nextcloud und Roundcube gehen Partnerschaft ein

Kurz notiert: Nextcloud (Dateispeicher) und Roundcube (Webmail) gehen eine Partnerschaft ein. Wie heute das Nextcloud-Team in einer Blogmitteilung bekannt gab, wird Roundcube in die "Nextcloud family" aufgenommen. Dabei lässt sich die Kooperation in erster Linie strategisch verstehen, wird aber bereits kurzfristige Auswirkungen haben, da das Entwicklerteam des bekannten Webmail-Clients vergrößert werden kann.

Die wichtigste Information bei der Nachricht ist, dass Roundcube nach aktuellem Stand weiterhin als eigenes Produkt erhalten bleibt. Es handelt sich somit nicht um eine "Verschmelzung" bzw. "Übernahme" des Produkts.

Die Nachricht sendet allerdings ein positives Signal für produktiv eingesetzte Open-Source-Systeme aus: Nextcloud als ein in Unternehmensumgebungen weit verbreiter Cloud-Dienst (Dateispeicher, Kalender, etc.) ermöglicht anderen Büroprogrammen, sich weiterzuentwickeln und auf dem technisch aktuellen Stand zu bleiben. Dies meine ich dabei besonders im Sicherheitskontext. Zero-Days können immer auftreten, aber mit viel Entwicklungsressourcen kann die Wahrscheinlichkeit proaktiv gesenkt werden.

Nextcloud möchte somit auch einen attraktiven Gegenpol für klassische proprietäre Anwendungen aufbauen. Wir können also gespannt sein, was sich aus der Partnerschaft entwickelt.

  •  
❌