Mein Leben mit Linux - Ein Tagebuch

[BlackPanther87]

#5 - Geplante Systemstruktur oder: Denken in Modulen

29.03.2020

Anmerkung: Man entschuldige die lange Verzögerung seit dem letzten Eintrag. Allerdings haben mich Arbeit sowie Erkältung von mir und meinen Kleinen recht erfolgreich vom Schreiben hieran abgehalten. In der nächsten Zeit sollte ich wieder regelmäßiger dazu kommen. Im nächsten Eintrag wird dann endlich mal "produktiv" gearbeitet - ich installiere das erste Hostsystem (mein privates Debian). Wie weit der Eintrag reicht, ist noch nicht ganz klar. Das Standardprozedere kann ich jedenfalls nur eingeschränkt nutzen.

Zurück zum Startpost​

Übersicht für diesen Eintrag

Systemaufbau visualisiert
Der Wahnsinn hat System
Ein genauerer Blick auf die Sicherheit
Mein Konzept für LVM näher betrachtet
Fußnoten

Wie zuvor bereits angedeutet, will ich in diesem Teil einen Überblick über meine geplante Systemstruktur geben. Dabei gehe ich auf den grundsätzlichen Aufbau ein, welche besonderen Techniken ich nutzen will und warum ich keine (wirkend oder auch tatsächlich) simpleren Alternativen nutze. Alle, die am praktischen Arbeiten mit Linux interessiert sind, werden hier wohl nicht so viel Brauchbares finden. Vielleicht findet sich dann ja aber doch die ein oder andere Anregung für eigene Experimente.

---

Systemaufbau visualisiert

Damit das Ganze nicht zu trocken und abstrakt wird, im Folgenden doch direkt mal eine grobe Veranschaulichung des geplanten Systemaufbaus.

Zurück zum Inhaltsverzeichnis​

---

Der Wahnsinn hat System

So, die obige Darstellung mag nun recht verwirrend scheinen. Und dabei zeigt sie noch nicht einmal alles, was genutzt werden wird. Es soll aber ein Grundprinzip andeuten, dass ich versuche (mehr oder minder) strikt durchzuziehen: Separation nach Nutzungsszenario. Die Gründe dafür sind recht vielfältig, aber nur um einige zu nennen:

• Ich will Privates, Gaming, Arbeit und Dozententätigkeit trennen. Ja, "Privates" und "Gaming" sind hier tatsächlich zwei verschiedene Dinge für mich. Steam haben z.B. meine privaten Fotos nicht wirklich zu interessieren. Ähnliches gilt natürlich für meine "reguläre" Arbeit bzw. meine Dozententätigkeit ¹. Jedes soll gegenüber den anderen sinnvoll separariert werden.
• Daher kann ich auch relativ² sicher sein, dass sich professionelle (vertrauliche) Dinge und privates nicht vermischen können. Zum Beispiel sollte selbst im Fall, dass Schadsoftware auf meinem privaten Hostsystem landet (aus welchem Grund auch immer, das ist zweitrangig), keine Arbeitsdaten gefährdet sein.
• Ich will im Falle von Fehlern (fehlerhafte Konfigurationen, aber "Schädlingsbefall" gehört auch dazu), ohne großen Zeit- und Arbeitsaufwand Systembestandteile auf einen früheren Stand zurücksetzen können. Darin begründet liegt sowohl die Konfiguration von minimalistischen Hostsystemen, als auch die intensive Nutzung von Virtualisierungslösungen.

Zurück zum Inhaltsverzeichnis​

---

Ein genauerer Blick auf die Sicherheit

Wie zuvor beschrieben hat Sicherheit bei der Nutzung meines Systems durchaus eine hohe Gewichtung. Ich würde aber nicht soweit gehen, Sicherheit über alles zu stellen. Am Ende muss ich dennoch produktiv arbeiten können³. Das zählt im Übrigen auch für meinen privaten Bereich und selbst das Gaming - bis zu einem gewissen Grad zumindest. Somit gibt es natürlich Wege, die Sicherheit meines Systems weiter zu erhöhen. Zum Beispiel sei hier nur die Separation mit unterschiedlichen (physischen) Systemen zu nennen. Natürlich wäre das sicherer, als so ziemlich alles, was ich mit meinem Konzept irgendwie anstellen kann. Im folgenden führe ich einige Punkte näher aus, die zentrale Punkte meines eigenen Sicherheitskonzeptes darstellen.

1. LUKS
   Üblicherweise genutzt zur Vollverschlüsselung von Speichermedien. In meinem speziellen Fall spreche ich ausdrücklich nicht davon, da ich eben nicht die klassische Variante (komplettes Laufwerk während der Installation verschlüsseln) nutze. Vielmehr sind zum Beispiel einer meiner SSDs drei Hauptpartitionen vorhanden, die alle separat verschlüsselt werden. Somit liegen zum Beispiel Volumes (zu LVM direkt hierunter kurz), die Privatdaten enthalten, auf einer anderen (LUKS)Partition als Arbeitsdaten⁴.
2. LVM
   Entsprechend meines Setups nutze ich hier prinzipiell "LVM on LUKS". Dabei wird auf einem verschlüsselten Laufwerk eine LVM-Konfiguration genutzt. Nun mag man sich darüber streiten, ob LVM an sich die Sicherheit eines Systems erhöht. Es erlaubt mir allerdings, verschiedene Bereiche (Volumes) meines Systems unterschiedlich zu handhaben. Ganz konkret beziehe ich mir etwa auf die unterschiedlichen Optionen, ein Volume zu mounten⁵.
3. Virtualisierung
   Es sollte inzwischen ja klar geworden sein: Virtualisierung ist ein zentraler Punkt für mich. Dies sowohl aus Gründen der Bequemlichkeit aber natürlich auch Sicherheit. Ich nutze hier VirtualBox, und zumindest für die vorhersehbare Zukunft wird das so bleiben⁶. Hier sind insbesondere auch sogenannte "unveränderliche" Images von Interesse. Diese werden mit jedem Neustart auf den vorherigen Zustand zurückgesetzt. Wo immer sinvoll, versuche ich auf diese zurückzugreifen.
4. Monitoring
   Ich überwache innerhalb meines Setups definierte Verzeichnisse auf Änderungen. Als Beispiel seien hier etc (ja, komplett) oder auth.log genannt. Nun sind solche Überwachungen ja reaktiver Natur und proaktiven Maßnahmen (wie Verschlüsselung zum Beispiel). Ich bin aber der festen Überzeugung, dass einer der Hauptschlüssel zu einem sicheren System eine gute Dokumentation ist⁷. Zum Beispiel werden alle Konfigurationsänderungen in einem (GIT)Repository gespeichert.
5. Veracrypt/LUKS-Container
   Die Vollverschlüsselung meines Laufwerks trägt zur Datensicherheit meiner bescheidenen Meinung nach nur bedingt bei. Sobald das Laufwerk entschlüsselt wurde, liegen die Daten ja unverschlüsselt vor. Zudem ist Diebstahl bzw. unerwünschter physischer Zugriff (selbst im geschäftlichen Umfeld) wohl deutlich weniger oft ein Bedrohungszenario. Daten, die als vertraulich, kritisch o.ä. eingestuft werden, sollten also zusätzlich abgesichert werden. Im vorliegenden Fall werde ich dabei hauptsächlich auf Veracrypt-Container zurückgreifen. Sollte ich mir sicher sein, dass entsprechende Daten nur unter Linux-basierten Systemen gelesen werden müssen, wirds vielleicht auch mal LUKS genutzt.
6. Passwort-Management
   Eine Lösung zur Verwaltung der Passwörter ist meiner Meinung nach heutzutage lebensnotwendig. In meinem speziellen Fall wohl noch mehr als ohnehin schon. Ich werde dazu (wie vllt zu erwarten ist) KeepassXC nutzen. Dabei wird aber nicht eine Passwort-Datenbank genutzt, sondern mehrere - nach der Kritikalität der entsprechend enthaltenen Passwörter separariert. Natürlich richten sich danach auch die entsprechenden Speicherorte (für das ein oder andere werde ich auch hardwareverschlüsselte Speicherlaufwerke nutzen).

