Monthly Archives: January 2018

Zu späte Erkenntnisse eines Ministers …

Posted on by

Vor kurzem konnte man lesen, dass sich unser geschäftsführender Außenminister (und früherer Wirtschaftsminister) auf der DLD-Konferenz geradezu ängstlich zum Thema IT und Europas Rolle zwischen den USA und China äußerte:

https://www.golem.de/news/dld-konferenz-gabriel-warnt-vor-digitalem-schlachtfeld-europa-1801-132276.html

Da wird spekuliert, ob Europa nicht zwischen den digitalen Supermächten (gemeint sind vor allem China und die USA) zerrieben werden könne – und der Telekom-Chef gibt auf derselben Tagung Europa auf dem Feld von sozialen Medien bereits verloren. Man fasst es ja nicht ….

Seit Jahren (wenn nicht Jahrzehnten) wurde und wird das Thema Digitalisierung sowie die totale Abhängigkeit Europas von amerikanischen globalen IT- und SW-Monopolisten von den diversen Regierungsparteien – vor allem aber den Volksparteien – völlig vernachlässigt. Man hat da wie üblich auf die Marktkräfte vertraut …

Und jetzt plötzlich ist alles zu spät? Bedurfte es erst Meltdown und Spectre – und die dadurch erneut in Szene gesetzte totale Abhängigkeit von außereuropäischen Chip-Herstellern – um Minister plötzlich wach zu rütteln? Lieber Ex-Wirtschaftsminister:

An Warnungen – auch von Seiten der Industrie – hat es nun wahrlich nicht gemangelt. Und dass die Marktkräfte eben nicht alles richtig regeln, sollte ein SPD-Mann wohl am besten wissen. Man hätte gerade auf diesem Feld schon längst auf eine staatlich organisierte Zusammenarbeit mit Frankreich setzen können …

Und lieber Herr Ex-Wirtschaftsminister – am Rande sei auch darauf verwiesen, dass deutsche Regierungen Know How einfach abfließen lassen:

Ich habe hier in Augsburg mal mit einem hochqualifizierten Ex-Mitarbeiter von Kuka gesprochen. Dem standen die Tränen in den Augen als der Verkauf von Kuka an chinesische Konzerne genehmigt wurde. Es wurde ja angeblich kein europäischer Investor gefunden …

http://www.finanznachrichten.de/nachrichten-2016-07/37971269-kuka-chef-rueckabwicklung-der-uebernahme-durch-midea-nicht-moeglich-016.htm

Wo blieb da der Staat als Investor? Da hatten wir mal ein weltweit führendes Technologieunternehmen mit Bezug zu Themen wie u.a. künstliche Intelligenz. Dass das Know-How ausschließlich und langfristig in Europa hätte verbleiben müssen, liegt angesichts der jetzt offenbarten ministerialen Ängste auf der Hand. Dafür hätte man damals kämpfen müssen. Wo waren Sie damals – lieber Ex-Wirtschaftsminister – als der Verkauf erfolgte und vor allem davor?

Immerhin ist im jetzigen Sondierungspapier von CDU/CSU und SPD die Rede von Giga-Netz-Ausbau, steuerlichen Erleichterungen für IT-Investitionen und einem gemeinsamen französisch-deutschen Zentrum für künstliche Intelligenz. Den erneuten Anlauf in Sachen “Deutsches E-Government” sehen wir regelmäßig seit dem Jahr 2000 in Regierungsprogrammen. Den Stand kennt jeder selber.

Alles Jahre zu spät – aber immerhin. Aber eines sollte ein Ex-Wirtschaftsminister auch verstehen:

Wenn man Google, Facebook, etc. etwas entgegensetzen will, nutzt es nichts, allein 10 – 12 Milliarden in den seit langem notwendigen Infrastrukturausbau zu investieren.

Mindestens die gleiche Summe muss in staatlich geförderte Brainware – sprich Menschen und deren IT-Kreativität investiert werden. Hierzu ist einerseits die gezielte Förderung von IT-Projekten erforderlich. Andererseits solltet ihr vielleicht auch mal darüber nachdenken, warum IT-Unternehmen zwar Ansparabschreibungen auf HW (zur Not auch Bagger) vornehmen können, nicht aber auf manchmal deutlich teurere SW und (in Grenzen) auch auf das Halten bzw. Beschaffen qualifizierten Personals?

Und dann ist da noch ein Punkt:
An unseren Schulen wird – wenn überhaupt – IT auf Basis von proprietären Microsoft-Systemen unterrichtet. Meist steht die Verwendung von MS-Office-Progammen im Fokus
der schon damit oft überforderten Lehrer.

Ehrlich gesagt:
Ich habe schon MSCE-zertifizierte Administratoren erlebt, die unfähig waren, sich in IPtables einzuarbeiten – weil zu abstrakt, komplex und ohne grafische Oberfläche. Das kommt leider nicht von ungefähr – es hat damit zu tun, dass die Betriebssysteme von MS geschlossen sind und weder Anwender noch Admin aus prinzipiellen Gründen viel davon mitbekommen sollen.

Es ist deshalb kein Wunder, wenn eine junge Generation von Indern und Chinesen, die schon allein aus Kostengründen auf Linux und offene Systeme setzt, unseren Kindern und Enkelkindern den Rang abläuft.

An den Schulen muss anhand von Systemen unterwiesen werden, die man auf jeder Detailebene studieren und ggf. auch anpassen kann; die Schüler müssen ab einem gewissen Alter in der Schule den strukturellen Aufbau von IT-Systemen lernen – und nicht den speziellen Umgang mit Google, MS Office oder Facebook. Letzteres lernen sie täglich völlig ausreichend im Umfeld ihrer Freunde.

Die Schule muss dagegen gezielt zeigen, wie IT-System prinzipiell funktionieren. Sie muss zeigen, was IT-Sicherheit bedeutet, wie und warum Angriffe erfolgen und wie man sich verteidigt (Harry Potter lässt grüßen …). Es ist vor allem SW-Entwicklung zu lehren – für Anwendungen und Betriebssysteme gleichermaßen. Das geht am besten und tiefsten mit Open Source und Linux.

