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
Spiele

Minecraft Pocket Edition: Welten sichern

Auch wenn der Wechsel eines Gerätes eine schöne Möglichkeit zum Aufräumen ist, so gibt es doch einiges, was mit auf das neue Gerät wandern soll. Leider gibt es gerade bei Mobilgeräten – im Gegensatz zum PC – nur selten die Möglichkeit, einen Spielstand manuell zu exportieren und auf einem anderen Gerät weiterzuverwenden.

Die Minecraft Pocket Editon bietet unter „Profil“ in den Einstellungen die Möglichkeit, als Dateispeicherort statt „Anwendung“ die Option „Extern“ zu wählen. „Extern“ bezieht sich hierbei nicht auf das Gerät selbst, sondern lediglich auf den Speicherplatz innerhalb des Geräts, d.h. die Daten entweder innerhalb des geschützten Anwendungsspeichers oder außerhalb auf der (im Zweifelsfall virtuellen) SD-Karte abzulegen.

Leider gibt es (zumindest in der Version 1.14.60) keine Möglichkeit, eine Welt von einem auf den anderen Speicherort zu übertragen. Ist eine Welt einmal im internen Anwendungsspeicher abgelegt, so gibt es keine einfache Möglichkeit, sie nach „Extern“ zweck Sicherung zu verschieben.

Auf einem ge-root-eten Gerät kann man dies trotzdem recht einfach tun, die Welten finden sich im Anwendungsspeicher unter

/data/data/com.mojang.minecraftpe/games/com.mojang/minecraftWorlds/

wobei jede Welt in mehreren Dateien innerhalb eines Unterordners gespeichert ist. Wer sortieren woll, findet den sprechenden Namen einer Welt in der Datei „levelname.txt“.

Vor dem Verschieben (Anwendung schließen!) ist es sinnvoll, den Dateispeicherort auf „Extern“ zu stellen und eine neue Welt anzulegen. Das Programm erstellt dann die benötigten Ordnerstrukturen unter „/storage/emulated/0“, so daß ein manuelles Anlegen entfällt.

Anschließend müssen lediglich die gewünschten Unterverzeichnisse aus dem oben genannten Ordner in das Verzeichnis

/storage/emulated/0/games/com.mojang/minecraftWorlds/

kopiert oder verschoben werden.

Kategorien
Funstuff

Pandemiebär

Kategorien
IMHO

Zeitsynchronisierung mit systemd

Sofern ein Linux-System systemd verwendet muß zum Abgleich der Systemzeit – sofern dieses nicht als Zeitserver für andere Systeme arbeiten sollen – kein ntp mehr insalliert werden.

Es reicht die Anpassung der Datei „/etc/systemd/timesyncd.conf“

$ sudo vi /etc/systemd/timesyncd.conf

in welcher dann in der Zeile „NTP=“ der gewünschte Zeitserver eingetragen wird.

[Time]
NTP=zeitserver.local
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
RootDistanceMaxSec=5
PollIntervalMinSec=32
PollIntervalMaxSec=2048

Nach Änderung der Datei wird der Dienst „systemd-timesyncd.service“ neu gestartet – das war’s.

$ sudo systemctl restart systemd-timesyncd.service

Anschließend kann die Konfiguration des Diensts mittels

$ timedatectl status
               Local time: Mo 2020-04-27 21:19:40 CEST
           Universal time: Mo 2020-04-27 19:19:40 UTC
                 RTC time: Mo 2020-04-27 19:19:40
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

überprüft werden. Wird der Status des „NTP service“ als „inactive“ angezeigt, so ist ein

$ timedatectl set-ntp true

notwendig, um die Synchronisation zu aktivieren. Detaillierte Informationen erhält man entweder über

$ timedatectl timesync-status
       Server: 1.2.3.4 (zeitserver.local)
Poll interval: 1min 4s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 4
    Reference: AF0149C
    Precision: 1us (-21)
Root distance: 31.249ms (max: 5s)
       Offset: -1.759ms
        Delay: 1.972ms
       Jitter: 0
 Packet count: 1
    Frequency: +17,237ppm