Zurück zum Inhaltsverzeichnis​

---

Mein Konzept für LVM näher betrachtet

Wie im vorherigen Abschnitt bereits beschrieben, ist LVM ein zentraler Punkt in meinem Konzept, um das relativ komplexe Setup effizient verwalten zu können. Dabei kann man sich meine geplante Struktur etwa wie folgt vorstellen⁸:

nvme0n1
+pv01_hosts_private
-+vg01_hosts_private
---01000_debian
---01010_home
---01020_opt
---01030_var
---01031_var_log
...weitere Systeme nach Bedarf
+pv02_hosts_gaming
...Systeme nach Bedarf
+pv03_hosts_work
...Systeme nach Bedarf
+pv04_hosts_train
...Systeme nach Bedarf
+pv19_hosts_testing
...Systeme nach Bedarf
[...]
+pv20_vms_private
-+vg20_vms_private
...LVs nach Bedarf
[...] Separate PVs/VGs usw. für Gaming, Arbeit und Dozent
+pv29_vms_shared
-+vg29_vms_shared
...LVs nach Bedarf
[...]
nvme0n2
+pv50_data_private
-+vg50_data_private
---50000_docs
---50010_movies
...weitere LVs nach Bedarf
[...]
...weitere PVs/VGs nach Bedarf für Gaming und Dozent (Arbeit nicht, siehe Kommentare unten)

Nun sieht das oben ja furchtbar kompliziert aus. Im Grunde ist es das aber gar nicht - im Folgenden einige Anmerkungen dazu:

• Aufmerksame Leser werden es vielleicht schon bemerkt haben: Ich versuche einzelne Elemente zu indexieren. Dies vor dem Hintergrund, dass ich später ein einzelnes logisches Volume über die fünfstellige ID referenzieren kann.
• Physical Volumes und Volume Groups sind dabei vierstellig gekennzeichnet. Die entsprechend einer Volume Group zugeordneten Logical Volumes nutzen die zweistellige Nummer. Wie man am Beispiel für mein privates Debian-System erkennen kann, weiß ich anhand der ID immer, dass ein LV, welches mit 01 beginnt, zu meinen privaten Host-Systemen gehört⁹.
• Alle LVs, die mit 010 beginnen, sind explizit und direkt meinem privaten Debian-Hostsystem zugeordnet. Ähnliches Prinzip gilt für alle anderen Hosts.
• Für LVs von Hostsystemen sind IDs bis 19999 gedacht. Dabei ist die Gruppe 19 explizit für Hosts mit Testcharakter reserviert. Ich nutze dort z.B. eine separate Debian-Installation, in der Konfigurationsänderung hardwarenah getestet werden können, bevor sie "in Produktion" überführt werden.
• LVs, auf denen ich eigentliche Daten ablege, nutzen IDs ab 50000. Auch hier lege ich wieder Wert darauf, dass eine entsprechende Separation vorhanden ist.
• In keinem Fall werden direkte Arbeitsdaten direkt auf dem System gespeichert, sondern immer nur auf externen (üblicherweise hardwareverschlüsselten) Laufwerken. Das erleichtert mir die Beurteilung nach Projektende anzugeben, dass sich keine Kundendaten mehr in meinem Besitz befinden.
• Natürlich verliert die Nutzung von LVM aufgrund meines genutzten Setups einen guten Teil seiner Vorzüge. Das ist mir durchaus bewusst.
• Gleichzeitig ist das gar kein so großes Problem. Meine Hosts (von solchen, die maximale Performance liefer sollen, mal abgesehen) greifen auf eine minimalistische Grundinstallation zurück, die nur wenig mehr als einen Desktop und eine Virtualisierungslösung bereitstellen. Dementsprechend gibt es da auch keine großen zu erwartenden Änderungen.
• Der eigentliche Teil meiner tagtächlichen Angelegenheiten (privat wie Arbeit) geschieht in den einzelnen VMs. Natürlich werde ich nicht für jede VM einzelne LVs auf den Hosts erzeugen.
• Ebenso werden nur die wenigsten VMs "innerhalb" eine vergleichbare Struktur wie die Hosts aufweisen. VMs werden nach Bedarf zwischen unterschiedlichen Hosts geteilt (das "Grundimage") und dann gemäß des Hosts unterschiedlich konfiguriert (etwa mit separaten eingebundenen Images, geteilten Ordnern o.ä.).
• Wo immer möglich, sind die VMs als unveränderlich konfiguriert. Hier werden dann die benötigten Daten über separate Images eingebunden. In diesem Fall separiere ich die Datenstruktur innerhalb der VM nicht weiter.

---

Fußnoten

1. Wie sich jeder denken kann, ist diese zumindest aktuell faktisch nicht vorhanden.
2. Ich würde an dieser Stelle ja "absolut" schreiben. Wie man auch später sehen wird, steckt hier schon mehr dahinter, als "nur" unterschiedliche Bootsysteme. Ich vermeide aber in aller Regel die Nutzung von Absolutismen, sofern das Thema nicht mein täglich Brot ist (und selbst dort ist das eher die Ausnahme).
3. Ganz aktuell bin ich da an einer Beratung, wo ich mich schon nach der Sinnahftigkeit gewisser Maßnahmen frage. Die Sicherheit des Unternehmens ist quasi "bunkermäßig". Nix kann (ohne weiteres) rein, nix raus - mal von Emails agesehen, die aber auf 10MB begrenzt sind. Wer sich mit TIA-Portal o.ä. beschäftigt, weiß aber, dass die entsprechenden Programme locker 50MB oder mehr erreichen können. In der Maschinensicherheit gibt es den Punkt der Unbedienbarkeit. Ist ein System unbedienbar, wird sich er Nutzer einen Weg suchen, wie er eine Arbeit dennoch erledigen kann. Der Programmierer wird also versuchen, seine Daten über alternative Wege (Cloud, Whatsapp, muaha...) auszutauschen. Ob das am Ende besser ist, als ein (unter eigener Kontrolle befindliches) System, mag jeder selbst entscheiden.
4. Natürlich werden für das Mounten von Volumes Root-Privilegien benötigt. Sollte das also unbewusst oder unbemerkt passieren, hat man ganz andere Probleme. Ich denke, es wird aber klar, worauf ich hinaus will.
5. Natürlich gibt es mehr, aber in meiner fstab-Konfiguration wird desöfteren readonly, noexec oder nosuid zu sehen sein.
6. Ich würde ja gerne KVM nutzen, da ich durchaus die Vorzüge verstehen kann. Zudem würde das auch eher meinem Credo entsprechen, dass ich nach Möglichkeit nativ unterstützte Tools verwenden will. Allerdings verfüge ich in Zusammenhang mit VirtualBox doch über Kenntnisse, die deutlich weiter als "Einsteiger" reichen. Bei KVM kann ich das nicht behaupten. Da ich mich aber dennoch gerne näher damit beschäftigen würde, wird es auch dazu eine Lösung geben. Und wer weiß, vielleicht wird es auch irgendwann den Weg in meine Produktivsysteme finden.
7. Ein Punkt, der meiner Erfahrung nach im Automatisierungsumfeld (gerade Mittelstand) leider oft vernachlässigt wird. Ich bin da schon positiv überrascht, wenn die Risikobeurteilung (was in der IT am ehesten dem Sicherheitskonzept entspricht) vor der eigentlichen Produktion erstellt wird. Von Sachen wie einem (durchgängigen) Vieraugen-Prinzip, konsistenter Programmierung bei verketteten Anlagen oder der ominösen Frage "Was ist denn jetzt der aktuelle Stand auf der Maschine?" fange ich jetzt mal gar nicht an...
8. Wie so oft: Natürlich nur ein Auszug. Zudem passe ich das individuell an. Nicht jedes System ist gleich konfiguriert und insbesondere (unveränderliche) VMs weichen hier ab. Ähnliches gilt für Installationen auf externen Laufwerken (wozu eben insbesondere auch separate Windows-Systeme gehören).
9. Zugegebenermaßen könnte man das natürlich auch am Pfad innerhalb von /dev erkennen. Ich denke aber, es sollte verständlich sein, dass ich hier den Fokus auf die eindeutige Identifizierung unabhängig davon legen will.