“IT und SW-Entwicklung” hätte ab einer hinreichenden Altersstufe ein Pflichtfach an den Schulen werden müssen. Am Gymnasium in anspruchsvoller Form und auf der gleichen Stufe wie Mathematik.

Aber dafür müsste die Politik erstmal für eine hinreichende Ausbildung der Lehrkräfte sorgen …. dazu lese ich aber nichts im aktuellen Sondierungspapier.

Für all das ist es keineswegs zu spät und Europa ist keineswegs verloren – es fehlte und fehlt wie immer der politische Wille. Es gibt in Deutschland und Frankreich genügend junge Leute, die gerne eine europäische Suchmaschine auf Basis künstlicher Intelligenz aufbauen möchten und dies in Form eines staatlich finanzierten Open Source Projektes auch in relativ kurzer Zeit schaffen könnten. Aber wird der Ehrgeiz geeigneter Leute überhaupt angestachelt, wird er auch finanziell gefördert? Statt dessen mussten wir vor ein paar Jahren erleben, wie genau ein Europäischer Entwickler für einen Hungerlohn und mit viel Freizeit die Verantwortung für bestimmte lebenswichtige Verschlüsselungsverfahren übernahm.

Bzgl. der Ängste unseres Außenministers und früheren Wirtschaftsministers, Europa werde zum “tatenlosen Zuschauer” im globalen IT-Wettbewerb, ist deshalb in aller erster Linie an seine – aber nicht nur seine – Verantwortlichkeit für die eingetretene Fehlentwicklung zu verweisen. Einen Kommentar zum Telekom-Chef erspare ich mir.

Eclipse, Git, SSH2, Einträge in der ~/.ssh/config, Bug bei Ciphers mit Domain-Angabe

Posted on by

Wenn man mit Eclipse (Oxygen2, Neon3) Git-Repositories auf Remote-Servern versorgen will, macht man das natürlich über SSH. Ich hatte in einem früheren Blogbeitrag schon mal auf einen Artikel

https://stribika.github.io/2015/01/04/secure-secure-shell.html

hingewiesen, in dem verschiedene Härtungsmaßnahmen aufgezeigt werden. Natürlich verwendet man dabei auch eine Public Key Authentication, wobei der öffentliche RSA-Schlüssel in hinreichender Länge (> 2048 Bit) auf dem Server implementiert wird. Er ist dort wie üblich beim entsprechenden externen User in die Datei “~/.ssh/authorized_keys” einzukopieren.

Unter Eclipse ist dann in jedem Fall noch Folgendes erforderlich: Unter dem Menüpunkt

Window >> Preferences >> General >> Network Connections >> SSH2

trägt man im Fensterchen zum “General”-Tab das Verzeichnis ein, in dem man seine privaten Keys aufbewahrt – und listet zudem die von Eclipse zu verwendenden Keys für die verschiedenen Git- bzw. SSH-Server auf. Das sieht dann etwa so aus:

Ohne diese Einträge funktioniert eine key-basierte SSH-Authentifizierung unter Eclipse nicht. Das gilt nicht nur für Git sondern auch für andere Arten von SSH-Verbindungen etwa unter den “Remote Systems”-Modulen, für SFTP- und für SSH-Shell-Zugriffe. Die korrespondierende Git-Push-Konfiguration für SSH kann dann etwa wie folgt aussehen:

“55511” sei dabei der gewählte SSH-Port, unter dem der Server erreichbar sein soll. Der Leser muss an dieser Stelle natürlich die für ihn geletenden Einträge vorzunehmen.

Auf einem typischen OpenSSH-Server unter Linux lassen sich die Vorgaben des oben genannten Artikels zu Einträgen in der SSH-Konfigurationsdatei “/etc/ssh/sshd_config” problemlos umsetzen. Etwas anders sieht es aber auf dem OpenSSH-Client-System aus. Dort würde man gerne zumindest folgende empfohlenen Härtungseinträge in der Datei “~/.ssh/config” unterbringen:

Korrekte Einträge in der OpenSSH “~/.ssh/config”-Datei, die aber unter Eclipse nicht funktionieren:

  
Host myserv.myhosteddomain.net
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr,aes256-cbc

Nutzt man die Zeile für “Ciphers” in der angegebenen Form, so funktioniert dies zwar für eine native SSH-Verbindung von der Kommandozeile eines Terminalfensters aus; Eclipse reagiert jedoch traurigerweise mit einer Exception “….. java.lang.NullPointerException“.

Ursache dafür ist eine falsche Behandlung von Domain-Angaben in den Cipher-Verfahren durch die zuständigen Eclipse-Module. Interessanterweise funktionieren aber die Domain-Angaben hinter den KEX-Verfahren!

Folgende Variante funktioniert mit den SSH-Modulen von Eclipse:

Funktionierende SSH-config-Datei für Eclipse: 

  
Host myserv.myhosteddomain.net
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
# The following does not 
work in Eclipse 
# Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,aes192-cbc
# This works, however: 
Ciphers aes256-cbc,aes256-ctr

Es ist irgendwie traurig, dass Eclipse sich in puncto SSH und Cipher-Angaben fehlerhaft verhält; denn man steht nun vor einer (geringfügigen) Einschränkung der Sicherheit. 256Bit basierte AES-Verfahren sollten im Moment allerdings noch ausreichen.

Ich hoffe, das hilft dem einen oder anderen, der auf die oben genannte Exception stößt. Zu hoffen bleibt auch, dass die Eclipse-Entwickler solche Bugs baldmöglichst beseitigen.

Update zu Opensuse 42.3 – kleine Probleme mit nvidia und libvirt/kvm

Posted on by

