Kategorien
Betriebssysteme

Internet-Zugriff für Sublime Text unter Debian unterbinden

Als Texteditor ist hier Sublime Text in der lizenzierten Version im Einsatz.

Es ist aus meiner Sicht vollkommen legitim, daß ein Lizenzinhaber gelegentlich überprüft, ob die zugewiesene Lizenz noch gültig ist. Sublime Text führt diese Online-Überprüfung aber nach jedem Start durch, was im Hinblick auf die Privatsphäre suboptimal ist – letzendlich geht es im Rahmen der erworbenen Lizenz die Entwickler nichts an, ob der Editor fünfzig mal am Tag oder um drei Uhr nachts gestartet wird.

Eine Diskussion mit dem Thema „Sublime Text calling home to license.sublimehq.com on every start?“ im offiziellen Sublime Text-Forum hat leider zu keinem greifbaren Ergebnis geführt. Da auch die Sales FAQ nicht verlangt, daß das Programm nach Hause telefonieren darf / kann / soll / muss, ist eine anwendungsbezogene Sperrung des Netzwerk-Zugriffs eine naheliegende Option.

Unter Windows konnte der Internet-Zugriff für ein beliebiges Programm mit Hilfe der bordeigenen Firewall mit wenigen Klicks blockiert werden, unter Linux ist dies etwas komplizierter. Unter Linux blockiert die Firewall Internetzugriffe von außen basierend auf IP-Adresse und Port und eben nicht wie im aktuellen Fall gewünscht unabhängig  von IP und Port den Zugriff einer Anwendung nach aussen.

Zur Realisierung bietet sich AppArmor an, das unter Debian 10 standardmäßig installiert und aktiviert ist, so daß keine zusätzliche Software benötigt wird. AppArmor verfügt über weitreichende Konfigurationsmöglichkeiten, wer aber einen kurzen Blick in die unter „/etc/apparmor.d“ gespeicherten Profile wirft, wird davon ohne Vorkenntnisse regelrecht erschlagen.

Glücklicherweise gibt es mit den AppArmor Utils die Möglichkeit, ein Profil für eine Anwendung interaktiv zu erstellen.

An der Kommandozeile wird als erster Schritt die Erstellung eines neuen Profils gestartet:

$ sudo aa-genprof /opt/sublime_text/sublime_text

Anschließend wird Sublime Text gestartet und nach Möglichkeit alle darin benötigten Aktionen ausgeführt.

Nach dem Beenden von Sublime Text wird mit Druch auf „S“ im ursprünglichen Fenster die interaktive Generierung gestartet. „aa-genprof“ untersucht nun die anwendungsbezogenen Einträge im Syslog und stellt zu jedem Eintrag die Frage, ob eine Aktion erlaubt sein soll oder nicht.

Das Ergebnis ist ein Profil, das in der Datei „/etc/apparmor.d/opt.sublime_text.sublime_text“ erzeugt wird und nur recht wenige Zeilen enthält.

Um den Netzwerkzugriff zu blockieren, muß – falls vorhanden – die Zeile

#include <abstractions/nameservice>

entfernt werden, denn diese schaltet den Netzwerkzugriff frei, so daß ein anschließend eingefügtes

deny network

keinerlei Wirkung mehr zeigt.

Das fertige Minimal-Profil für Sublime Text sieht dann wie folgt aus:

# Last Modified: Mon May 11 20:28:54 2020
#include <tunables/global>