Zurück zum Inhaltsverzeichnis

Zurück zum Startpost​

 

[RalphS]

Na das klingt ja gut durchdacht. Gefühlt sehr selten heutzutage, deswegen ein Extra-Gefälltmir zum Gefälltmir.

-- Wie Du schon sehr richtig festgestellt hast ist das mit dem Virtualbox nicht optimal. Auf einem VM-Host hat "überhaupt nichts" zu laufen und VBox mag zwar von der Einrichtung schön einfach sein.... aber dafür ist es auch doppelt anfällig. Egal welchen, aber irgendeinen Type I Hypervisor solltest Du Dir bei Gelegenheit mal anschauen. Das kann auch was in Richtung Xen oder ESXi sein, wenn KVM nicht so Dein Ding ist. Wichtig ist nur, daß die "Steuerzentrale" (also da wo der HV ausgeführt wird) dediziert bleibt und dort nichts anderes ausgeführt wird.

-- Vielleicht hab ichs nur übersehen in der Menge, dennoch sicherheitshalber wiederholt: Backups!
Ganz wichtig. Verschlüsselung und kein Backup schreit geradezu nach Problemen. Wenn irgend möglich: Backups unverschlüsselt und gut geschützt lagern, zB im Safe.

-- Das mit der Unbedienbarkeit ist kein "Maschinen"problem. Es ist ein psychologisches und tritt überall auf, wo es in irgendeiner Form um Absicherung geht. Da Sicherheit und Komfort sich gegenseitig ausschließen, gibt es notwendigerweise zwei Extrema "sicher" und "komfortabel": keins davon ist praktisch brauchbar, da "sicher" notwendigerweise zu "kann nicht mehr dem Einsatzzweck nach verwendet werden" degeneriert. Dann ist es auch egal, ob es die verriegelt und verrammelte Wohnungstür mit fünf Schlüsseln an sechs Stellen im Haus war. Wird es zu unbequem, dann wird halt das Fenster angekippt gelassen. (Dasselbe Problem stellt sich übrigens auch in bezug auf die Häufigkeit von Passwortwechseln.)


In jedem Fall Hut ab für eine durchdachte Lösung. Was jetzt noch bleibt ist, sich dran zu halten. Ich stell mir das recht schwierig vor, aber am Ende des Tages ist es natürlich einfach nur Gewohnheitssache.

Ach ja, fast vergessen. Hätte ich auch selber drauf kommen können, bin ich aber nicht 😊 deswegen danke für die Idee, einfach ein Repository in .../etc anzulegen und so ein Auge auf Änderungen zu haben, sowie diese bei Bedarf zurückrollen zu können. Hab ich schon bei mir eingerichtet im System und wird mir hoffentlich helfen, ungewollte Änderungen zu identifizieren und ungeschehen zu machen.

 

[BlackPanther87]

Danke dir erstmal für das ausführliche Feedback. Um kurz Rückmeldung zu einigen Punkten zu geben.

Das kann auch was in Richtung Xen oder ESXi sein, wenn KVM nicht so Dein Ding ist.

Wird in jedem Fall KVM sein. Im Gegensatz sind eher die anderen beiden nicht meins. Es ist auch nicht so, dass ich null Erfahrung mit KVM habe. Hatte mal ne Zeit lang einen dedizierten Server mit Proxmox gehostet, was im Grunde ja (vereinfacht gesprochen) "Debian + KVM + Web-Interface" bereitstellt. Gerade nochmal interessehalber nachgeschaut und verwundert, dass die weiterhin sockelbasiert lizensieren.

-- Vielleicht hab ichs nur übersehen in der Menge, dennoch sicherheitshalber wiederholt: Backups!
Ganz wichtig. Verschlüsselung und kein Backup schreit geradezu nach Problemen. Wenn irgend möglich: Backups unverschlüsselt und gut geschützt lagern, zB im Safe.