oder mit Hilfe von

$ timedatectl show-timesync
SystemNTPServers=zeitserver.local
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=zeitserver.local
ServerAddress=1.2.3.4
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=2min 8s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=4, Precision=-21, RootDelay=17.333ms, RootDispersion=18.478ms, Reference=AF0149E, OriginateTimestamp=Mon 2020-04-27 21:05:29 CEST, ReceiveTimestamp=Mon 2020-04-27 21:05:29 CEST, TransmitTimestamp=Mon 2020-04-27 21:05:29 CEST, DestinationTimestamp=Mon 2020-04-27 21:05:29 CEST, Ignored=no PacketCount=2, Jitter=329us }
Frequency=1353001
Kategorien
IMHO

Update Google Pixel von LineageOS 16 auf 17.1

Vor wenigen Tagen wurde LineageOS 17.1 veröffentlicht – Zeit auf die aktuelle Version zu wechseln und hierbei gleich neue Lineage Recovery auszuprobieren. Der in LineageOS eingebaute Updater erkennt zwar, daß eine neue Version vorliegt, kann das Update aber nicht manuell durchführen.

LineageOS

Die sehr kurz gehaltene Upgrade-Doku spart leider aus, daß man das Lineage Recovery nicht wie bisher für TWRP empfohlen mittels „fastboot boot …“ direkt starten kann, denn dann erscheint lediglich eine Fehlermeldung:

$ sudo fastboot boot lineage-17.1-20200418-recovery-sailfish.img
...
FAILED (remote: dtb not found)

Ein Blick in die Installations-Doku zeigt, daß die Lineage Recovery installiert werden soll:

$ fastboot flash boot lineage-17.1-20200418-recovery-sailfish.img

Anschließend kann die Recovery gestartet werden (Power & Volume down) und über die Menüpunkte „apply update“ / „apply from adb“ empfangsbereit gemacht werden. Die eigentliche Installation des Updates ist unspektakulär:

$ adb sideload lineage-17.1-20200418-nightly-sailfish-signed.zip

GApps (optional)

Die Dokumentation weist darauf hin, daß es wichtig ist, den Zustand bzgl. eventuell verwendeter GApps beizubehalten, d.h. wenn welche installiert waren, müssen sie vor dem ersten Start des Betriebssystems aktualisiert werden.

Hierzu wird die Recovery erneut gestartet und bereit zum Datenempfang gemacht, dann kann das Paket installiert werden.

$ adb sideload open_gapps-arm64-10.0-pico-20200418.zip

Root

Das bisher für LineageOS 16 angebotene „addonsu“ ist aus technischen Gründen leider nicht mehr erhältlich

… our usual provided AddonSU zip to enable root access for the user is no longer feasible

weshalb auf Alternativen wie Magisk ausgewichen werden muss.

… if you want root for apps, flash magisk zip in recovery. Just don’t flash it during initial lineage install, as it’s known to cause bootloop if you do.

Wichtig ist, Magisk nicht zusammen mit LineageOS zu installieren, ob hier ein erneuter Start der Recovery reicht oder ein Systemstart erfolgen sollte, ist nicht ganz klar. Die Installation erfolgt analog zu LineageOS bzw. den GApps am sinnvollsten nach einem Systemstart.

$ adb sideload Magisk-v20.4.zip

Nacharbeiten

Nach der Installation kam von Magisk keine Aufforderung von AFWall+ zum Erhalt von Root-Rechten. Nach einem weiteren Reboot kam dann aber die erwartete Aufforderung.

Der Captive-Portal-Check lief trotz übernommener AFWall+-Einstellungen immer auf einen Verbindungsfehler, die Liste der Freigaben musste noch um „[1073] Network Stack, com.android.server.NetworkPermissionConfig“ erweitert werden, ansonsten wurde dauerhaft das „X“ beim Verbindungsstatus angezeigt und einige Apps haben erst gar nicht versucht, sich mit dem Internet zu verbinden.