Das aktuelle Drama um Meltdown und Spectre verlangt auch von Linux-Usern starke Nerven. Bei Opensuse steht zudem das Auslaufen des Support-Zeitraums für Opensuse Leap 42.2 an. Es lohnt sich also, hier auch noch ein Upgrade betroffener Systeme auf Opensuse Leap 42.3 vorzunehmen. In der Reihenfolge

  1. Anwendung aktueller Kernel-Patches (man suche z.B. unter YaST > Software Management” mit dem Begriff “kernel” nach entsprechenden RPM-Paketen und deren Updates) sowie von Intel- bzw. AMD-Microcode-Patches (Pakete “ucode-intel”, “ucode-intel-blob” bzw. “ucode-amd”) unter Opensuse Leap 42.2.
  2. Bei Einsatz von qemu, kvm, libvirt: Update entsprechender Pakete unter Leap 42.2.
  3. Upgrade auf Opensuse Leap 42.3 (z.B. gem. der Anleitung unter https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/)
  4. Soweit dann noch nötig: Anwendung aktueller Kernel-Patches, von Intel- bzw. AMD-Microcode-Patches und Updates von qemu/kvm/libvirt-Paketen unter Leap 42.3
  5. [Für Mutige (und Sicherheitsbewusste): Upgrade auf ein aktuelles Kernel-Paket zur Version 4.14 aus dem “kernel”-Repository “http://download.opensuse.org/repositories/Kernel:/stable/standard/”.]

Das klappt eigentlich ganz gut. Bei zwei Systemen bin ich dabei im Zuge des Standard-Upgrades aber auf zwei kleinere Problemchen mit “kvm/qemu” und dem proprietären “Nvidia”-Treiber gestoßen.

Nvidia-Problem => Deinstallation des Pakets “drm-kmp-default”

Im Zuge der Installation des proprietären Nvidia-Treibers (z.B. über das Installations-File “NVIDIA-Linux-x86_64-384.98.run”), den man sich von der Nvidia-Web-Site laden kann, klappt zwar die Kompilation des Treibers, nicht aber das Laden des Moduls “nvidia-drm.ko”. Es kommt eine entsprechende Meldung zum Fehlschlag der Nvidia-Installation. Ursache ist ein Paket “drm-kmp-default”, das aus mir nicht nachvollziehbaren Gründen installiert wird, aber in seiner Version nicht zum aktualisierten Default-Kernel (z.Z. 4.4.104-39.1) des Leap 42.3-Systems passt. Hier hilft es, das Paket “drm-kmp-default” zu deinstallieren. Das “drm”-Modul wird dennoch geladen und vom Modul “drm-nvidia” auch korrekt verwendet.

qemu/kvm-Problem: Korrekten Eintrag zu “namespaces” in der Datei qemu.conf vornehmen

Nach dem Upgrade auf Leap 42.3 und Aktualisierung aller Virtualisierungspakete ließen sich leider keine KVM-Gastsysteme mehr starten. Ich erhielt ganz unabhängig von der Art des Gastes und dessen Betriebssystem eine Meldung der Art:

Error starting domain: internal error: child reported: Kernel does not provide mount namespace: Permission denied

Ursache ist ein fehlender Eintrag

#namespaces = [ “mount” ]
namespaces = []

(bzw. ein unwirksamer Default-Eintrag (namespaces = [ “mount” ])) in der Datei “/etc/libvirt/qemu.conf”.
Ich tippe darauf, dass dieses Problem durch Rückportierungen bestimmter neuer Kernel-Features auf die relativ veraltete 4.4-Version von Leap 42.3 verursacht wurde. Im Standard-4.4-Kernel brauchte man den Eintrag in der vorliegenden Form nämlich nicht. Auf die Lösung dieses Problems bin ich nicht selbst gekommen; s. zu diesem Thema die unten angegebenen Links.

Viel Spaß weiterhin mit Opensuse – trotz des aktuellen Security Super-GAUs. Das beste Gegenmittel gegen Spectre ist – neben laufenden System-Updates – maximale Vorsicht beim Öffnen jeglicher externer Quellen, das Verifizieren von Update-Quellen für System- und Anwendungsdateien und das Verifizieren von Web-Sites im Internet über https-Verbindungen, das Kontrollieren der Hash-Summen für alle Updates sowie der Einsatz von “Noscript
“-Plugins in euren Browsern. Soweit ich das verstehe, erfordert ein Ausnutzen der Spectre-Schwachstelle in den aktuellen Prozessoren das Ausführen malignen Codes. Ein Einfangen von Schadcode muss man vermeiden – diese Binsenwahrheit gilt und erfordert nunmehr weiter erhöhte Wachsamkeit – im besonderen beim Browsen im Internet.

Vielleicht denken einige Unternehmen und Webseiten-Programmierer nun auch wieder ein wenig mehr darüber nach, ob und wann Javascript für den Betrieb einer öffentlichen Web-Seite überhaupt erforderlich ist. Auf vielen Seiten erfolgt der Einsatz oftmals weniger aus funktionalen Gründen als vielmehr deshalb, damit das Nutzerverhalten aus kommerziellen Gründen getrackt werden kann …..

Links

https://forums.opensuse.org/showthread.php/527697-Can-t-load-nvidia-drm-ko-after-update
https://forums.opensuse.org/showthread.php/527394-KVM-guest-will-not-start-with-latest-version-of-kernel
https://www.redhat.com/archives/libvirt-users/2017-March/msg00033.html
https://www.redhat.com/archives/libvirt-users/2017-March/msg00035.html

Fun with veth-devices, Linux bridges and VLANs in unnamed Linux network namespaces – VIII

Posted on by

In the last post of this series

Fun with veth-devices, Linux bridges and VLANs in unnamed Linux network namespaces – VII [Theoretical considerations regarding the connection of a network namespace or container to two separated VLANs]

we discussed two different approaches to connect a network namespace (or container) “netns9” to two (or more) separated VLANs. Such a network namespace could e.g. represent an administrative system (for example in form of a LXC container) for both VLANs. It has its own connection to the virtual Linux bridge which technically defines the VLANs by special port configurations. See the picture below, where we represented a VLAN1 by a member network namespace netns1 and a VLAN2 by a member netns4:

The solution on the left side is based on a bridge in an intermediate network namespace and packet tagging up into the namespace for the VLANs’ common member system netns9. The approach on the right side of the graphics uses a bridge, too, but without packet tagging along the connection to the common VLAN member system. In our analysis in the last post we assumed that we would have to compensate for this indifference by special PVID/VID settings.

The previous articles of this series already introduced general Linux commands for network namespace creation and the setup of VLANs via Linux bridge configurations. See e.g.: Fun with … – IV [Virtual VLANs for network namespaces (or containers) and rules for VLAN tagging at Linux bridge ports]. We shall use these methods in the present and a coming post to test configurations for a common member of two VLANs. We want to find out whether the theoretically derived measures regarding route definitions in netns9 and special PVID/VID-settings at the bridge work as expected. A test of packet filtering at bridge ports which we regarded as important for security is, however, postponed to later posts.

Extension of our test environment

First, we extend our previous test scenario by yet another network namespace “netns9“.

Our 2 VLANs in the test environment are graphically distinguished by “green” and “pink” tags (corresponding to different VLAN ID numbers). netns9 must be able to communicate with systems in both VLANs. netns9 shall, however, not become a packet forwarder between the VLANs; the VLANs shall remain separated despite the fact that they have a common member. We expect, that a clear separation of communication paths to the VLANs requires a distinction between network targets already inside netns9.

Bridge based solutions with packet tagging and veth sub-interfaces

There are two rather equivalent solutions for the connection of netns9 to brx in netns3; see the schematic graphics below:

Both solutions are based on veth sub-interfaces inside netns9. Thus, both VLAN connections are properly terminated in netns9. The approach depicted on the right side of the graphics uses a pure trunk port at the bridge; but also this solutions makes use of packet tagging between brx and netns9.

Note that we do not need to used tagged packets along the connections from bridge brx to netns1, netns2, netns4, netns5. The VLANs are established by the PVID/VID settings at the bridge ports and forwarding rules inside a VLAN aware bridge. Note also that our test environment contains an additional bridge bry and additional network namespaces.

We first concentrate on the solution on the left side with veth sub-interfaces at the bridge. It is easy to switch to a trunk port afterwards.

The required commands for the setup of the test environment are given below; you may scroll and copy the commands to the prompt of a terminal window for a root shell: 

unshare --net --uts /bin/bash &
export pid_netns1=$!
unshare --net --uts /bin/bash &
export pid_netns2=$!
unshare --net --uts /bin/bash &
export pid_netns3=$!
unshare --net --uts /bin/bash &
export pid_netns4=$!
unshare --net --uts /bin/bash &
export pid_netns5=$!
unshare --net --uts /bin/bash &
export pid_netns6=$!
unshare --net --uts /bin/bash &
export pid_netns7=$!
unshare --net --uts /bin/bash &
export pid_netns8=$!
unshare --net --uts /bin/bash &
export pid_netns9=$!

# assign different hostnames  
nsenter -t $pid_netns1 -u hostname netns1
nsenter -t $pid_netns2 -u hostname netns2
nsenter -t $pid_netns3 -u hostname netns3
nsenter -t $pid_netns4 -u hostname netns4
nsenter -t $pid_netns5 -u hostname netns5
nsenter -t $pid_netns6 -u hostname netns6
nsenter -t $pid_netns7 -u hostname netns7
nsenter -t $pid_netns8 -u hostname netns8
nsenter -t $pid_netns9 -u hostname netns9
     
# set up veth devices in netns1 to netns4 and in netns9 with connections to netns3  
ip link add veth11 netns $pid_netns1 type veth peer name veth13 netns $pid_netns3
ip link add veth22 netns $pid_netns2 type veth peer name veth23 netns $pid_netns3
ip link add veth44 netns $pid_netns4 type veth peer name veth43 netns $pid_netns3
ip link add veth55 netns $pid_netns5 type veth peer name veth53 netns $pid_netns3
ip link add veth99 netns $pid_netns9 type veth peer name veth93 netns $pid_netns3

# set up veth devices in netns6 and netns7 with connection to netns8   
ip link add veth66 netns $pid_netns6 type veth peer name veth68 netns $pid_netns8
ip link add veth77 netns $pid_netns7 type veth peer name veth78 netns $pid_netns8

# Assign IP addresses and set the devices up 
nsenter -t $pid_netns1 -u -n /bin/bash
ip addr add 192.168.5.1/24 brd 192.168.5.255 dev veth11
ip link set veth11 up
ip link set lo up
exit
nsenter -t $pid_netns2 -u -n /bin/bash
ip addr add 192.168.5.2/24 brd 192.168.5.255 dev veth22
ip link set veth22 up
ip link set lo up
exit
nsenter -t $pid_netns4 -u -n /bin/bash
ip addr add 192.168.5.4/24 brd 192.168.5.255 dev veth44
ip link set veth44 up
ip link set lo up
exit
nsenter -t $pid_netns5 -u -n /bin/bash
ip addr add 192.168.5.5/24 brd 192.168.5.255 dev veth55
ip link set veth55 up
ip link set lo up
exit
nsenter -t $pid_netns6 -u -n /bin/bash
ip addr add 192.168.5.6/24 brd 192.168.5.255 dev veth66
ip link set veth66 up
ip link set lo up
exit
nsenter -t $pid_netns7 -u -n /bin/bash
ip addr add 192.168.5.7/24 brd 192.168.5.255 dev veth77
ip link set veth77 up
ip link set lo up
exit
nsenter -t $pid_netns9 -u -n /bin/bash
ip addr add 192.
168.5.9/24 brd 192.168.5.255 dev veth99
ip link set veth99 up
ip link set lo up
exit

# set up bridge brx and its ports 
nsenter -t $pid_netns3 -u -n /bin/bash
brctl addbr brx  
ip link set brx up
ip link set veth13 up
ip link set veth23 up
ip link set veth43 up
ip link set veth53 up
brctl addif brx veth13
brctl addif brx veth23
brctl addif brx veth43
brctl addif brx veth53
exit

# set up bridge bry and its ports 
nsenter -t $pid_netns8 -u -n /bin/bash
brctl addbr bry  
ip link set bry up
ip link set veth68 up
ip link set veth78 up
brctl addif bry veth68
brctl addif bry veth78
exit

# set up 2 VLANs on each bridge 
nsenter -t $pid_netns3 -u -n /bin/bash
ip link set dev brx type bridge vlan_filtering 1
bridge vlan add vid 10 pvid untagged dev veth13
bridge vlan add vid 10 pvid untagged dev veth23
bridge vlan add vid 20 pvid untagged dev veth43
bridge vlan add vid 20 pvid untagged dev veth53
bridge vlan del vid 1 dev brx self
bridge vlan del vid 1 dev veth13
bridge vlan del vid 1 dev veth23
bridge vlan del vid 1 dev veth43
bridge vlan del vid 1 dev veth53
bridge vlan show
exit
nsenter -t $pid_netns8 -u -n /bin/bash
ip link set dev bry type bridge vlan_filtering 1
bridge vlan add vid 10 pvid untagged dev veth68
bridge vlan add vid 20 pvid untagged dev veth78
bridge vlan del vid 1 dev bry self
bridge vlan del vid 1 dev veth68
bridge vlan del vid 1 dev veth78
bridge vlan show
exit

# Create a veth device to connect the two bridges 
ip link add vethx netns $pid_netns3 type veth peer name vethy netns $pid_netns8
nsenter -t $pid_netns3 -u -n /bin/bash
ip link add link vethx name vethx.50 type vlan id 50
ip link add link vethx name vethx.60 type vlan id 60
brctl addif brx vethx.50
brctl addif brx vethx.60
ip link set vethx up
ip link set vethx.50 up
ip link set vethx.60 up
bridge vlan add vid 10 pvid untagged dev vethx.50
bridge vlan add vid 20 pvid untagged dev vethx.60
bridge vlan del vid 1 dev vethx.50
bridge vlan del vid 1 dev vethx.60
bridge vlan show
exit

nsenter -t $pid_netns8 -u -n /bin/bash
ip link add link vethy name vethy.50 type vlan id 50
ip link add link vethy name vethy.60 type vlan id 60
brctl addif bry vethy.50
brctl addif bry vethy.60
ip link set vethy up
ip link set vethy.50 up
ip link set vethy.60 up
bridge vlan add vid 10 pvid untagged dev vethy.50
bridge vlan add vid 20 pvid untagged dev vethy.60
bridge vlan del vid 1 dev vethy.50
bridge vlan del vid 1 dev vethy.60
bridge vlan show
exit

# Add subinterfaces in netns9
nsenter -t $pid_netns9 -u -n /bin/bash
ip link add link veth99 name veth99.10 type vlan id 10
ip link add link veth99 name veth99.20 type vlan id 20
ip link set veth99 up
ip link set veth99.10 up
ip link set veth99.20 up
exit

# Add subinterfaces in netns3
nsenter -t $pid_netns3 -u -n /bin/bash
ip link add link veth93 name veth93.10 type vlan id 10
ip link add link veth93 name veth93.20 type vlan id 20
ip link set veth93 up
ip link set veth93.10 up
ip link set veth93.20 up
brctl addif brx veth93.10
brctl addif brx veth93.20
bridge vlan add vid 10 pvid untagged dev veth93.10
bridge vlan add vid 20 pvid untagged dev veth93.20
bridge vlan del vid 1 dev veth93.10
bridge vlan del vid 1 dev veth93.20
exit

We just have to extend the command list of the experiment conducted already in the second to last post by some more lines which account for the setup of netns9 and its connection to the bridge “brx” in netns3.

Now, we open a separate terminal, which inherits the defined environment variables (e.g. on KDE by “konsole &>/dev/null &”), and try a ping from netns9 to netns7: 

mytux:~ # nsenter -t $pid_netns9 
-u -n /bin/bash
netns9:~ # ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
^C
--- 192.168.5.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1008ms

netns9:~ # ping 192.168.5.7
PING 192.168.5.7 (192.168.5.7) 56(84) bytes of data.
^C
--- 192.168.5.7 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1006ms

netns9:~ #

Obviously, the pings failed! The reason is that we forgot to set routes in netns9! Such routes are, however, vital for the transport of e.g. ICMP answering and request packets from netns9 to members of the two VLANs. See the last post for details. We add the rules for the required routes: 

#Set routes in netns9 
nsenter -t $pid_netns9 -u -n /bin/bash
route add 192.168.5.1 veth99.10                                                     
route add 192.168.5.2 veth99.10                                                    
route add 192.168.5.4 veth99.20
route add 192.168.5.5 veth99.20                                                    
route add 192.168.5.6 veth99.10
route add 192.168.5.7 veth99.20
exit

By these routes we, obviously, distinguish different paths: Packets heading for e.g. netns1 and netns2 go through a different interface than packets sent e.g. to netns4 and netns5. Now, again, in our second terminal window: 

mytux:~ # nsenter -t $pid_netns9 -u -n /bin/bash 
netns9:~ # ping 192.168.5.1 -c2
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
64 bytes from 192.168.5.1: icmp_seq=1 ttl=64 time=0.067 ms
64 bytes from 192.168.5.1: icmp_seq=2 ttl=64 time=0.083 ms

--- 192.168.5.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.067/0.075/0.083/0.008 ms
netns9:~ # ping 192.168.5.7 -c2
PING 192.168.5.7 (192.168.5.7) 56(84) bytes of data.
64 bytes from 192.168.5.7: icmp_seq=1 ttl=64 time=0.079 ms
64 bytes from 192.168.5.7: icmp_seq=2 ttl=64 time=0.078 ms

--- 192.168.5.7 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.078/0.078/0.079/0.008 ms
netns9:~ # ping 192.168.5.4 -c2
PING 192.168.5.4 (192.168.5.4) 56(84) bytes of data.
64 bytes from 192.168.5.4: icmp_seq=1 ttl=64 time=0.151 ms
64 bytes from 192.168.5.4: icmp_seq=2 ttl=64 time=0.076 ms

--- 192.168.5.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.076/0.113/0.151/0.038 ms

Thus, we have confirmed our conclusion from the last article that we need route definitions in a common member of two VLANs if and when we terminate tagged connection lines by veth sub-interfaces inside such a network namespace or container.

But are our VLANs still isolated from each other?
We open another terminal and try pinging from netns1 to netns4, netns7 and netns2: 

mytux:~ # nsenter -t $pid_netns1 -u -n /bin/bash
netns1:~ # ping 192.168.5.4
PING 192.168.5.4 (192.168.5.4) 56(84) bytes of data.
^C
--- 192.168.5.4 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms

netns1:~ # ping 192.168.5.7
PING 192.168.5.7 (192.168.5.7) 56(84) bytes of data.
^C
--- 192.168.5.7 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1007ms

netns1:~ # ping 192.168.5.2
PING 192.168.5.2 (192.168.5.2) 56(84) bytes of data.
64 bytes from 192.168.5.2: icmp_seq=1 ttl=64 time=0.195 ms
64 bytes from 192.168.5.2: icmp_seq=2 ttl=64 time=0.102 ms
^C
--- 192.168.5.
2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.102/0.148/0.195/0.048 ms
netns1:~ #

And in reverse direction :

mytux:~ # nsenter -t $pid_netns5 -u -n /bin/bash                                               
netns5:~ # ping 192.168.5.4
PING 192.168.5.4 (192.168.5.4) 56(84) bytes of data.                                           
64 bytes from 192.168.5.4: icmp_seq=1 ttl=64 time=0.209 ms                                     
64 bytes from 192.168.5.4: icmp_seq=2 ttl=64 time=0.071 ms                                     
^C                                                                                             
--- 192.168.5.4 ping statistics ---                                                            
2 packets transmitted, 2 received, 0% packet loss, time 999ms                                  
rtt min/avg/max/mdev = 0.071/0.140/0.209/0.069 ms                                              
netns5:~ # ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.                                           
^C                                                                                             
--- 192.168.5.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1008ms

netns5:~ #

Good! As expected!

Forwarding between two VLANs?

We have stressed in the last post that setting routes should clearly be distinguished from “forwarding” if we want to keep our VLANs separated:

We have NOT enabled forwarding in netns9. If we had done so we would have lost the separation of the VLANs and opened a direct communication line between the VLANs.

Let us – just for fun – test the effect of forwarding in netns9: 

netns9:~ # echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
netns9:~ #

But still:

netns5:~ # ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
^C
--- 192.168.5.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

Enabling forwarding in netns9 alone is obviously not enough to enable a packet flow in both directions! A little thinking , however, shows:

If we e.g. want ARP resolution and pinging from netns5 to netns1 to work via netns9 we must establish further routes both in netns1 and netns5. Reason: Both network namespaces must be informed that netns9 now works as a gateway for both request and answering packets: 

netns1:~ # route add 192.168.5.5 gw 192.168.5.9

netns5:~ # route add 192.168.5.1 gw 192.168.5.9

Eventually: 

netns5:~ # ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
64 bytes from 192.168.5.1: icmp_seq=1 ttl=63 time=0.186 ms
64 bytes from 192.168.5.1: icmp_seq=2 ttl=63 time=0.134 ms
^C
--- 192.168.5.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.134/0.160/0.186/0.026 ms
netns5:~ #

So, yes, forwarding outside the bridge builds a connection between otherwise separated VLANs. In connection with a packet filter this could be used to allow some hosts of a VLAN1 to reach e.g. some servers in a VLAN2. But this is not the topic of this post. So, do not forget to disable the forwarding in netns9 again for further experiments: 

netns9:~ # echo 0 > /proc/sys/net/ipv4/conf/all/forwarding
netns9:~ #

Bridge based solutions with packet tagging and a trunk port at the Linux bridge

The following commands replace the sub-interface ports veth93.10 and veth93.20 at the bridge by a single trunk port:

# Change veth93 to trunk like interface in brx 
nsenter -t $pid_netns3 -u -n /bin/bash
brctl delif brx veth93.10
brctl delif brx veth93.20
ip link del dev veth93.10
ip link del dev veth93.20
brctl addif brx veth93
bridge vlan add vid 10 tagged dev veth93
bridge vlan add vid 20 tagged dev veth93
bridge vlan del vid 1 dev veth93
bridge vlan show
exit

Such a solution works equally well:

netns9:~ # ping 192.168.5.4 -c2
PING 192.168.5.4 (192.168.5.4) 56(84) bytes of data.
64 bytes from 192.168.5.4: icmp_seq=1 ttl=64 time=0.145 ms
64 bytes from 192.168.5.4: icmp_seq=2 ttl=64 time=0.094 ms

--- 192.168.5.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.094/0.119/0.145/0.027 ms
netns9:~ # ping 192.168.5.6 -c2
PING 192.168.5.6 (192.168.5.6) 56(84) bytes of data.
64 bytes from 192.168.5.6: icmp_seq=1 ttl=64 time=0.177 ms
64 bytes from 192.168.5.6: icmp_seq=2 ttl=64 time=0.084 ms

--- 192.168.5.6 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.084/0.130/0.177/0.047 ms
netns9:~ #

Summary and outlook

It is easy to make a network namespace or container a common member of two separate VLANs realized by a Linux bridge. You have to terminate virtual veth connections, which transport tagged packets from both VLANs, properly inside the common target namespace by sub-interfaces. As long as we do not enable forwarding in the common namespace the VLANs remain separated. But routes need to be defined to direct packets from the common member to the right VLAN.

In the next post we look at commands to realize a connection of bridge based VLANs to a common network namespace with untagged packets. Such solutions are interesting for connecting multiple virtual VLANs to routers to external networks.

 

An ihren Taten sollt ihr sie erkennen … ein paar Gedanken zum Jahreswechsel

Posted on by

Es war ein interessantes Jahr 2017 – auch aus der Perspektive eines 59-Jährigen, der die Entwicklung unserer Parteienlandschaft mit zunehmender Besorgnis verfolgt. Liebe Freunde, sicher werdet ihr euch fragen, warum ich darüber in einem IT-lastigen Blog schreibe. Aber vor kurzem wurde ich von einem IT-affinen Freund nicht ohne Hintergedanken gefragt, was denn meine größte Freude im vergangenen Jahr gewesen sei und was meine größte Enttäuschung.

Der erste Teil der Antwort war einfach und ziemlich IT-frei:

Eine große Freude war eine syrische Flüchtlingsfamilie, die meine Frau und ich ein wenig betreuen. Beide junge Eltern haben im Herbst die B1-Prüfung bestanden – obwohl sie im März trotz vorangegangenen staatlich finanzierten Sprachunterrichts so gut wie kein Deutsch konnten. Danach wird und will einer der beiden trotz 15-jähriger Praxis als Elektriker in Syrien einen formellen Ausbildungsgang in dieser Berufssparte antreten. Integration ist möglich – aber sie bedarf des Engagements und der Geduld deutscher Bürger, die mit unseren neuen Mitbürgern regelmäßig sprechen, sie anspornen und motivieren. Man wird dafür mit neuen Freundschaften und vielfältigen Einblicken in andere Kulturen reichlich belohnt. Und vielleicht erhält unser Land dadurch in einiger Zeit einen Nachschub an den viel beschworenen Fachkräften, an denen es angeblich schon jetzt so mangelt.

Bzgl. der größten Enttäuschung würden einige meiner Bekannten nun vielleicht auf den Abschied der Stadt München von Linux tippen. Falsch. Das war aus meiner Sicht zu erwarten – u.a. wegen grundlegender fachlicher/technischer Defizite bei der Schwerpunktsetzung für den Linux-Einsatz. Im Übrigen bin ich der Meinung, dass die Entscheidung viel mehr über den stetigen Verfall der SPD (nicht nur in München) aussagt als über Linux. Womit wir fast schon bei der eigentlichen Enttäuschung wären – nämlich dem Verhalten der SPD bei der Behandlung der Gesetze zur Quellen-TKÜ und zur Möglichkeit der Online-Durchsuchung von IT-Systemen aller Art durch Sicherheitsbehörden.

Zwischen den Ansprüchen an den Staat, die Sicherheit der Staatsbürger zu gewährleisten und auf der anderen Seite die Privatsphäre und informationelle Selbstbestimmung des Einzelnen als Grundpfeiler einer freiheitlichen Demokratie zu schützen, besteht immer ein Spannungsverhältnis. In der Praxis wird es dabei auch zu Widersprüchen kommen, die der Gesetzgeber (mühsam) und unter sorgfältiger Abwägung aller absehbaren Folgen auflösen muss. Dass dem Aspekt der Sicherheit dabei ein großes Gewicht zuzumessen ist, ist klar. Sicher kann man es dabei auch nicht allen recht machen.

Aber: Gesetze, die Eingriffe in fundamentale Freiheit des einzelnen Bürgers auf Dauer regeln sollen, erfordern in einer Demokratie eben auch und unbedingt einen vorhergehenden öffentlichen Diskurs. Dabei müssen möglich Folgen aufgezeigt werden, die Wirksamkeit und Verhältnismäßigkeit der Gesetze ist zu hinterfragen, der Wille der Bevölkerung ist zu erkunden, die Verträglichkeit mit Verfassungsprinzipien sind zwingend auszuloten – auch unter Berücksichtigung der Möglichkeit, dass einmal Un-Demokraten Macht erhalten könnten. Für meine Generation ist diese Feststellung eine Selbstverständlichkeit. Wir möchten nämlich nicht, dass Willy Brandts Leitsatz “Wir wollen mehr Demokratie wagen” ohne hinreichende Information und Beteiligung der Bürger durch den Satz “Wir wollen mehr staatliche Überwachung praktizieren” ersetzt wird – selbst, wenn die Motive für ausgedehnte Überwachungsmöglichkeiten gut und richtig sein mögen.

In einer repräsentativen Demokratie erwarte ich von einer staatstragenden Parteien wie der SPD, dass sie einen solchen öffentlichen Diskurs intensiv führt und mit hinreichenden Informationen für den Bürger versieht. Dabei ist der Rat von Fachleuten einzuholen, wenn es um Technologiefolgenabschätzungen geht. Dass die Folgen von Staatstrojanern auf ganz verschiedenen Ebenen betrachtet werden müssen, liegt wohl auf der Hand.
Die Gesetze betreffen schließlich auf Dauer Rechte und Freiheiten eines jeden Bürgers in einer digitalen Informationsgesellschaft. Gerade Politiker erleben doch, wie sehr sich unser aller Privatleben in digitalen Abdrücken im Internet, in sozialen Medien und kaum geschützten Cloud-Systemen manifestiert – zum Guten wie zum Schlechten.

Genau hier aber hat die SPD 2017 völlig versagt: Kurz vor der Sommerpause wurden die TKÜ-Gesetzentwürfe ohne größere Debatte im Parlament von der SPD mitbeschlossen. Über das Verhalten der SPD in dieser Angelegenheit und über die Folgen der neuen Gesetze ist in Zeitungen und Internetforen bereits viel Kluges geschrieben worden. Ich möchte das nicht wiederholen.

Persönlich erhielt ich folgende Antwort des SPD-Vorstandes auf eine Mail, in der ich mich beim damaligen Kanzlerkandidaten darüber beklagte, dass die SPD das Thema trotz massiver potentieller Folgen (Wannacry hatten wir zu dem Zeitpunkt gerade hinter uns) nicht hinreichend in einen öffentlichen Diskurs eingebracht habe; ich zitiere den SPD-Vorstand:

“Mit den beschlossenen Gesetzen soll der Tatsache Rechnung getragen werden, dass Verbrecher zunehmend über verschlüsselte Messenger-Dienste miteinander
kommunizieren. Für die Zulassung sollen ebenso strenge Voraussetzungen gelten wie für die schon jetzt unter Richtervorbehalt erlaubte akustische
Wohnraumüberwachung. Die weite Verbreitung informationstechnischer Systeme führt dazu, dass sie auch eine wichtige Rolle spielen, wenn es um die
Verhinderung und um die Aufklärung von Straftaten geht. Bei der Gefahrenabwehr wird den Polizeibehörden schon seit längerer Zeit ausdrücklich die Möglichkeit eingeräumt, schwere Gefahren durch den Einsatz von Überwachungstechniken abzuwehren. Im Bereich der Strafverfolgung ist umstritten, inwieweit die Überwachung insbesondere verschlüsselter Kommunikation über das Internet zulässig ist. Die Möglichkeit eines verdeckten Eingriffs in informationstechnische Systeme zum Zweck ihrer Durchsuchung besteht bislang für die Strafverfolgungsbehörden nicht. Der SPD-Obmann im Bundestags-Rechtsausschuss Johannes Fechner sagte, wenn Straftäter die Möglichkeiten der Digitalisierung nutzten, sollten auch die Polizeibehörden diese neuen technischen Wege gehen können, um Verbrechen aufzuklären.”

Dieser Text sagt leider Einiges darüber aus, wie einfach das digitale Weltbild der SPD inzwischen geworden ist. Der Text offenbart zunächst eine gewisse Hilflosigkeit gegenüber technischen Entwicklungen. Dann wird der Anspruch formuliert, auch IT-Systeme zur Verhinderung von Straftaten unter Richtervorbehalt einsetzen zu dürfen. Geschenkt …

Bei einer staatlichen Endgeräteüberwachung geht es aber um die potentielle Breite und Tiefe des technischen Eingriffs gegenüber der Bevölkerung, es geht ferner um die fachliche und technische Kontrolle des Eingriffs gegenüber jeder betroffenen Einzelperson; es geht um das Prinzip der Unschuldsvermutung sowie auch die nachweisbare Revision und Beendigung einer Überwachungsmaßnahme bei Ausbleiben von Hinweisen auf ein Verbrechen. Es geht darum, dass durch einen Endgerätezugriff nicht nur auf Kommunikationsdaten zugegriffen werden kann: Wie wird eigentlich praktisch verhindert, dass einmal erworbenes Wissen zur Privatsphäre einer Person auch nach Beweis ihrer Unschuld nicht in anderen Zusammenhängen gegen diese Person verwendet wird? Wie sind Unternehmen zu behandeln? Was geschieht, wenn man über die Überwachung von Einzelpersonen auf sensible Firmendaten stößt, die ggf. mit dem eigentlichen Grund der Überwachung gar nichts zu tun haben? Es geht ferner um ganz praktische technische Fragen einer Überwachung des Eingriffs der Sicherheitsbehörden durch Fachkräfte der Justiz und auch die Verifizierung der Beendigung eines Eingriffs durch die Justiz. Es geht um die Löschung von aufgezeichneten Informationen, die für den Fahndungserfolg unerheblich sind.

Es geht aber auch um virale Fortpflanzung des invasiven Codes für den Fall, dass der mutmaßliche Verbrecher vor einer Entschlüsselung eine
Kopie empfangener kryptierter Informationen auf Endgeräte ohne Internetkontakt vornimmt. Es geht um die technische Kontrolle einer solchen Fortpflanzung. Es geht ferner um die Frage, ob ein staatlicher Eingriff durch IT-Kundige nicht umschifft werden kann – also um die Frage, ob die Maßnahme gegenüber fachkundigen Verbrechern überhaupt wirksam wäre. Es geht um die Verhinderung eines massenhaften Einsatzes oder die Verhinderung des Missbrauchs durch Unbefugte – WannaCray lässt grüßen und, liebe SPD, von den Hintergründen zu WannaCry, nämlich des Einsatzes von invasiven Techniken US-amerikanischer Behörden, die über Lecks nach außen drangen, wusstet ihr … Es geht um die Frage, ob ein Staat, der hackt, erkannte Schwachstellen in Betriebssystemen oder Anwendungs-Software nicht eher für sich behalten wird. Es geht um die Glaubwürdigkeit der öffentlichen Information zu Schwachstellen in IT-Systemen u.a. durch das BSI. Etc., etc., etc…

Gerne hätte ich zu wenigstens einem dieser Punkte die fachkundige und abgewogene Meinung der SPD erfahren … Leider Fehlanzeige.

Das Thema, dass eine Dekryptierung von Nachrichten, die ein Bürger verschlüsselt hat, durch den Staat grundsätzlich fragwürdig ist, wird in der Antwort des SPD-Vorstands zwar erwähnt, aber erstaunlicherweise nicht ausgeführt. Denn weil der SPD-Obmann im Rechtsausschuss die Meinung vertritt, dass Polizeibehörden auch “diese neuen technischen Wege” gehen sollten, ist bestimmt alles gut. Es geht ja nur um “verdeckte Eingriffe in informationstechnische Systeme zum Zwecke der Durchsuchung” – also um den Staat als Hacker. Passt schon … und bestimmt ist euer Obmann auch ein IT-Fachmann …

Liebe Genossen, ich war über dieses Niveau im Umgang mit einem potentiellen Wähler wirklich erschüttert.

Auf eine weitere Mail, in der ich dann im Detail fachliche und technische Aspekte diskutiert habe und die SPD bat, mir zugehörige Sachfragen zu beantworten, erhielt ich – wenig überraschend – keine Antwort mehr. Obwohl dabei der aus meiner Sicht nicht unerhebliche Punkt angesprochen wurde, dass und wie gerade IT-kundige Verbrecher sich gegen die staatlichen Eingriffe wehren könnten – nicht aber der einfache Bürger.

SPD, quo vadis? Ich sag’ mal:

Die SPD hat in den Grokos vergangener Jahre nicht nur ihr Profil verloren, sondern offenbar auch ihr Niveau bei der Behandlung von Themen, die die heutige und die künftige Freiheit des Einzelnen in unserer Informationsgesellschaft betreffen.

Liebe SPD – leider ward ihr meine Enttäuschung des Jahres 2017:

Grundlegende Eingriffe in bürgerliche Freiheiten gehören in eine breite öffentliche Debatte, bevor man entsprechende Gesetze beschließt. Das betrifft nicht nur eure Glaubwürdigkeit – ohne öffentlichen Diskurs zerbricht der Konsens in einer freiheitlichen Gesellschaft. Gerade ihr solltet wissen, dass das wichtiger ist als Koalitionsdisziplin.

Und glaubt mir: Viele Bürger wissen nicht mal, dass es ein Gesetz zur Quellen-TKÜ gibt und dass der Staat künftig unter definierten Bedingungen Endgeräte überwachen darf. Das bestätigt sich immer wieder in Diskussionen mit Nachbarn, mit Freunden – aber auch mit Geschäftspartnern.

Jetzt und heute werden die Grundlagen für die Behandlung bürgerlicher Freiheiten in einer Welt festgelegt, in der digitale Informationssysteme jeden Lebensbereich erfassen und prägen werden. Das ist keine Thematik, die sich allein in Parlamentsausschüssen und Koalitionsverhandlungen klären ließe. Es ist auch keine Thematik für politisch interessierte Zirkel von selbsternannten IT-Eliten. Diese Thematik geht uns alle als Bürger, aber auch als Unternehmer und Unternehmerinnen in einer liberalen Gesellschaft unmittelbar und dauerhaft an. Alle staatstragenden Parteien sind hier zum öffentlichen Diskurs verpflichtet – eine historisch der Freiheit verbundene Partei aber in besonderem Maße …

P.S.: Enttäuscht wird man in der Regel durch Menschen oder Organisationen, für die man eine gewisse
Sympathie empfindet oder empfunden hat.