Denke nicht, dass ich bisher explizit was längeres dazu geschrieben hatte. Aber ja, das gehört selbstverständlich dazu. Ich werde dazu (vielleicht auch schon im nächsten Teil) was schreiben, da ich die Host-Backups gerne über Live-Systeme ziehe (also kein Timeshift o.ä.). Clonezilla direkt werd ich dazu nicht nutzen, wohl aber partclone und gzip. Die Backups habe ich in der Vergangenheit "quasi-verschlüsselt" abgelegt (nicht das Backup an sich verschlüsselt, aber die Partition, in der sie gespeichert sind. Insgesamt bin ich mit meiner Backup-Situation aktuell nicht wirklich zufrieden (kein NAS o.ä.), da kommt aber vielleicht ja noch mal was.

-- Das mit der Unbedienbarkeit ist kein "Maschinen"problem. Es ist ein psychologisches und tritt überall auf, wo es in irgendeiner Form um Absicherung geht.

Aus meiner persönlichen Sicht kann es sich zu einem erwachsen (die anderen Ausführungen in deinem Abschnitt teile ich voll, das nur nebenbei). Warum? Nun, dazu muss ich auf etwas zurückgreifen, mit dem ich mich (wirklich) auskenne: Maschinen eben
Es gibt dort in gewissen Normen (z.B. 2006/42/EG, letztlich auch im Produkthaftungsrecht) die Begriffe der "vernünftigerweise vorhersehbaren Fehlanwendung". Wenn ich eine Maschine (in der IT eben ein System) so designe, dass es unbedienbar wird, muss ich mich nachher nicht wundern, wenn daran manipuliert wird. Wenn ein Bediener alle paar Minuten einen Gefahrenbereich betreten muss, weil die fabrikneue Maschine für eine Funktion vielleicht keine "Testfunktion" (im Jargon z.B. Rüsten/Einrichten oder ähnliches) besitzt, stellt sich die Frage, ob das bereits Probleme für den Hersteller bedeuten kann. Nun wird in der IT üblicherweise bei solch einer Geschichte kein Mensch(enleben) gefährdet, der grundsätzliche Gedanke sollte aber klar werden, denke ich.
Aber gut, ich schweife ab. Jedenfalls will ich im späteren Verlauf durchaus versuchen, Bezug auf informatik-relevantere Normen wie die Serie 27001 (mir nur am Rande aktuell bekannt) zu nehmen.

 

[BlackPanther87]

#6 - Risikoanalyse: Testumgebungen verschlüsseln?

05.04.2020

Zurück zum Startpost​

Übersicht für diesen Eintrag

Warum diese Reihenfolge?
Initiale Risikoanalyse
Da müssen wir was tun
Reicht das denn schon?
Fußnoten

---

Warum diese Reihenfolge?

Auf den ersten Blick mag es merkwürdig erscheinen, warum ich gerade die Testumgebung für meinen regulären privaten Host zuerst installieren werde. Viele Nutzer würden es wohl als "natürlicher" empfinden, die Reihenfolge entsprechend zu wechseln. Allerdings werden die meisten Informatiker mir hier zustimmen: Ein Test der grundlegenden Installation und Konfiguration in einer solchen Testumgebung ist vor der Überführung in "die Produktion" sehr hilfreich¹. Nun habe ich eine solche Umgebung auch im Grunde bereits auf meinem "alten" Clevo-System mit einer VirtualBox-VM², die Lösung mit einem dedizierten Bootsystem bietet mir aber unter anderem die folgenden entscheidenden Vorteile:

• Da die Installation direkt auf der Hardware läuft, komme ich der "Produktionsinstanz" so nahe, dass man (beinahe) von einem Klon sprechen kann. Ich werde zwar einige komforttechnische Anpassungen vornehmen, diese beschränken sich aber hauptsächlich auf die genutzte Backupstrategie. LUKS, LVM (natürlich werden die LVs deutlich kleiner), GRUB werden praktisch identisch konfiguriert. Installierte Pakete sind (mit genannten Ausnahmen) deckungsgleich usw.
• Ich kann auch umfangreichere Änderungen durchführen, ohne gleich befürchten zu müssen, mir meine Produktivinstanzen zu zerschießen³. Als Beispiel seien hier nur Tests zur "Dongle-Entschlüsselung" von LUKS-Partitionen genannt.
• Performancetechnisch bin ich faktisch identisch mit meinem Produktivsystem. Unabhängig von der Virtualisierungslösung muss immer mit gewissen Einbußen rechnen (KVM ist hier besser als VirtualBox). Dies gilt insbesondere bei Nutzung von Nested Virtualization (die zumindest VBox faktisch für Intel nicht bietet, selbst der Support für AMD ist meiner Kenntnis nach noch im Beta-Stadium).
• Keine Ahnung wie das bei KVM aussieht, aber zumindest VBox hat meiner Erfahrung nach mit Gästen im UEFI-Modus Probleme. Von Debian weis ich das definitiv, siehe dazu auch das offizielle Wiki. Das mag bei anderen Distributionen vielleicht besser aussehen, ich persönlich habe mir aber angewöhnt: Finger weg von VBox im EFI-Modus. Dies führt natürlich zu Problemen, da eine MultiBoot-Testinstallation in einer VM damit sehr erschwert wird - umso mehr wenn man meine LVM-Struktur bedenkt.

Alles in allem sollten die obigen Punkten einen Eindruck geben, warum ich genau diese Verfahrensweise wähle und wohl erst in einigen Einträgen zur Installation meines "eigentlichen" Produktiv-Systems komme.

Zurück zum Inhaltsverzeichnis​

---

Initiale Risikoanalyse

Um festzulegen, welche Sicherheitsmaßnahmen ich für meine Testumgebung im Speziellen umsetzen will, führe ich zunächst eine Risikoabschätzung durch. Diese versucht sich an die DIN EN ISO 27001 anzulehnen. Ich vermute mal, dass dies vielen Leuten, die professionell im IT-Bereich arbeiten, etwas sagen wird. Ich persönlich hatte bisher praktisch keine Berührungspunkte mit dieser Norm im Speziellen. Sehr wohl aber mit der im Maschinenbau sehr bekannten DIN EN ISO 12100. Der Gedanke ist grundsätzlich sehr ähnlich, im Maschinenbau redet man eben von "Schwere der Verletzung" (Schadensausmaß) und "Häufigkeit/Dauer der Gefährdungsexposition" (Eintrittswahrscheinlichkeit?). Zusätzlich kommt dann noch die "Wahrscheinlichkeit zur Vermeidung" hinzu (keine Entsprechung in 27001).

Wichtig: Jemand "mit Ahnung" bzgl. 27001 mag mich korrigieren, aber ich vermute einfach mal, dass die Einstufung des Risikos selbstverständlich OHNE Maßnahmen zu geschehen hat. Somit müsste man sich z.B. fragen: "Was kann passieren, wenn jemand Unbefugtes Zugriff auf meine Testumgebungen bekommt?". Daraus mag die Risikominderungsmaßnahme folgen, dass man verschlüsselt (oder auch nicht, es muss jeder selbst beurteilen, ob das Risiko akzeptabel ist). Dieser Prozess ist iterativ, das heißt, das noch vorhandene Restrisiko wird erneut beurteilt. Eventuell wird auch hier wieder festgestellt, dass weitere Maßnahmen notwendig sind.

Jedenfalls komme ich zu den folgenden Einschätzungen für die beiden Risikoparameter gemäß DIN EN ISO 27001 (gilt nur im Zusammenhang mit meinen Testumgebungen!)⁴.

Schadensausmaß
Gehen wir also davon aus, dass jemand vollen Zugriff auf (eine) meiner Testumgebungen hat. Gehen wir weiter davon aus, dass KEINE Maßnahmen gesetzt sind (BIOS-Passwörter, GRUB-Passwörter für bestimmte Einträge usw.). Wie zuvor bereits beschrieben, stellen diese eine nahezu exakte Kopie der entsprechenden Produktivsysteme dar. Man könnte also ohne weiteres direkte Rückschlüsse auf die Sicherheitsmaßnahmen meiner eigentlich wichtigen Systeme führen. Folgende Attacken könnten dann natürlich sehr viel zielgerichteter durchgeführt werden. Dazu kommt, dass bei der Annahme, dass bereits unbefugter Zugriff vorliegt, wohl auch auf alle anderen unverschlüsselten Partitionen/LVs zugegriffen werden kann. Somit hätte man dann potenziell Zugriff auf ALLE Testumgebungen (Privat, Gaming, Arbeit, Dozent). Dies würde zwar nicht direkt Arbeitsdaten bedrohen (bei deren Kompromittierung ich durchaus in den Bereich der Schadensersatzpflicht kommen könnte). Es würde aber dennoch zu einem massiven Informationsleck führen. Nach eigener Einschätzung lande ich damit im Risikographen bei "kritisch" (zugegebenermaßen mit Tendenz zu geringfügig)⁵.

Eintrittswahrscheinlichkeit
Die Beurteilung der Wahrscheinlichkeit des Auftretens einer Gefährdung gestaltet sich nun in der Regel etwas einfacher als die Schwere. Im Maschinenbau gibt es relativ gute Indikatoren, wenn von "häufig", "gelegentlich" usw. die Rede ist - die teilweise auch durch entsprechende Normen festgeschrieben werden⁶. Dazu kommen aber auch Erfahrungswerte aus der Vergangenheit. Und hier kann ich berichten, dass bereits durch ein Konkurrenzunternehmen eines ehemaligen Kunden versucht wurde, Informationen abzugreifen. Nun bin ich zwar "sesshaft" geworden (kein klassisches Beraterdasein, im Grunde tätig für ein Unternehmen), aber dennoch in einer Branche mit Schnittmengen unterwegs. Die Exposition für eigentliche "Fremdfirmen" liegt auch nicht mehr so häufig vor wie früher, ist aber doch hin und wieder nicht zu vermeiden. Da wie beschrieben in der Vergangenheit eine solche Gefährdung bereits aufgetreten ist, sehe ich mich gezwungen, das mit "gelegentlich" einzustufen (zugegebenermaßen mit Tendenz zu "entfernt vorstellbar").

Anhand der beiden Parameter oben gelangen wir damit zur folgenden initialen Risikoeinstufung.

Zurück zum Inhaltsverzeichnis​

---

Da müssen wir was tun

Hierbei landen wir also im inakzeptablen Bereich. Dagegen muss natürlich etwas getan werden. Nehmen wir also an, die Testumgebungen liegen auf einer mit LUKS verschlüsselten Partition (ohne weitere explizit definierte Maßnahmen). Meiner Einschätzung nach verändert sich die Einstufung wie folgt:

Zur Erläuterung: Zunächst einmal muss man überlegen, welcher Parameter durch die Schutzmaßnahme denn überhaupt beeinflusst wird. Im vorliegenden Fall kann das nur die Eintrittswahrscheinlichkeit sein⁷. Denn bei Versagen der Verschlüsselung (warum auch immer, das ist zweitrangig) erhält der Angriff dennoch Zugriff auf die Daten aller Testumgebungen. Allerdings wird ein tatsächlicher Zugriff darauf sehr viel schwerer. Das Ausmaß der Verringerung ist natürlich auch wieder eine subjektive Einschätzung. Eine Veränderung um zwei Stufen wegen einer einzelnen (isoliert betrachteten) Schutzmaßnahme mag möglich sein, aus meiner Erfahrung heraus neigt man bei solchen Geschichten aber oft dazu, sich "selbst zu belügen". Denn die Verschlüsselung alleine bringt wohl nicht viel, wenn zum Beispiel das dafür genutzte Passwort unbedacht gewählt wird.

Zurück zum Inhaltsverzeichnis​

---

Reicht das denn schon?

Wie auf dem Schema zu sehen ist, befinden wir uns nun im sogenannten "ALARP"-Bereich (As Low As Reasonably Practicable). Dies bedeutet, dass das verbleibende Risiko abhängig von den eigenen Einschätzungen durchaus als akzeptabel angesehen werden kann. Im privaten Bereich ist das natürlich jedem selbst überlassen, im geschäftlichen mag das unter Umständen etwas anders aussehen. In meiner persönlichen Situation und Einschätzung kann ich mit Hilfe der folgenden weiteren Maßnahmen eine Reduzierung der Eintrittswahrscheinlichkeit um eine weitere Stufe rechtfertigen:

• Einschränkung der Nutzungshäufigkeit
  Hiermit meine ich, dass die Testumgebungen zum Beispiel nicht während Kundeneinsätzen oder ähnlichem genutzt werden. Der entscheidende Punkt hier ist, dass während der Benutzung keine unbefugte Person physisch Zugriff erlangen kann. Also zum Beispiel, wenn ich zuhause oder im Hotelzimmer bin⁸.
• LUKS-Passwort mit relativ hoher Kritikalität
  Es mag trivial erscheinen, das hat aber nicht nur mit der eigentlichen Passwortqualität zu tun. Hier spielen auch Sachen wie Änderungshäufigkeit und Speicherort (rein handschriftlich oder digital als Passwort-Datenbank) eine Rolle⁹.

Bei Umsetzung dieser beiden Punkte habe ich ein gutes Gefühl dabei, die Einstufung nochmal zu verbessern. Auch hier ist wieder wichtig zu erkennen, dass beide Maßnahmen nur Auswirkungen auf die Eintrittswahrscheinlichkeit haben. Bei Versagen wird auch hier der Schaden nicht gemindert¹⁰. Für mich ist die Frage nach der Verschlüsselung meiner Testsysteme damit zunächst einmal beantwortet. Davon unberührt sind selbstverständlich andere im Zusammenhang stehende Geschichten wie die Absicherung des BIOS¹¹.

Es war mir wichtig, an dieser Stelle zumindest einen kurzen Einblick in ein mögliches Konzept zur Umsetzung eines anwendungsbasierten Risikokonzepts zu geben. Im folgenden Eintrag werde ich dann endlich nun auch mit Erstellung des Installationsmediums und der eigentlichen Installation loslegen.

Zurück zum Inhaltsverzeichnis​

---

Fußnoten

1. Mir ist durchaus bekannt, dass Sachen im Maschinenbau, der IT oder auch sonstwo gerne mit der heißen Nadel gestrickt werden, weil sich "irgendwer da oben" Gedanken gemacht hat, dass jetzt unbedingt innerhalb kürzester Zeit irgendein Projekt umgesetzt werden muss. Oft werde ich leider erst gefragt "wenn das Kind schon in den Brunnen gefallen ist". Dann wird dem Kunden etwa eine CE-Kennzeichnung für seine 20 Jahre alte Maschine verkauft, ohne dass man sich bewusst ist, was das eigentlich bedeuten kann. Damit muss diese Maschine dann den aktuell gültigen technischen Bestimmungen entsprechen, somit also die neuesten Sicherheitsvorschriften erfüllen. Mit Ruhe, einer entsprechenden Projektplanung und Kommunikation kann das natürlich alles sehr viel besser laufen. Dementsprechend mache ich mir mit der ganzen Umsetzung hier aktuell auch keine Hektik (merkt man vermutlich^^).
2. Wie schon desöfteren beschrieben (leider) nicht mit KVM, da sich meine Kenntnisse hiermit aktuell noch auf wirkliche Grundlagen beschränken. Im Grunde gelten die Punkte aber mehr oder minder unabhängig von der Virtualisierungslösung.
3. Das gilt selbstverständlich nur in eingeschränktem Maße. Gerade bei Änderungen beim Bootloader könnte ich mir natürlich dennoch den Zugang zum gesamten System sperren. Das ist mir bewusst und auch dafür plane ich einen pragmatischen Workaround (GRUB reinstallieren/reparieren gehört nicht dazu).
4. Selbstverständlich mögen andere Leute zu anderen Schlussfolgerungen kommen, selbst wenn identische Eingangsvoraussetzungen vorliegen würden. Auch mag es andere Verfahrensweisen geben, die besser geeignet für die eigenen Anforderungen sind. Im Grunde soll hier auch nur klar werden, dass ein risikobasierter Ansatz gewählt werden sollte, damit die Maßnahmen abhängig von der Kritikalität getroffen werden. An dieser Stelle reicht das aber auch, eventuell greife ich das in einem zukünftigen Eintrag nochmal auf.
5. Das mag zunächst etwas krass wirken. Es gibt ja nur noch eine Stufe darüber (die dann oft als "existenzbedrohend" beschrieben wird). Aber zunächst mal sollte man im Zweifel eher "nach oben hin" absichern. Zum anderen ist natürlich die Abstufung immer etwas schwer. Deswegen wird in der Literatur oft versucht, bei den Beurteilungen zu quantifizieren. Das funktioniert meiner eigenen Erfahrungen in der Praxis aber oft mehr schlecht als recht. Zum Beispiel wird ein gebrochener Finger von vielen nicht unbedingt als schwere Verletzung angesehen, ist am Ende aber doch eindeutig als solche (da potenziell irreversibel) kategorisiert.
6. Wer genaueres dazu wissen will, dem empfehle ich zum Beispiel das Informationspapier der Berufsgenossenschaft Rohstoffe und Chemische Industrie "Erstellen von Risikobeurteilungen für Maschinen". Schaut relativ weit unten auf der Seite, da ist relativ klein ein Direkt-Link zur PDF (verlinke das ungern direkt hier).
7. Leute, die im IT-Umfeld öfter damit zu tun haben, mögen mich korrigieren, aber: Meiner Erfahrung nach verändern die meisten Schutzmaßnahmen nur einen Parameter. Diejenigen, die beide Parameter verändern, basieren meist auf Redundanz. Das mag in der IT vielleicht funktionieren, im Maschinenbau oftmals nicht. Man stelle sich das nur beim Kran vor: Einen Kranhaken (inkl. Verseilung usw.) redundant auszuführen, macht keinen Sinn, da bei Versagen des ersten Systems durch die zu erwartenden hohen dynamischen Kräfte das zweite direkt mit ausfallen wird. Hier hilft nur die mechanische Auslegung mit entsprechend hohen Sicherheiten.
8. Findige Mitleser werden hier einwenden, dass ich ziemlichen Blödsinn schreibe. Wieso sollte jemand sich den Umweg über meine Testumgebungen machen, wenn er während meiner Kundeneinsätze doch viel einfacher versuchen kann, interessante Daten direkt abzuziehen? Wer nun aber das Thema des risikobasierten Ansatzes durchdenkt, wird darauf kommen, dass hier zwei unterschiedliche Eingangsvoraussetzungen vorliegen. Bei meinem tatsächlichen Arbeitssystem wird zumindest die Kritikalität auf die höchste Stufe gesetzt sein. Die Wahrscheinlichkeit wird vermutlich innerhalb der gleichen Stufe verbleiben. Jedenfalls werden dort selbstverständlich andere (und zusätzliche) Maßnahmen notwendig.
9. Ich bin der Überzeugung, dass ein Passwort-Container je nach Situation durchaus sicherer sein kann als ein "analoger" Zettel. Für die Sachen nämlich, auf die ich eventuell auch mal auf Montage zugreifen muss, kann ein Zettel eine schlechte Idee sein. Ich kann einfach physischen Zugrif auf mein System während Montage nicht zu 100% verhindern. Auch hier ist der entscheidende Punkt wieder eine individuelle Risikoeinschätzung.
10. Man mag sich nun fragen, wie beim vorliegenden Fall denn das Schadensausmaß reduziert werden könnte. Da die Menge und Kritikalität der möglicherweise kompromittierten Daten entscheidend ist, müsste man diese reduzieren. Dies führt zu einer ähnlichen Lösung wie bei meinen eigentlichen Hostsystemen. Separate LUKS-Systeme für Privates, Arbeit usw. Dies würde aber unweigerlich zu einer Verschlechterung der Benutzerfreundlichkeit führen (tut es bei meinen normalen Hosts ja unstrittigerweise auch). Das ist es mir persönlich für die Testumgebungen aber nicht wert bzw. gemäß meiner Einschätzung auch gar nicht mehr notwendig.
11. Ich hatte es ja schon erwähnt: Der Punkt ist nicht, kein Risiko mehr zu haben. Es wird immer ein Restrisiko verbleiben. Der Punkt ist, die verbleibenden Restrisiken auf ein für die Anwendung akzeptables Niveau zu reduzieren. Im Übrigen hat man hier nicht immer die Wahl: Es gibt je nach Branche sehr wohl Vorgaben, die man einhalten muss. Im Maschinenbau sind das (wie anderswo) entsprechende Normen, die (wenn "harmonisiert") den "aktuellen Stand der Technik" definieren. Es obliegt jedem selbst, diese zu erfüllen, es wäre aber dringendst zu empfehlen. Die Gründe dafür liegen in der Beweisführung im Haftungsfall und verhalten sich ähnlich der Beweislastumkehr bei Gewährleistung.

Zurück zum Inhaltsverzeichnis

Zurück zum Startpost​

 

[RalphS]

Mamma mia, da macht sich aber definitiv einer Gedanken. Daumen ganz weit hoch!

Ergänzend zum Thema zwei Anmerkungen, nicht so sehr direkt bezogen als eher informativ, da das, was man im Netz so findet, leider verwäscht und man oft gegenteilige (teils falsche) Informationen findet. Als "Ahnungsloser" kann man dann nicht mehr entscheiden, was stimmt und was nicht.

Ad 1. Stichwort Plaintext-Attacke.
Plaintext-Attacken beruhen darauf, daß man ein Datum bekanntermaßen redundant vorliegen hat, mit der notwendigen Eigenschaft, daß eine Kopie verschlüsselt vorliegt und die andere nicht (plaintext).
Auf diesem Weg ist es möglich, die verwendeten Verschlüsselungsparameter zu rekonstruieren und die restlichen, mit denselben Parametern verschlüsselten Daten, ebenfalls zu rekonstruieren. Grundsätzlich beruht der Ansatz darauf, daß Hashfunktionen unumkehrbar speichern und daher keine Rückschlüsse auf die Ursprungsdaten zulassen und diese Annahme aber nicht mehr zutrifft, wenn jene Ursprungsdaten mitgeliefert werden.

Gegenmaßnahme: Datenträger nicht nachträglich verschlüsseln, sondern initial bei der ersten Verwendung. Das sorgt dafür, daß an keiner Stelle "plaintext" auf dem Medium landet, welcher später für Angriffszenarien verwendet werden kann.


Ad 2. TPM.
Die Idee der Trusted Computing-Architektur (cf. TCG) ist grundsätzlich zunächst, ein integrales System zu haben. Es geht nicht primär darum, daß keiner mitlesen kann: Ziel ist, dem modularen System "PC" eben jene Modularität zu entziehen und stattdessen eine logische Einheit zu bekommen, die auch nur als Einheit funktioniert. In Folge ist der Anspruch, einen PC nicht in seine Einzelteile zerlegen zu können (und damit zB Daten entwenden zu können).
Vor dem Gesichtspunkt kann ein Trusted Computing Modell folgendermaßen aufgebaut sein:
1. System ist UEFI-Modus.
2. Secure Boot ist aktiviert.
3. Multiboot ist deaktiviert.
4. Ein hardwarebasiertes Verschlüsselungsmodul ist installiert, üblicherweise in Form eines TPM.
5. Der Datenträger ist verschlüsselt unter Zuhilfenahme des genannten Verschlüsselungsmoduls.

Der Rechner kann nun nicht mehr zerlegt werden, ohne Zugriff auf die Daten zu verlieren. Man kann aber den PC mitnehmen und wird dann erst vom Login-Bildschirm aufgehalten (oder, soweit konfiguriert, vom Systempaßwort, welches ebenfalls aufs TPM zurückgreift und damit nicht einfach geändert werden kann).
Es bleibt weiterhin möglich, soweit man sich Zugriff auf die Firmwareeinstellungen verschaffen kann, das TPM zurückzusetzen. Da dieses aber für die Verschlüsselung der Daten verwendet wird, sind mit Zurücksetzen jene Daten nicht mehr zugänglich (außer es gab einen Recoveryschlüssel, welcher mit entwendet wurde => das gilt es unbedingt zu vermeiden).


Eine Verschlüsselung ist deshalb ebenso zu planen wie alles andere auch. Was möchte ich erreichen? Was exakt sind die Auswirkungen? Ist es womöglich sicherer, einzelne Ordnerstrukturen zu verschlüsseln, die dann bei jedem Zugriff authentifiziert werden müssen, statt automatisch beim Systemstart (oder Mount des Datenträgers) die enthaltenen Daten freizugeben?

Das TCG-Modell schützt beispielsweise nicht davor, daß jemand den Laptop einsteckt, welcher vom Mitarbeiter unbeaufsichtigt und ohne Sperre/Abmeldung stehen zu lassen. In solchen Fällen verhält sich die Systemsicherung so, als wäre sie nicht vorhanden.

 

[BlackPanther87]

Mamma mia, da macht sich aber definitiv einer Gedanken. Daumen ganz weit hoch!

Vielen Dank dafür, man versucht sein bestes

Gegenmaßnahme: Datenträger nicht nachträglich verschlüsseln, sondern initial bei der ersten Verwendung. Das sorgt dafür, daß an keiner Stelle "plaintext" auf dem Medium landet, welcher später für Angriffszenarien verwendet werden kann.

Absolut richtig. Da meine Laufwerke zuvor nur teilverschlüsset waren, habe ich sie wie im vierten Eintrag beschrieben deshalb auch entsprechend überschrieben. Davon abgesehen ist die durch LUKS erzeugte Sicherheit aber sowieso nur am Rande interessant. Die eigentliche Gefahrenquelle liegt ja beim Kunden vor (zu diesem Zeitpunkt ist das Laufwerk dann entschlüsselt).

Eine Verschlüsselung ist deshalb ebenso zu planen wie alles andere auch. Was möchte ich erreichen? Was exakt sind die Auswirkungen? Ist es womöglich sicherer, einzelne Ordnerstrukturen zu verschlüsseln, die dann bei jedem Zugriff authentifiziert werden müssen, statt automatisch beim Systemstart (oder Mount des Datenträgers) die enthaltenen Daten freizugeben?

Genau aus diesem Gedankengang heraus werden die "wirklich interessanten" Daten ja auch nicht auf dem System an sich abgelegt. Geht zwar (leider) nur mit Einschränkungen, da bestimmte Software mindestens temporäre Kopien ablegt, aber soweit das eben möglich ist. Stattdessen werde ich separierte TrueCrypt-Container nutzen (LUKS nicht möglich, da oft Windows im Spiel ist), die teilweise auch noch mit hardwareverschlüsselten Laufwerken genutzt werden. Als Beispiel seien hier die USB-Laufwerke von IStorage genannt. Ich nutze hier eigentlich nur solche, die nach FIPS 140-2 Level 3 zertifiziert sind (16GB für 107€ UVP, also preislich sicher als gehoben zu betrachten). Es gibt nicht viele deutsche Resourcen, aber wer sich für die Anforderungen der einzelnen Level interessiert, für den mag diese Seite ein guter Start sein. Level-4-Geräte gibt es im freien Handel praktisch nicht zu bekommen, nebenbei bemerkt.

Allgemeine Anmerkung: Es geht hier gar nicht so sehr darum, maximale Sicherheit zu erreichen (die wie ja zuvor schon bemerkt wurde, nicht praktikabel ist), sondern es einem Angreifer erst einmal nur so schwer zu machen, dass er sich ein anderes Angriffsziel sucht. Solange es sich nicht um mein "halb-privates" System handelt, ist mir das dann relativ egal. Wenn ich mir so andere Systeme anschaue, mit denen auf Baustellen gearbeitet wird, ist das jedenfalls oft nicht wirklich schwer...

 

[netzgestaltung]

Hi, ich wollte kurz auf deine Kritik zur Paketbeschreibung von "dell-0926-bionic-meta" zurückkommen.

Description: Meta package for whitehaven-mlk
This is a metapackage for whitehaven-mlk

Da ich schon einigen Installationen zugesehen habe ist mir aufgefallen was es bedeutet und die Bedeutung ist auch mmn ganz OK so. Und zwar werden mit "Metapaketen" weitere Pakete installiert. Die Beschreibung verweist darauf, welches es ist: "whitehaven-mlk".

Eine nähere Beschreibung wird sich vermutlich dort dann finden. Ähnlich ist es zb auch bei der Installation von Desktop Oberflächen, da niemand alle Gnome Pakete kennt, gibt es als Metapaket "gnome-session"

 

[BlackPanther87]

[...]
Da ich schon einigen Installationen zugesehen habe ist mir aufgefallen was es bedeutet und die Bedeutung ist auch mmn ganz OK so. Und zwar werden mit "Metapaketen" weitere Pakete installiert. Die Beschreibung verweist darauf, welches es ist: "whitehaven-mlk".

Eine nähere Beschreibung wird sich vermutlich dort dann finden. [...]

Naja, wie das mit Metapaketen funktioniert, ist mir im Grunde schon bewusst (ich werde bei der manuellen Nachinstallation des KDE-Desktops nochmal einen genaueren Blick darauf werfen). Ich hätte mich wohl auch weniger dran gestört, wenn für "whitehaven-mlk" bei Dell irgendwas als Referenz zu finden wäre.

Folgende Suche z.B.:
https://www.google.com/search?q=whitehaven-mlk+ubuntu
Die ersten zwei Resultate verlinken auf Canonical's Dell-Repository, das im Endeffekt nichts neues an Infos bringt.
Resultat 3 bringt einen in Dells (Community)Forum, in dem auch nur jemand fragt, welche Repos denn benötigt werden.
Resultat 4 ist witzigerweise dann bereits dieser Thread hier.

Dells eigene Dokumentation gibt dazu nichts her. Im Übrigen scheint MLK für "Mid Life Kicker" zu stehen - Referenzthread in Dells eigenem Forum. "Whitehaven" wäre dementsprechend vermutlich ein Dell-interner Codename für was auch immer (die Precision-Serie ist es nicht). Ich habe mir das Ganze aber bereits gedanklich mal für den technischen Support aufgehoben. Kann man meinen PSP-Vertrag ja auch mal bezüglich Linux-spezifischen Dingen nutzen.

Zugegebenermaßen ist das Kritik auf recht hohem Niveau. Es gibt ja nun nicht gerade viele Unternehmen, die Laptops vorinstalliert mit Linux verkaufen und zumindest grundsätzlich auch supporten. Auch wird durch mich ja ohnehin neu installiert. Dennoch achte ich persönlich auf solche Sachen und hätte eine zusammenfassende Dokumentation der durchgeführten Änderungen gegenüber der "Standard-Ubuntu-Installation" für die sprichwörtliche "Kirsche auf der Torte" gefunden. So werde ich jetzt im Nachgang (verhältnismäßig mühselig) eben hier und da Reverse Engineering betreiben.

 

[Pokernikus]

Sie bisher sehr interessant aus.

Hoffe da kommt noch was mehr, dann ist das hier ein klarer Kandidat für die Startseite.

Ganz genau.
Er macht das sehr gut.
Du übrigens auch.

 

[SVΞN]

Er macht das sehr gut.

So ist es und deshalb mach ich mich jetzt mal an die verdiente Notiz für die Startseite.

Du übrigens auch.

Wow! Vielen Dank! Das geht runter wie Öl!

Bleibt gesund!

Sven

 

[xtf]

VM hab ich früher auch gemacht. Bei Linux reicht es aber völlig verschiedene Benutzer zu erstellen, die Programme dort entsprechend zu nutzen und dabei zu bleiben. Firejail oder Bubblewrap können gut die Anwendungen isolieren, teils zu gut. Steam gibt es aber zB in Flatpak, wo es von Haus aus sandboxed ist und den Aufbau weiter "verunkompliziert" und entbloated. Der Weg ist das Ziel, weiter so.

 

[scooter010]

Cool. Kennst du qubes?
KVM XEN hypervisor mit dedizierten qubes für Beruf, privat Test etc.
Qubes-os.org

 

[SVΞN]

Cool. Kennst du qubes?

Qubes OS finde ich persönlich sehr interessant, weshalb ich es schon relativ lange im Einsatz habe.

Mehr dazu auch hier:

Qubes OS 4.0.2: Mit besten Empfehlungen von Edward Snowden

Liebe Grüße
Sven

 

[BlackPanther87]

So ist es und deshalb mach ich mich jetzt mal an die verdiente Notiz für die Startseite.

Wow, vielen Dank dafür! 😊

VM hab ich früher auch gemacht. Bei Linux reicht es aber völlig verschiedene Benutzer zu erstellen, die Programme dort entsprechend zu nutzen und dabei zu bleiben. Firejail oder Bubblewrap können gut die Anwendungen isolieren, teils zu gut. Steam gibt es aber zB in Flatpak, wo es von Haus aus sandboxed ist und den Aufbau weiter "verunkompliziert" und entbloated. Der Weg ist das Ziel, weiter so.

Grundsätzlich gebe ich dir damit recht, für die meisten Nutzer wird das in der Tat wohl ein akzeptabler Mittelweg sein. Es entspricht nur nicht ganz meinen eigenen Vorstellungen. Und nachdem ich gerne mal an verschiedenen Sachen rumprobiere, lässt sich dies mit der Nutzung von VMs in Verbindung mit meinem (zeitweisen) Dokumentationsfimmel besser vereinbaren^^

Cool. Kennst du qubes?
KVM hypervisor mit dedizierten qubes für Beruf, privat Test etc.
Qubes-os.org

Ja, kenne ich, in der Tat eine sehr gute Erwähnung. Ich hatte auch mit dem Gedanken gespielt, es direkt mit in meine grafische Systemübersicht aufzunehmen (in der Tat musste ich gerade nochmal nachschauen, obs nicht doch auftaucht^^). Qubes hat allerdings einige Eigenheiten, die es in meinem System zu einem weniger wichtigen Baustein machen werden (nur in Kürze, ich werde in einem fernen zukünftigen Eintrag bei Bedarf genauer drauf eingehen):

1. Meine Frau
   Im Ernst - ich hatte das bisher so noch nicht aufgeführt. Allerdings wird mein System nicht (ganz) allein von mir genutzt. Es ist absehbar, dass es hin und wieder auch mal von meiner besseren Hälfte benutzt wird. Das bringt allerdings einige Herausforderungen mit (ich weis jetzt schon, dass mir das Thema mit LUKS und "doppeltem" Passwort einige Erklärungen abringen wird bzw. ich eine Dongle-Lösung testen werde). Jedenfalls wäre Qubes hier sicher nicht das richtige System.
2. Die Geschwindigkeit ist sicher nicht vergleichbar mit einem "regulären" System.
3. Qubes fordert von einem eine gewisse Disziplin bzw. dass man ein gewisses Verständnis von Virtualisierung im Allgemeinen und der Umsetzung in Qubes im Speziellen hat.
4. Anonymität != Sicherheit - leider denken viele Leute, dass sie durch die Nutzung eines auf Anonymisierung spezialisierten Systems (wie auch Tails) automatisch sicherer sind. Es gehört ja aber schon einiges mehr dazu (es sei hier nur das Thema Tor und Bad Exit Nodes genannt).

Jedenfalls danke an alle für das Feedback! Vielleicht schaffe ich es auch noch, den nächsten Teil innerhalb der Osterfeiertage fertig zu haben. Nachdem ich jetzt tatsächlich anfange, am System zu arbeiten (meine zwei Wilden Kleinen aber auch zuhause sind), wird das tendenziell zumindest länger. Die ersten Installationsschritte sollten aber relativ flott gehen, hier bin ich noch geübt.

 

[scooter010]

Qubes hat neben einigen Problemen wie sie freie Software eben so hat (Treibersupport) noch ein paar aufgrund der Konzeption vorhandene Probleme:
Ein Stück Hardware gehört immer nur einem System/Qube. Ausnahme ist CPU und RAM, da wird auf bekannte Virtualisierung gesetzt. Monitor, Maus und Tastatur gehören dem dem Hypervisor, LAN einer dedizierten VM mit einem NAT für die einzelnen Qubes.
Games benötigen Low Level Zugriff auf die Graka. Sie muss also der jeweiligen Qube gehören.
Ergo muß es mindestens 2 Graka in einem System geben, eine für den Hypervisor und eine für die Games-Qube.
Welcher Laptop hat das schon? Und selbst wenn, sind die NVidia Optimus oder sowas angebunden, wofür es in Qubes keine Unterstützung gibt.
Somit scheiden grafisch anspruchsvolle Spiele auf einem Laptop mit Qubes einfach aus.
Ich finde, Qubes ist auch eher eine "bessere" Schreibmaschine, die man auch zur Softwareentwicklung (je nach Zweck) kann, aber eher nicht für den Workstation/Gamingstation Einsatz gedacht.

Der Fokus ist eben die Sicherheit, nicht die Kompatibilität.

 

[wayne_757]

Beruflich bin ich (mit Ausnahme von vier Jahren Medizintechnik) im Maschinenbau unterwegs. Dort beschäftige ich mich seit einiger Zeit mit allen Aspekten der funktionalen Sicherheit.

Kleiner Tipp am Rande:
Werde Prozessexperte!

 

[BlackPanther87]

Kleiner Tipp am Rande:
Werde Prozessexperte!

Naja, zu einem guten Teil war ich das in meiner Zeit in der Medizintechnik ja - selbst jetzt ist der eigentliche Gedanke hinter meiner aktuellen Arbeit einen effizienten und gesamtheitlichen Prozess zur funktionalen Sicherheit für das Unternehmen, in dem ich angestellt bin, zu erstellen. Das soll aber eigentlich nicht der alleinige Inhalt meiner Arbeit sein (auch wenn das geldtechnisch gesehen vielleicht die bessere Wahl wäre).

Spoiler: Ein Off-Topic Beispiel dazu

SICK hat (hauptsächlich für die Automobilisten) eine Applikation im Angebot, die sich SafetyPortal nennt. Dabei soll der Zugang zu Gefahrenbereichen abgesichert werden. Vereinfacht gesagt wird hier die Unterbrechung von (nicht sichtbarem) Lichtstrahlen auf einer zweidimensionalen Fläche geprüft. Speziell für diese Anwendung ist, dass der Skid zwar die Erfassungsfläche ohne Unterbrechen der Sicherheit passieren kann, ein Mensch aber sicher erkannt wird. Bei diesen Anwendungen fährt das Skid aber immer zuerst in einen speziell ausgesparten Bereich (der Wagen hat ein vorauseilendes Merkmal). Die Scanner erwarten, dass dieser Bereich unterbrochen wird und blenden dann einen entsprechenden Bereich aus.
In der von mir entwickelten Lösung (hätten verschiedene Leute gerne, gibts aber nicht so ohne weiteres natürlich) ist dieses voreilende Merkmal nicht notwendig (die Unterscheidung wird rein über logische Verknüpfungen gelöst).
Ich brauche so was. Prozesse zu entwickeln, finde ich zwar grundsätzlich interessant. Ich brauche aber doch immer wieder den Praxisbezug. Um die Ecke denken - dazu gehört insbesondere auch Fehler anhand der logischen Verschaltung zu erkennen.

 

[ro///M3o]

Einfach nur WOW!!! (nicht das Spiel sondern die Anerkennung )
Um mir soviel Wissen aneignen zu können, hätte ich sehr sehr lange gebraucht. Allein nur für das Rechachieren und du teilst das mit allen hier in einer sehr verständlichen und super dokumentierten Form. Das macht die Community so besonders! Vielen Dank dafür und meinen Respekt wie ausführlich! Herzlichen Glückwunsch für die mehr als verdiente Startseite. Für Linux mein neuer Almanach.
Nochmals herzlichen Dank

 

[Bigeagle]

Ziemlich umfangreich und interessant.
Wenn ich bedenke dass ich schon manchen als paranoid gelte weil ich noscript im Browser nutze und eine (linux) VM fürs surfen auf potentiell verseuchten Seiten nutze und empfehle ...

Frage die sich mir aber noch stellt: wie machst du das mit den Updates? Bei so vielen Systemen empfinde ich es als teils doch recht beschwerlich. So nach 3 Updateprozessen fängt bei mir dann der 'habe ich das nicht eben schon gemacht?'-gedanke an. Ich habe auch einfach diesen drang bei der ersten Nutzung am Tag erstmal updates zu ziehen - sofern auf linux.
Unveränderliche VMs sind da noch schwieriger weil ein weiterer Schritt dazukommt. Ich bin daher auch wieder davon und von geteilten virtuellen Platten weg.

 

[BlackPanther87]

Frage die sich mir aber noch stellt: wie machst du das mit den Updates? Bei so vielen Systemen empfinde ich es als teils doch recht beschwerlich. So nach 3 Updateprozessen fängt bei mir dann der 'habe ich das nicht eben schon gemacht?'-gedanke an. Ich habe auch einfach diesen drang bei der ersten Nutzung am Tag erstmal updates zu ziehen - sofern auf linux.
Unveränderliche VMs sind da noch schwieriger weil ein weiterer Schritt dazukommt. Ich bin daher auch wieder davon und von geteilten virtuellen Platten weg.

Grundsätzlich eine gute Frage, dazu einige Anmerkungen:

• Das Problem als solches ist mir bekannt und bewusst. Allerdings ist es unwahrscheinlich, dass ich es in absehbarer Zukunft auch angehen werde. Bis dahin zählt hier zunächst mal "Disziplin und Dokumentation". Nicht sehr effizient natürlich.
• Jedenfalls gehe ich bei Arbeiten am System, über das ich hier schreibe nach folgender grundlegenden Reihenfolge vor: Funktion --> Sicherheit --> Komfort --> Visuelles. Natürlich gibt es hier Schnittmengen bzw. im individuellen Fall mag das auch etwas anders aussehen. Aber das Grundlegende sollte klar sein: Es bringt mir nichts, wenn ein absolut sicheres Systeme meine funktionellen Anforderungen nicht bringt. Genauso macht es für mich nicht viel Sinn, mich mit Komfortfunktionen zu beschäftigen, solang das System für mich nicht ausreichende Sicherheit bietet.
• Konkret heißt das: Konkrete Gedanken über Möglichkeiten zum effizienten Updaten meiner VMs mache ich mir erst, wenn der Punkt dafür erreicht ist.
• Falls es aber interessiert, fällt mir aus dem Stehgreif ganz konkret Ansible (und bei Bedarf auch Vagrant) ein. Es gibt hierfür auch recht gute Tutorials (oft eben in Englisch).
• Allerdings sei gesagt, dass meine eigene kurze Risikoeinschätzung hier für Ansible mit VirtualBox wohl darauf hinaus laufen würde, dass ich es nicht damit nutzen würde. Die VM bzw. je nach Situation auch der Host, auf dem Ansible läuft, müsste jedenfalls sehr gut gesichert sein.
• Mit einem "regulären" Type-2-Hypervisor wäre mir hier nicht so wohl. Das würde jedenfalls eine alternative Lösung wie KVM oder sogar einen "richtigen" Server bedeuten. Nicht etwas, dass in absehbarer Zeit bei mir geschehen wird (RedHat sieht KVM als Type-1, da scheiden sich aber wohl nach wie vor die Geister). Am nähesten wird wohl irgendwann die Umstellung meiner VirtualBox-VMs auf KVM kommen. Aber wie schon geschrieben, brauchts da viele (viele) Tests und Übung, bevor ich mich traue, das für irgendwas kritisches zu nutzen.

Ich hoffe, ich konnte dir damit einen groben Einblick in meine Gedanken dazu geben. Es ist jedenfalls nichts, dass ich in nächster Zeit näher beleuchten werde.

EDIT: Bevor ich's vergesse, ein recht guter grundsätzlicher Überblick (Englisch) über Type1 und Type2-Virtualisierungen: https://medium.com/teamresellerclub...visors-what-makes-them-different-6a1755d6ae2c.