/opt/sublime_text/sublime_text {
  #include <abstractions/X>
  #include <abstractions/base>
  #include <abstractions/dbus-session-strict>
  #include <abstractions/evince>

  deny network,

  /opt/sublime_text/ r,
  /opt/sublime_text/** r,
  /opt/sublime_text/plugin_host mrix,
  /opt/sublime_text/sublime_text mr,
  /proc/filesystems r,
  owner /dev/shm/* rwl,
  owner /home/** rw,

}

Direkt nach Erzeugung startet AppArmor das Profil im „Enforce“-Modus, d.h. alles, was nicht explizit erlaubt ist, wird verboten. Sofern Build-Systeme o.ä. eingesetzt werden, sind noch Nachabeiten notwendig.

Diese können entweder manuell erfolgen oder durch das Wechseln des Profils in den „Complain“-Modus, dessen Aufzeichnungen anschließend wieder interaktiv ausgewertet werden können.

Zum Start von Perl als Build-System reicht z.B. das Hinzufügen von

/usr/bin/perl mrix,

welches das Starten des Perl-Internpreters mit den geerbten Berechtigungen von Sublime Text erlaubt.

Kategorien
Anwendungen

Zoom unter Linux

Die Videochat-Software von Zoom ist aktuell in vielen Schlagzeilen zu finden und das leider nicht nur im positiven Sinn: von „Unter Beobachtung“ bis „Videokonferenz-Software: Ist Zoom ein Sicherheitsalptraum?“ – spätestens beim Gedanken daran, die Software auf das eigene System loszulassen, beschleicht den Systemadministrator mehr als nur ein ungutes Gefühl.

Wer Zoom trotzdem installieren will / muss und sich dabei halbwegs sicher fühlen will, kann die Software in einer Sandkiste wie z.B. Firejail einsperren.

Zoom

Den Client bezieht man am einfachsten über die Website des Herstellers, wo es den „Zoom-Client für Linux“ fertig gepackt für verschiedene Distributionen gibt.

Nach Herunterladen der gewünschten Version wird diese mittels

$ sudo apt install ./zoom_amd64.deb

inklusive der eventuell noch benötigten Abhängigkeiten installiert und noch vor dem ersten Start abgesichert.

Alternativ kann auch die Version für ein „Anderes Linux-Betriebssystem“ gewählt werden. Der Download ist dann ein gepacktes tar-Archiv, welches ohne Installation in einen beliebigen Ordner entpackt werden kann. Um Abhängigkeiten und Icon muss man sich dann allerdings selbst kümmern.

Firejail

Sofern nicht bereits installiert, kann Firejail in den meisten Fällen direkt aus dem Repository der verwendeten Distribution bezogen werden.

$ sudo apt install firejail

Ein Profil für Zoom wird mitgeliefert und findet sich nach der Installation unter „/etc/firejail/zoom.profile“

Damit beim Aufruf über das Icon in GNOME der Start auch tatsächlich mit Firejail erfolgt, ist der Aufruf von

$ firecfg --fix

Fixing desktop files in /home/benutzername/.local/share/applications
   ...
   Zoom.desktop created
   ...

notwendig, welcher die Links für alle „.desktop“-Dateien aus „/usr/share/applications“ auf absolute Dateipfade überprüft und im Bedarfsfall angepasste Kopien unter „/home/benutzername/.local/share/applications“ anlegt.

Ist Zoom dann gestartet, kann mit

$ firejail --list
3339:benutzername::/usr/bin/firejail /usr/bin/zoom

überprüft werden, daß Firejail auch tatsächlich verwendet wird.

Kategorien
Betriebssysteme

xrdp für andere Benutzer als root aktivieren

Sollte nach der Installation von xrdp die Verbindung nur als root funktionieren und für alle anderen Benutzer verweigert werden, so hilft ein Eingriff in die Datei „/etc/X11/Xwrapper.config“: In der Zeile

allowed_users=console

den Wert von „console“ auf „anybody“ ändern.

Kategorien
Betriebssysteme

Debian pausiert beim automatischen Login

Nach Aktivieren des automatischen Logins legte Debian während des Startvorgangs eine Pause ein, in der zumindest für den Benutzer nichts Sichtbares passierte.

Ein Blick in die Meldungen des Kernels brachte die Erkenntnis, das die Pause in Wahrheit für das Initialisieren des Zufallszahlen-Generators verwendet wurde:

[ 6.278178] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[ 83.784868] random: crng init done

Das Problem wird durch die Art und Weise verursacht, wie der Kernel die Initialisierung durchführt:

The random number generator gathers environmental noise from device drivers and other sources into an entropy pool.

Sofern für den Login-Schirm der Graphikartentreiber initialisiert wird und der Benutzer Maus und Tastatur zur Anmeldung verwendet, wird offensichtlich genügend „environmental noise“ für die Initalisierung generiert, ansonsten dauert’s eben länger.

Eine Lösungsmöglichkeit bietet die Installation eines Pseudo-Zufallszahlen-Generators wie haveged, welcher zwar lediglich Algorithmus-basierte Pseudozufallszahlen generiert, den Bootprozess aber merklich beschleunigt.

Nach einem

$ sudo apt install haveged

sieht der Systemstart dann wieder wie erwartet aus:

[ 2.917662] intel_rapl: Found RAPL domain uncore
[ 3.115268] random: crng init done
Kategorien
Betriebssysteme

Laufwerke von der Kommandozeile ohne Kennwort einbinden

Normalerweise kann auf einem Linux-System nur root ein Laufwerk auf der Kommandozeile ein- oder aushängen, „normale“ Benutzer verwenden hierfür die benötigten Befehle zusammen mit den sudo-Mechanismus.

Bei der automatisierten Einbindung eines Laufwerks ist es allerdings hinderlich, wenn das „sudo“-Kommando beim Einhängen jedesmal nach dem Kennwort des Benutzers fragt, weshalb mit einer Änderung in der Datei „/etc/sudoers“ die Kennwortabfrage für bestimmte Befehle abgeschaltet werden kann.

Achtung: Änderungen an der Datei „/etc/sudoers“ können neben dem Erzeugen von Sicherheitslücken auch dazu führen, daß man sich selbst aussperrt. Deshalb immer ein zweites Terminalfenster öffnen und mittels

$ sudo -i
[sudo] Passwort für localuser:
root@localhost:~#

parallel als root anmelden. So kann – falls die Datei durch eine Änderung beschädigt wird – jederzeit eingegriffen und die Änderung rückgängig gemacht werden. Auch sollten alle Änderungen ausschließlich mit dem Editor „visudo“ durchgeführt werden, der beim Speichern eine Syntaxprüfung durchführt.

Die Änderung ist schnell gemacht und besteht aus dem Hinzufügen einer einzigen Zeile:

$ sudo visudo

...
%sudo ALL=NOPASSWD: /usr/bin/mount, /usr/bin/umount
...

Hiermit wird für alle Benutzer der Gruppe „sudo“ die sudo-Kennwortabfrage für die beiden Befehle „/usr/bin/mount“ sowie „/usr/bin/umount“ deaktiviert.