Ich möchte das Mailverzeichnis von Thunderbird gegen das System abschotten, um zu verhindern, dass beliebige Prozesse (incl. root) auf den Inhalt zugreifen können. Eine Möglichkeit wäre encfs, aber ich sehe noch keinen Weg, wie man es anstellen kann, dass nur TB den entsprechenden Verzeichnisbaum in Klartext sieht. Hat jemand eine Idee, wie man das anstellen könnte?
Sieh dir SELinux oder AppArmor an. Je nachdem was die Distro bietet.
:
Bearbeitet durch User
Puh… Ich benutze Linux Mint 21.
Vielleicht gibt's da AppArmor. Ähnliche Zielrichtung. Spaß wird vmtl beides keinen machen. Ist eher was für Server.
(prx) A. K. schrieb: > Spaß wird vmtl > beides keinen machen. Ist eher was für Server. Den Verdacht habe ich auch… Eine Möglichkeit wäre evtl. noch ein Docker Container.
Moriz schrieb: > Ich möchte das Mailverzeichnis von Thunderbird gegen das System > abschotten, um zu verhindern, dass beliebige Prozesse (incl. root) auf > den Inhalt zugreifen können. IMAP-Server (physisch oder VM) aufsetzen, Thunderbird darauf zugreifen lassen. Das lokale Caching kann man unterbinden, wenn ich mich recht erinnere.
Wenn du z.B. Truecrypt aufm Rechner hast und einen Symlink des Thunderbird Verzeichnses nach .../truecrypt/user/.mozilla/thunderbird legst, dann die Originaldateien da rein kopierst, hat ausser dir niemand mehr Zugriff darauf. Und ein weiterer Vorteil ist, wnn der Rechner neu gestartet wird und der Truecrypt Container nicht gemountet ist, kann Thunderbird auch nicht gestartet werden. Funktioniert übrigens auch mit vielen anderen Programmen.
Kurt schrieb: > ann die Originaldateien da rein kopierst, hat ausser dir niemand > mehr Zugriff darauf. Was genau hindert andere Programme daran auch auf die Datei zuzugreifen? Verschlüsselte Dateisysteme bringen erstmal nichts, weil eben grundsätzlich alle laufenden Programme Zugriff haben. (prx) A. K. schrieb: > Sieh dir SELinux oder AppArmor an. Das ist die richtige Antwort, das Zauberwort heißt Mandatory Access Control. Dies korrekt zu konfigurieren ist ein sehr hoher Aufwand, da man sehr leicht kleine Fehlerchen macht die das ganze Konzept zunichte machen. Enterprise-Linux-Distros haben da schon ein vorgegebenes System (Policy) für. Am Sinnvollsten (und sichersten!) ist es also, einfach RHEL o.ä. zu verwenden und auf dessen SELinux Policy aufzubauen. Fußangel: Wenn du mit Thunderbird einen Anhang irgendwo hin speicherst, können andere Programme (z.B. PDF-Viewer) diesen dann natürlich erstmal nicht öffnen. Das ist auch sinnvoll, denn da könnten ja geheime Daten vom Thunderbird drin sein.
> Ich möchte das Mailverzeichnis von Thunderbird gegen das System > abschotten, um zu verhindern, dass beliebige Prozesse (incl. root) auf > den Inhalt zugreifen können. Naja, bei mir transportiert das System die mail (fetchmail, sendmail o.ä.) die dann thunderbird auf dem Bildschirm schmeisst. Und manchmal muss ich mir die mails mit alpine anschauen, weil die "grafische Verbindung" zu wenig Bandbreite hat. Einiges wird auch per python sortiert ... also die Idee, das nur thunderbird mailen darf, finde ich nicht so toll. Aber das ist ja auch Dein und nicht mein Rechner der hier verfrickelt wird.
(prx) A. K. schrieb: > Sieh dir SELinux oder AppArmor an. Je nachdem was die Distro bietet. Der TO will auch das root nicht darauf zugreifen kann. Die richtige Antwort lautet daher: Schlag dir das aus dem Kopf. Am nächsten kommst du dem wenn du nur verschlüsselte Mails (PGP o.ä.) dort nutzt und das nur auf einer eigenen Physik laufen lässt. Die Physik bei nichtnutzung in einen Tresor legen, die Schrauben der Physik mit Glitzernagellack sichern und vor jeder Nutzung kontrollieren und die Platte vollverschlüsseln, plus die üblichen Härtungen.
G. K. schrieb: > Der TO will auch das root nicht darauf zugreifen kann. Mit SELinux geht das. Das kann man so einrichten, dass es keinen klassischen root mehr gibt, sondern nur eingeschränkte Kontexte.
Moriz schrieb: > Ich möchte das Mailverzeichnis von Thunderbird gegen das System > abschotten, um zu verhindern, dass beliebige Prozesse (incl. root) auf > den Inhalt zugreifen können. > > Eine Möglichkeit wäre encfs, aber ich sehe noch keinen Weg, wie man es > anstellen kann, dass nur TB den entsprechenden Verzeichnisbaum in > Klartext sieht. > > Hat jemand eine Idee, wie man das anstellen könnte? Wenn Du ein wenig genauer beschreiben könntest, was genau Du erreichen und vor genau was Du Deine E-Mails schützen willst, könnten wir Dir womöglich besser helfen. AppArmor dürfte kaum gehen, denn das wirkt nur auf Executables und darum müßtest Du für alle ausführbaren Programme auf Deinem System entsprechende Policies anlegen, die den Zugriff auf dieses Verzeichnis verbieten -- nicht besonders komfortabel. SELinux bietet an dieser Stelle ein vollständigeres Modell, das auch auf Dateien und Verzeichnisse angewendet werden kann und beim Zugriff die konfigurierten Rechte des Prozesses mit denen der Dateisystemobjekte vergleicht. Möglicherweise wären ACLs eine Möglichkeit, aber die könnte ein User mit root-Privilegien natürlich umkonfigurieren.
Niklas G. schrieb: > G. K. schrieb: >> Der TO will auch das root nicht darauf zugreifen kann. > > Mit SELinux geht das. Das kann man so einrichten, dass es keinen > klassischen root mehr gibt, sondern nur eingeschränkte Kontexte. Damit das vollumfänglich wirkt muss man sich auch um sowas kümmern: https://www.google.com/search?q=linux+disable+selinux
G. K. schrieb: > Damit das vollumfänglich wirkt muss man sich auch um sowas kümmern: SELinux kann man nicht deaktivieren wenn es eingeschaltet und korrekt (!) konfiguriert ist, selbst root kann es nicht. Das ginge nur indem man ein anderes (Live) System bootet und die Systempartition modifiziert. Dies verhindert man über Verschlüsselung + Secure Boot (Systempartition und das ganze OS sowie Bootloader werden dafür signiert). Unter Android ist das vollständig implementiert; selbst wenn man dort "root" Rechte hat hat man nur sehr eingeschränkten Zugriff, und man kann SELinux nicht abschalten. Den eMMC Speicher ausbauen und woanders anschließen hilft auch nix dank Verschlüsselung (Keys sind in der Secure Enclave). Nur über Bugs im Kernel oder Bootloader oder eine explizit dafür vorgesehene Funktion für OEM Unlocking (die dann aber gewisse Features abschaltet) kann man das umgehen.
:
Bearbeitet durch User
Niklas G. schrieb: > G. K. schrieb: >> Damit das vollumfänglich wirkt muss man sich auch um sowas kümmern: > > SELinux kann man nicht deaktivieren wenn es eingeschaltet und korrekt > (!) konfiguriert ist, selbst root kann es nicht. Das ginge nur indem man > ein anderes (Live) System bootet und die Systempartition modifiziert. > Dies verhindert man über Verschlüsselung + Secure Boot (Systempartition > und das ganze OS sowie Bootloader werden dafür signiert). Du hast da was vergessen: https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html https://danwalsh.livejournal.com/10972.html Wobei disable anstatt permissive sehr spannende Effekte erzeugen kann, insbesondere wenn das relabeling nicht korrekt nachgezogen wurde.
:
Bearbeitet durch User
G. K. schrieb: > Du hast da was vergessen: Man kann auch dem root problemlos verbieten, die Kernel Commandline in der Bootloader Konfiguration zu modifizieren. Dann ginge es nur mit physischen Zugang - außer man verwendet Secure Boot und deaktiviert das manuelle Ändern der Command Line im Bootloader Menü. Genau wie unter Android halt. Android ist übrigens eine ziemlich gute Antwort auf die Frage - die Daten von Apps inklusive der Mail-Apps sind sehr gut abgeschottet, da kommt man so gut wie nicht dran (inkl root).
Beitrag #7866973 wurde vom Autor gelöscht.
Ein T. schrieb: > Wenn Du ein wenig genauer beschreiben könntest, was genau Du erreichen > und vor genau was Du Deine E-Mails schützen willst, könnten wir Dir > womöglich besser helfen. Ganz simpel: Ich will verhindern, dass irgend welche wie auch immer aufgebaute Malware auf meinem System an die EMails kommen kann. Hintergrund: einem Bekannten wurden möglicherweise seine Mails gestohlen und daraus ein Szenario für Social Engineering an seinen Mailpartnern extrahiert. Das Ganze war noch nicht sehr ausgereift, weil die Mails, die verschickt wurden, so dämlich formuliert waren, dass ein Blinder erkennen konnte, dass da was faul ist. Ich rechne damit, dass die Saukerle ihre KI irgendwann so weit perfektionieren, dass sie den Stil des Lockvogels perfekt nachmacht. Deswegen möchte ich meine Mails für Trojaner u.Ä. unerreichbar machen.
:
Bearbeitet durch User
Moriz schrieb: > Ich will verhindern, dass irgend welche wie auch immer aufgebaute > Malware auf meinem System an die EMails kommen kann. Wie wäre es zu verhindern das du irgendeinen "Schädling" in dein system rein lässt? Alles andere wäre grob fahrlässig! Moriz schrieb: > Ich rechne damit, dass die Saukerle ihre KI irgendwann so weit > perfektionieren, dass sie den Stil des Lockvogels perfekt nachmacht. > Deswegen möchte ich meine Mails für Trojaner u.Ä. unerreichbar machen. Bis die ihre KI so weit haben, falls die überhaupt eine verwendet haben, denn die Dinger kennen sowas ähnliches wie Moral und Ethik, das muss man denen erst abgewöhnen (weg programmieren) wird es noch dauern. Tipp: Keine Mails mehr schreiben! Nur noch Zettel mit UV Tinte und die muss der Empfänger dann essen, nach dem sie gelesen wurden! Das kann keiner mehr mitlesen...
:
Bearbeitet durch User
Kilo S. schrieb: > Alles andere wäre grob fahrlässig! Der Teufel ist ein Eichhörnchen und Murphy's Law ist immer noch in Kraft… > denn die Dinger kennen sowas ähnliches wie Moral und Ethik Wo hast du denn diesen Blödsinn her?
Moriz schrieb: > Ganz simpel: Ich will verhindern, dass irgend welche wie auch immer > aufgebaute Malware auf meinem System an die EMails kommen kann. Simpel ist allerdings was anderes. Und wenn du das für simpel hältst wirst du wahrscheinlich die Komplexität die dafür notwendig ist nicht beherrschen können. > Hintergrund: einem Bekannten wurden möglicherweise seine Mails gestohlen > und daraus ein Szenario für Social Engineering an seinen Mailpartnern > extrahiert. Das Ganze war noch nicht sehr ausgereift, weil die Mails, > die verschickt wurden, so dämlich formuliert waren, dass ein Blinder > erkennen konnte, dass da was faul ist. Und wenn die Malware im Kontext deines MUAs läuft? Oder auf den MTAs welche andere kontrollieren? Moriz schrieb: > Bis die ihre KI so weit haben, falls die überhaupt eine verwendet haben, > denn die Dinger kennen sowas ähnliches wie Moral und Ethik, das muss man > denen erst abgewöhnen (weg programmieren) wird es noch dauern. Nö, das gesunde Volksempfinden wird denen extra rein trainiert: https://www.derstandard.at/story/3000000265338/llama-4-meta-trimmt-seine-ki-nach-rechts-um-trump-zu-gefallen
:
Bearbeitet durch User
G. K. schrieb: > Simpel ist allerdings was anderes. > Und wenn du das für simpel hältst wirst du wahrscheinlich die > Komplexität die dafür notwendig ist nicht beherrschen können. So ist es, unter normalem Desktop Linux Daten vor dem root User zu verstecken ist extrem aufwendig. Daher z.B. RHEL nutzen. Oder einfach Android, oder einen separaten Computer für email und Internet. Moriz schrieb: > Hintergrund: einem Bekannten wurden möglicherweise seine Mails gestohlen Sicher dass das über Zugriff auf das lokale Mailprogramm passiert ist? Das ist ja ne ziemliche 90er Methode. Ganz davon abgesehen dass keiner Malware für Desktop Linux schreibt. Vermutlich hatte der Bekannte beim email Postfach das gleiche Passwort wie bei anderen online Diensten, und irgendeiner wurde gehackt...
:
Bearbeitet durch User
Niklas G. schrieb: > Moriz schrieb: >> Hintergrund: einem Bekannten wurden möglicherweise seine Mails gestohlen > > Sicher dass das über Zugriff auf das lokale Mailprogramm passiert ist? > Das ist ja ne ziemliche 90er Methode. Ganz davon abgesehen dass keiner > Malware für Desktop Linux schreibt. Vermutlich hatte der Bekannte beim > email Postfach das gleiche Passwort wie bei anderen online Diensten, und > irgendeiner wurde gehackt... Ach komm, ohne monokausales Feindbild hat der Tag doch keine Struktur.
Moriz schrieb: > Ganz simpel: Ich will verhindern, dass irgend welche wie auch immer > aufgebaute Malware auf meinem System an die EMails kommen kann. Mir ist keine Möglichkeit bekannt, mit der sich das von Dir Gewünschte mit auch nur ansatzweise vertretbarem Aufwand realisieren ließe. Zumindest die mir bekannten Sicherheitsmodelle (SELinux, AppArmor, RSBAC) unterbinden alles, was nicht explizit erlaubt worden ist. Das bedeutet: Du würdest die Zugriffsberechtigungen jedes Executable auf dem System korrekt konfigurieren müssen. Auf einem Server, der ja üblicherweise relativ wenige Executables installiert hat und wo tendenziell eher selten neue Software installiert wird, ist das zu einem (durchaus hohen) Preis noch möglich -- allerdings finden sich auf meinem Desktop mindestens 3685 Executables... Auch Technologien wie verschlüsselte Dateisysteme funktionieren nicht. Denn damit Dein Thunderbird auf das verschlüsselte Dateisystem zugreifen könnte, müßte es natürlich gemountet sein, und dann ist es augenblicklich auch für mindestens alle privilegierten Nutzer auf dem System lesbar. Ähnliches gilt natürlich für alle Ansätze mit FUSE. Möglicherweise könntest Du mehr Glück mit anderen Linux Security Modules haben, wie TOMOYO, SMACK, LoadPin, SARA, KSRI und wie sie alle heißen, aber grundsätzlich würde ich wegen der notwendigen "all-or-nothing"-Ansätze, die solche Module durchsetzen müssen, nicht allzu viel Hoffnung hegen. Trotzdem wünsche ich Dir viel Glück und bitte um eine Rückmeldung, sofern Du wirklich etwas findest, womit das mit vertretbarem Aufwand geht. > Hintergrund: einem Bekannten wurden möglicherweise seine Mails gestohlen > und daraus ein Szenario für Social Engineering an seinen Mailpartnern > extrahiert. Das Ganze war noch nicht sehr ausgereift, weil die Mails, > die verschickt wurden, so dämlich formuliert waren, dass ein Blinder > erkennen konnte, dass da was faul ist. Hm, okay, machen wir es kurz: Dein "möglicherweise" weist darauf hin, daß Dir nicht einmal sicher bekannt ist, ob die E-Mails Deines Bekannten entwendet worden sind. Für eine reine Vermutung halte ich aber schon Deinen Ansatz für deutlich übertrieben, und wenn ich mir die Aufwände einer Realisierung etwa mit SELinux anschaue... solltest Du eher Dich darauf konzentrieren, Dir erst gar keine Schädlinge einzufangen. > Ich rechne damit, dass die Saukerle ihre KI irgendwann so weit > perfektionieren, dass sie den Stil des Lockvogels perfekt nachmacht. Irgendwann könnte das möglicherweise vielleicht eventuell so sein. Aber angesichts meiner Erfahrungen mit KI bezweifele ich stark, daß sowas in absehbarer Zukunft geschehen wird. Die einzige machbare Lösung, die ich da noch sehe, wäre es, den Storage-Layer von Thunderbird mit einer Verschlüsselungsschicht zu erweitern. Aber auch das wäre natürlich ein signifikanter Aufwand, und wer die APIs von OpenSSL kennt, wird sich sicher nicht um diesen Job reißen. :-)
Moriz schrieb: > Wo hast du denn diesen Blödsinn her? Blödsinn? Aha, ich hab schon des öfteren (bei technischen Fragen, etwas spezieller, zb. Zum Dissasembly der Fumot Firmware) von der "KI" gesagt bekommen:"Leider kann ich dir darüber keine Antwort geben weil das verboten ist. , unterstützen nicht beim Hacken"... Oder anders gesagt eine KI die Social engineering betreiben soll braucht mindestens ein verändertes Modell! G. K. schrieb: > Nö, das gesunde Volksempfinden wird denen extra rein trainiert: Und was hat das damit zu tun das die KI mir erzählen will das sie sich nicht am Hacking beteiligt? Niklas G. schrieb: > Das ist ja ne ziemliche 90er Methode. Ganz davon abgesehen dass keiner > Malware für Desktop Linux schreibt. Bist du dir da ganz SICHER? Peinlich für dich! Seltener aber gibt es: Perfctl, Sedexp, L10n.. https://de.m.wikipedia.org/wiki/Liste_von_Linux-Malware
Kilo S. schrieb: > Bist du dir da ganz SICHER? > Peinlich für dich! > Seltener aber gibt es: Perfctl, Sedexp, L10n.. "Keiner" ist eine rhetorische umgangssprachliche Untertreibung, im Sinne von "insignifikant wenige". Peinlich, solche sprachlichen Nuancen nicht erkennen zu können aber dennoch meinen mit Beleidigungen um sich werfen zu müssen. Und tatsächlich ist die von dir zitierte Liste extrem kurz im Vergleich zur Masse an Windows-Malwares.
Kilo S. schrieb: > Moriz schrieb: >> Wo hast du denn diesen Blödsinn her? > > Blödsinn? Ja. Totaler Blödsinn, um genau zu sein. > Aha, ich hab schon des öfteren (bei technischen Fragen, etwas > spezieller, zb. Zum Dissasembly der Fumot Firmware) von der "KI" gesagt > bekommen:"Leider kann ich dir darüber keine Antwort geben weil das > verboten ist. , unterstützen nicht beim Hacken"... Du sprichst von ChatGPT oder einem anderen Large Language Model (LLM). Alle LLMs, die öffentlich zugänglich sind, haben nach Microsofts Erfahrungen mit dem Bot Tay [1] solche "Entschärfungen" eingebaut. Das ist aber nicht "die KI", sondern nur eine ganz besondere Ausprägung davon. [1] https://de.wikipedia.org/wiki/Tay_(Bot)
Ein T. schrieb: > Die einzige machbare Lösung, die ich da noch sehe, [...] Ich bitte um Verzeihung, daß ich mir selbst antworte, aber mir ist eben noch eine weitere Lösung eingefallen: nämlich die Entwicklung eines eigenen Linux Security Module (LSM). Keine Ahnung, wie aufwändig das wäre.
Ein T. schrieb: > Auch Technologien wie verschlüsselte Dateisysteme funktionieren nicht. > Denn damit Dein Thunderbird auf das verschlüsselte Dateisystem zugreifen > könnte, müßte es natürlich gemountet sein, und dann ist es > augenblicklich auch für mindestens alle privilegierten Nutzer auf dem > System lesbar. Ähnliches gilt natürlich für alle Ansätze mit FUSE. Ich hatte ja schon mal die Verschlüsselung von Mails mit z.b. PGP in den Raum geworfen um einen Teil der Angriffsmöglichkeiten zu erschweren.
Ein T. schrieb: > Ich bitte um Verzeihung, daß ich mir selbst antworte, aber mir ist eben > noch eine weitere Lösung eingefallen: nämlich die Entwicklung eines > eigenen Linux Security Module (LSM). Keine Ahnung, wie aufwändig das > wäre. Wenn man nur einen Hammer kennt sieht alles wie ein Nagel aus.
G. K. schrieb: > Ich hatte ja schon mal die Verschlüsselung von Mails mit z.b. PGP in den > Raum geworfen Normalerweise kann der root User auf den Speicher aller Prozesse zugreifen, also eben auch den Schlüssel und die Mails aus dem Thunderbird Prozess abgreifen.
Ein T. schrieb: > Das ist aber nicht "die KI", sondern nur eine ganz besondere Ausprägung > davon. OK, dann zeig doch mal eine die das (nach dem aufsetzten auf deinem System) klaglos mit macht. Du bist nicht der erste der das Versuchen würde, zwei der Typen die dachte sie können "KI Böse machen für ihre zwecke" hab ich schon hart scheitern sehen! Gut das eine ist nen Möchtegern Systemintegrator der jedes Mal bei mir aufschlägt wenn er ein Problem hat, das andere nen komischer Möchtegern Hacker der nicht mal einen Arduino Sketch zum funktionieren bringt. Außer Zahnbelag haben die beiden nix drauf was IT angeht. Ist schon lustig, du sagst selbst die öffentlichen können es nicht, sagst aber auch nix dazu wie lange es dauern würde das bei einer selbst aufgesetzten KI zu ändern! Und ich gehe noch davon aus daß man genau aus diesem Grund, Verhinderung einer "Bösen" KI, nicht nur an den Trainingsdaten liegt, das wäre zu einfach Niklas G. schrieb: > Peinlich, solche sprachlichen Nuancen nicht erkennen zu können aber > dennoch meinen mit Beleidigungen um sich werfen zu müssen. Keiner heißt keiner, sonst nennt sich das wenige! Und wäre es nur ein einziger, dann wär's immer noch mehr als "Keiner". Niklas G. schrieb: > Und tatsächlich ist die von dir zitierte Liste extrem kurz im Vergleich > zur Masse an Windows-Malwares. Ja, glücklicherweise. Wobei die garantiert nicht vollständig ist. Abgesehen davon, schau mal auf die Datumsangaben! Wie lange es das doch schon gibt.
Kilo S. schrieb: > Keiner heißt keiner, sonst nennt sich das wenige! Und wäre es nur ein > einziger, dann wär's immer noch mehr als "Keiner". In deinem Universum vielleicht, der Rest der Welt kann mit Umgangssprache umgehen. Kilo S. schrieb: > Abgesehen davon, schau mal auf die Datumsangaben! Wie lange es das doch > schon gibt. Eben, die entsprechenden Vulnerabilities sind sicher schon längst repariert.
Wie kommt die meiste Malware auf die Rechner? Über Mail. Wenn so eine Malware-Email eine Sicherheitslücke in Thunderbird ausnutzt, in welchem Kontext läuft die dann? In dem von Thunderbird. Worauf hat Thunderbird Zugriff? Auf die Mails. Auf was hat die Malware Zugriff? Auf die Mails. Auf was hätte ein Virenscanner Zugriff? Nicht auf die Mails. Mit einem (selbstgehosteten) Webmail-Server und Zugriff über Webbrowser (natürlich ohne lokalen Disk-Cache) bist du sichererer. Da kannst du den Speicherort der Mails und möglichen Einfallspunkt für Malware physikalisch voneinander trennen.
Niklas G. schrieb: > G. K. schrieb: >> Ich hatte ja schon mal die Verschlüsselung von Mails mit z.b. PGP in den >> Raum geworfen > > Normalerweise kann der root User auf den Speicher aller Prozesse > zugreifen, also eben auch den Schlüssel und die Mails aus dem > Thunderbird Prozess abgreifen. Weswegen ich extra folgendes formuliert habe: " ... um einen Teil der Angriffsmöglichkeiten zu erschweren."
:
Bearbeitet durch User
G. K. schrieb: > Ich hatte ja schon mal die Verschlüsselung von Mails mit z.b. PGP in den > Raum geworfen um einen Teil der Angriffsmöglichkeiten zu erschweren. Wenn Du Deine E-Mails mit PGP (oder mit S/MIME oder dem GNU Privacy Guard) verschlüsseln würdest, dann wüßtest Du sicher, daß es dazu entsprechender Kommunikationspartner bedarf, die ihrerseits ihre Mails verschlüsseln. Das betrifft leider nur die Wenigsten; die Meisten verstehen nicht einmal, was dieser komische Anhang in meinen signierten E-Mails beinhaltet. Besonders lustig fand ich einen Benutzer, der mir in seiner Antwort auf meine E-Mail meine eigene Mailsignatur zurückgeschickt und geglaubt hat, das würde die Sicherheit unserer Kommunikation erhöhen. G. K. schrieb: > Wenn man nur einen Hammer kennt sieht alles wie ein Nagel aus. Da die verschiedenen mir bekannten Hämmer Dir offenbar nicht ausreichen, könntest Du natürlich zu meiner Erhellung beitragen und erzählen, was mir anscheinend entgangen zu sein scheint. Die Verschlüsselung von E-Mails ist, wie oben ausgeführt, jedenfalls nicht besonders praktikabel -- und Niklas' Einwand, daß ein Angreifer mit Root-Privilegien durchaus an die Schlüssel kommen könnte, ist natürlich ebenfalls zunächst gültig.
Niklas G. schrieb: > Eben, die entsprechenden Vulnerabilities sind sicher schon längst > repariert. Na und? Gibt doch längst neue:https://zendata.security/de/2025/02/27/neue-linux-malware-auto-color-ermoeglicht-angreifern-vollstaendigen-fernzugriff/
Moriz schrieb: > incl. root Das geht nicht, weil der Kernprozess immer root ist. Aus diesem Grunde sind keine Inhalte unpruefbar in einer Cloud fuer den Meister (Hersteller) jedes Betriebssystems.
Kilo S. schrieb: > Ein T. schrieb: >> Das ist aber nicht "die KI", sondern nur eine ganz besondere Ausprägung >> davon. > > OK, dann zeig doch mal eine die das (nach dem aufsetzten auf deinem > System) klaglos mit macht. Language Models -- auch große -- sind nur für jene Hexenwerk, deren Kenntnisse und Erfahrungen sich auf vortrainierte Modelle beschränken. > Außer Zahnbelag haben die beiden nix drauf was IT angeht. Bisher habe ich allerdings noch nichts von Dir lesen dürfen, daß Dich für eine Sachdiskussion qualifiziert oder mir Dein Interesse daran signalisiert hätte. > Ist schon lustig, du sagst selbst die öffentlichen können es nicht, > sagst aber auch nix dazu wie lange es dauern würde das bei einer selbst > aufgesetzten KI zu ändern! Das betrifft ja nur die öffentlich zugänglichen Modelle. Aber was ich selbst modelliere und womit ich es trainiere, entscheide ich immer noch selbst. > Und ich gehe noch davon aus daß man genau aus diesem Grund, Verhinderung > einer "Bösen" KI, nicht nur an den Trainingsdaten liegt, das wäre zu > einfach Du verstehst ja offensichtlich nicht einmal, was ich schreibe. Ich habe NICHT gesagt, daß die öffentlich zugänglichen Modelle das nicht könnten.
Niklas G. schrieb: > Normalerweise kann der root User auf den Speicher aller Prozesse > zugreifen, also eben auch den Schlüssel und die Mails aus dem > Thunderbird Prozess abgreifen. "Normalerweise" trifft es gut. Um Löcher dieser Richtung zu stopfen gibt es heute die in Hardware gegossene Möglichkeit, RAM Adressräume von Anwendungen individuell zu verschlüsseln. Aber um dieser Kanone das im Laufe des Threads immer weiter anwachsende Kaliber :) zu reduzieren: Dem mittlerweile etwas untergetauchten Moritz wäre wohl schon gedient, indem er den Thunderbird in einer eigenen verschlüsselt gespeicherten VM platziert. Das ist nicht perfekt, sondern ein Kompromiss, jedoch praktikabel. Und dank Linux obendrein nicht allzu raumgreifend.
:
Bearbeitet durch User
QubesOS, ein Linux das jeden Prozess isoliert laufen lässt gibts auch noch. Aber wenn deine Malware über email reinkommt nützt das auch nix, deine ganze Idee ist Schwachsinn im Quadrat.
Franko S. schrieb: > Aber wenn deine Malware über email reinkommt nützt das auch nix, > deine ganze Idee ist Schwachsinn im Quadrat. Richtig, die Maleware verteilt / aktiviert sich nicht von alleine. Du kannst tausende verseuchte Junk-Mails auf dem Rechner liegen haben und es passiert genau nix - erst wenn der Problemfaktor "Mensch" zugreift (in dem Fall öffnet / anklickt) geht es los. Dann nämlich liegt die Maleware genau da wo sie hin will: im RAM.
Ein T. schrieb: > Ich habe NICHT gesagt, daß die öffentlich zugänglichen Modelle das nicht > könnten. OK, dann hätte ich gerne den Link zu einer, die man deiner Meinung nach für solche SE Angriffe problemlos trainieren kann. Genauso wie zur Mithilfe beim finden von "Nicht öffentlichen" Datenblattern, ach und nicht zu vergessen das sie auch Login Geschütze Seiten uns Server öffnen muss (mit eigenem Account, Hacken oder sonst wie!) um mir SDK, Codebeispiele ect. zu organisieren die hinter einer Paywall bzw. mit Accountzwang verbunden sind. Und sollte das wirklich nur an den Trainingsdaten liegen, ich glaube nicht wirklich daran, es wäre grob fahrlässig da nicht im "verarbeitenden" Teil einen möglichst schwer zu "brechende" "Grundmoral/Ethik" zu implementieren. Dann sollten die Entwickler dafür auf ewig Sand in der Wüste schaufeln gehen! Das ist wie einem irren ne Knarre zu geben, man wüsste Genua es kann was passieren, nur wann, das weiß man erst wenn es zu spät ist. Ich stell ja auch nicht einfach meine HV experimentiere auf den Spielplatz im guten Glauben "wird schon keiner anfassen".
Meistens muss man sogar mehrfach klicken, um sich per Mail etwas einzufangen: nämlich auf den in der Mail enthaltenen Link. Die Mail nur zu öffnen reicht oft nicht aus.
:
Bearbeitet durch User
Ich mache es eigentlich umgekehrt, und zwar schränke ich den "Zugriffsradius" von Mailprogramm und Browser (TB & FF) via Firejail ein. Außer ihren "Systemverzeichnissen" haben die praktisch nur Zugriff auf den Downloads-Ordner. Alles andere "sehen" sie nicht. Das bedeutet zwar, dass ich einen Mail-Anhang zunächst in den Downloads-Ordner kopieren muss, aber damit kann ich leben. Für Links in TB eignet sich auch die Erweiterung "Torpedo", die versehentliches klicken doch um einiges erschwert.
Wäre ein anderer Mail-Client evt. eine Option? Claws Mail z.B. dürfte etwas weniger Angriffsfläche bieten, jedenfalls, wenn man nicht einfach jedes Plugin installiert. Der eigentliche Fehler ist doch, dass manche Leute keine vernünftigen Mails schreiben können (wollen?)
1 | From: noreply.bahncard-rechnung@bahn.de |
2 | Subject: Rechnung zu Ihrer BahnCard |
3 | |
4 | -webkit-box-shadow: 0px 4px 8px #828282; /*webkit browser */-moz-box-shadow: 0px 4px 8px |
5 | #828282; /*firefox */box-shadow: 0px 4px 8px #828282; line-height:1.15;width:468.300pt; |
6 | padding:0pt 42.000pt 0pt 85.000pt ; background-color: #FFFFFF; margin:auto.header{ padding
|
7 | [...] |
8 | BahnCard- |
9 | Service| www.bahn.de________________________________________________________________Interne- |
10 | tauftritt der Deutschen Bahn AG >> http://www.db.de| Sitz der Gesellschaft: Frankfurt am |
11 | MainRegistergericht: Frankfurt am Main, HRB 83173USt-IdNr.: DE 260656754Vorstand: Dr. |
12 | Michael Peterson (Vorsitz), Stefanie Berk, Wilken Bormann, Martin Jende, Anja |
13 | SchöllmannVorsitzender des Aufsichtsrates: Dr. Richard Lutz |
14 | |
15 | [BahnCard_Rechnung.pdf application/octet-stream (53312 bytes)] |
Bauform B. schrieb: > Wäre ein anderer Mail-Client evt. eine Option? Claws Mail z.B. dürfte > etwas weniger Angriffsfläche bieten, jedenfalls, wenn man nicht einfach > jedes Plugin installiert. Der TE fürchtet aber garnicht die Angriffsfläche seines Mailclients. Es ist genau umgekehrt: er fürchtet, dass ein beliebiges Programm die Mails, die in einem Mailverzeichnis liegen, liest oder kopiert um mit diesem Wissen social-engineering-Angriffe zu fahren. Weiter denkt er, auch root-Prozessen nicht trauen zu können. In der korrekten Konsequenz hieße dies aber dass er die gesamte Distribution nicht online nutzen darf, zumindest nicht für Webmail, Shopping, Banking. Selbst aus einem harmlosen Browserverlauf lassen sich genug Daten fürs Social Engineering gewinnen.
Ein T. schrieb: > Zumindest die mir bekannten Sicherheitsmodelle (SELinux, AppArmor, > RSBAC) unterbinden alles, was nicht explizit erlaubt worden ist. Das > bedeutet: Du würdest die Zugriffsberechtigungen jedes Executable auf dem > System korrekt konfigurieren müssen. Zwei Modelle bleiben: der Docker-Container und eine VM. Ein T. schrieb: > Hm, okay, machen wir es kurz:… Machen wir es kurz: das trägt zur Lösung der Frage kein Jota bei, also lassen wir das, auch wenn es die Lieblingsmasche all der Forenteilnehmer ist, die sowieso schon immer alles gewusst haben… Ein ganz passabler Schutz vor Hackern ist übrigens Artenvielfalt, wenn schon nicht der Betriebssystem, dann wenigstens der Umgebungen, in den gewisse Anwendungen laufen. Hacker haben eines gemeinsam: sie wollen Profi, ohne dafür arbeiten zu müssen – sie werden also ein speziell gehärtetes System nur angreifen, wenn es einen Riesenprofit verspricht. Für tumbe Massengaunereien also eher nicht…
G. K. schrieb: > Ich hatte ja schon mal die Verschlüsselung von Mails mit z.b. PGP in den > Raum geworfen um einen Teil der Angriffsmöglichkeiten zu erschweren. Das ist keine Lösung, denn es geht ja nicht nur um einen kleinen Kreis von Teilnehmern, sondern mein ganzes Mail-Umfeld durch Verschlüsselung abzuschirmen. Dazu müssen alle Beteiligten mitspielen und das ist völlig illusorisch.
Franko S. schrieb: > Aber wenn deine Malware über email reinkommt nützt das auch nix, > deine ganze Idee ist Schwachsinn im Quadrat. Danke für die Blumen. Es ist doch immer wieder ermunternd, Leute zu treffen, die jede Frage als Schwachsinn erkennen können, bevor die Sache auch nur formuliert ist. Das ist der Schlüssel zu Erfolg und Reichtum!
Joerg W. schrieb: > Ich mache es eigentlich umgekehrt, und zwar schränke ich den > "Zugriffsradius" von Mailprogramm und Browser (TB & FF) via Firejail > ein. Die Spur hatte ich als erste verfolgt – scheint mir nicht geeignet zu sein, weil die Jail-Verzeichnisse vom System her problemlos einsehbar sind und damit auch für irgend eine Malware, die z.B. durch ein Programm ins System geschleust wurde. Dafür gibt es ja praktisch unendlich viele Möglichkeiten und wenn sich so eine Sauerei nach dem Festsetzen mal einige Wochen ruhig verhält und dann erst loslegt, wird es wirklich schwer, den Urheber ausfindig zu machen.
Kilo S. schrieb: > Ein T. schrieb: >> Ich habe NICHT gesagt, daß die öffentlich zugänglichen Modelle das nicht >> könnten. > > OK, dann hätte ich gerne den Link zu einer, die man deiner Meinung nach > für solche SE Angriffe problemlos trainieren kann. Staune und lerne hier [1]. [1] https://www.tensorflow.org/text/tutorials/text_generation > Genauso wie zur Mithilfe beim finden von "Nicht öffentlichen" > Datenblattern, Du brauchst Hilfe bei einfachem BruteForce? > Und sollte das wirklich nur an den Trainingsdaten liegen, ich glaube > nicht wirklich daran, es wäre grob fahrlässig da nicht im > "verarbeitenden" Teil einen möglichst schwer zu "brechende" > "Grundmoral/Ethik" zu implementieren. Wie genau soll das funktionieren? Das kannst ja Du sicher erklären, oder? Im Übrigen warte ich auf Deinen ersten konstruktiven Beitrag zum Thema "Linux: nur einer Anwendung Zugriff auf ein verschlüsseltes Verzeichnis geben".
Moriz schrieb: > Ich rechne damit, dass die Saukerle ihre KI irgendwann so weit > perfektionieren, dass sie den Stil des Lockvogels perfekt nachmacht. > Deswegen möchte ich meine Mails für Trojaner u.Ä. unerreichbar machen. Einfach nach dem lesen löschen. Oder auch davor, ganz automatisch auf dem Server, wo die her kommen… Auch wenns ja schon gesagt wurde: wenn da erst mal jemand auf deinem System unterwegs ist, ist sowieso schon alles zu spät. Oliver
Moriz schrieb: > Ich möchte das Mailverzeichnis von Thunderbird gegen das System > abschotten, um zu verhindern, dass beliebige Prozesse (incl. root) auf > den Inhalt zugreifen können. Es haben ausnahmslos alle Bewerter dich negativ bewertet. Bedeutet, dass Andere gar nicht begeistert sind, das du den Zugriff auf deinem Eigentum anderen Programmen vorenthalten möchtest. Eventuell wäre eine Anfrage in einem qualifizierten Forum sinnvoller.
:
Bearbeitet durch User
Wenn es eins gibt, was ich niemals eine Gute Idee finde, wenn es um Sicherheit geht, dann ist es root einzuschränken. Wer root Zugriff hat, der kontrolliert das System. Deshalb sollte der Besitzer des Systems root zugriff haben. Denn der dem das System gehört, sollte vollen Zugriff darauf haben, und alles damit tun können, was er will. Statt also root einzuschränken, macht es mehr Sinn, den root Account zu schützen. Mein Threat-Model, wenn es um Root geht, ist, nur der Besitzer des Systems soll root zugriff haben. Andere Benutzer könnten kompromittiert sein. Nun, wie schützt man root davor? Erstmal muss man verhindern, dass jemand anderes Root werden kann. Was wenn jemand bei su, sudo, oder pkexec das Passwort abfängt? Also entweder weg mit su, sudo, systemd (machinectl) und pkexec, und/oder stark einschränken, so dass man nicht einfach so root werden kann. (Docker sollte man auch vermeiden, das ist nicht sicher, wenn ein User das verwenden kann) Aber was, wenn man dann doch Root braucht? Entweder direkt auf der Console als Root anmelden - das login Program läuft bereits als Root, und wird nicht von einem andern Nutzer gestartet - oder man dafür einen extra Benutzer an genau dafür an, dem man dann für sudo / pkexec die entsprechenden Berechtigungen gibt. Das DAC Berechtigungssystem unter Linux funktioniert eigentlich sehr gut. Man kann recht einfach einstellen, welche User auf welche Daten zugriff haben. Auf Servern lässt man darum verschiedene Anwendungen unter unterschiedlichen Usern laufen. Das Problem ist nur, auf dem Desktop laufen unterschiedliche Anwendungen unter dem selben User - naja, abgesehen von subuids bei User Namespacen, die man bei Containern verwenden kann. Wenn man 2 Sets an Benutzer und Gruppen haben könnte, eins für den User, und dann für die Anwendung, das wäre ideal, aber leider gibt's das noch nicht. Also bleiben nur LSMs. Ich muss mir die mal nochmal ansehen. Als ich die das letzte mal angesehen habe, war ich noch nicht so davon begeistert. Entweder sind sie zu kompliziert, oder nicht besonders flexibel... Aber vielleicht ist das ja mittlerweile besser geworden. Container namespaces jails sind recht nett und auch sehr nützlich, aber auch etwas unpraktisch. Noch eine Sache. Vergiss Disk Encryption wieder. Das hilft gegen Diebe und Beamte, aber nicht gegen Viren. Wenn man Daten verwendet, sind sie nicht mehr Verschlüsselt, sonst könnte man sie ja nicht verwenden.
Moriz schrieb: > Zwei Modelle bleiben: der Docker-Container und eine VM. Das sind natürlich die naheliegendsten Möglichkeiten, darum hatte ich Deine Frage so interpretiert, daß Du diese Wege nicht gehen wolltest. Eine VM ist natürlich ohnehin kein Problem, simpel aufzusetzen und zu pflegen. Mit einem Free-, Net- oder OpenBSD als Basis wärst Du IMHO wahrscheinlich auch exotisch genug, damit ein zufälliger Angreifer sich einfachere Ziele sucht. Dennoch lassen sich auch VM-Images natürlich auf dem Host mounten, insofern halte ich es immer noch für eine valide Frage, ob Du Dich vor versierten und womöglich gezielten Angriffen schützen willst, oder nur vor Skriptkiddies. Ein Container benötigt jedenfalls ein wenig mehr Aufwand, vor allem müssen ein paar Device-Nodes vom Host in Deinen Container gemountet werden. Beispiele für solche Setups -- wenngleich keines für Thunderbird -- findest Du im Git-Repo der wundervollen Jessica Frazelle [1]. Nichtsdestotrotz stellt sich dann die Frage nach der Persistierung Deiner Daten; das könnte natürlich ein Docker Volume sein, aber dann liegen Deine Daten wieder unverschlüsselt und vom Host aus erreichbar auf Deiner Festplatte. Möglicherweise ließe sich dabei jedoch eine Lösung mit VeraCrypt nutzen [2]. Eine weitere Option wäre es übrigens, Deinen Thunderbird mit unshare(1) in (mindestens) einem Mount Namespace zu starten, aber auch dann wären Deine Maildaten vom Host aus relativ leicht zu erreichen. Aber die wichtigsten Kernfragen sind, gegen welche Art von Angreifern Du Dich schützen möchtest -- und wieviel Aufwand und Einbuße an Komfort Du zu investieren bereit bist, um Dich gegen dieses "möglicherweise" zu verteidigen. Ach so, und chroot(8) gibt es natürlich auch noch, aber... am Ende gelten dabei dann dieselben Fragen nach der Persistierung und vermutlich wäre das auch nicht ganz so einfach aufzusetzen und zu pflegen. [1] https://github.com/jessfraz/dockerfiles [2] https://github.com/tomerh2001/veracrypt-mount
Daniel A. schrieb: > Das DAC Berechtigungssystem unter Linux > Also bleiben nur LSMs. Könntest du die Rätsel dieser Abkürzungen mal lüften?
DAC = Discretionary Access Control (Die üblichen Benutzer, Gruppen, und Dateiberechtigungen) MAC = Mandatory Access Control (wird unter Linux von LSMs umgesetzt) LSM = Linux Security Module ACL = Access Control List (z.B. wenn Dateien mehrere Benutzer und Gruppenberechtigungen haben)
:
Bearbeitet durch User
Ein T. schrieb: > Dennoch lassen sich auch VM-Images natürlich auf > dem Host mounten, insofern halte ich es immer noch für eine valide > Frage, ob Du Dich vor versierten und womöglich gezielten Angriffen > schützen willst, oder nur vor Skriptkiddies. Kommt darauf an, was du unter "Skriptkiddies" verstehst… Ich würde auch professionelle Betrüger dazu zählen, die irgend so ein Schatten-Abo für professionell erstellte Einbruchssoftware abgeschlossen haben, aber über kein tiefer gehendes Systm-Knowhow verfügen. Die halte ich für eine realistische Gefahr. > Eine weitere Option wäre es übrigens, Deinen Thunderbird mit unshare(1) > in (mindestens) einem Mount Namespace zu starten, aber auch dann wären > Deine Maildaten vom Host aus relativ leicht zu erreichen. Das gehört wohl auch zu dem Komplex Jail – muss ich mir mal näher ansehen… > Ach so, und chroot(8) gibt es natürlich auch noch, aber... Das ist die Grundlage für diese Jail-Geschichten. Die sind darauf ausgelegt, den eingesperrten Prozess am Ausbruch zu hindern, schottet seine Dateien aber nicht gegen das System ab. Für diese Jail-Sachen gibts das jailkit, mit dem sich einiges automatisieren lässt.
:
Bearbeitet durch User
Moriz schrieb: >> Ach so, und chroot(8) gibt es natürlich auch noch, aber... > > Das ist die Grundlage für diese Jail-Geschichten. Die sind darauf > ausgelegt, den eingesperrten Prozess am Ausbruch zu hindern, schottet > seine Dateien aber nicht gegen das System ab. Jails basieren in Linux in der regel auf Namespaces, und seccomp zum Einschränken der Syscalls. Chroot, sowie switch_root sind älter als Namespaces, werden aber oft mit Mount Namespacen verwendet. Neben Mount Namespacen gibt es noch diverse andere Namespaces (User, PID, Time, UTS, Network, Cgroups).
Ein T. schrieb: > Du brauchst Hilfe bei einfachem BruteForce? Och, etwas mehr Bandbreite für ne höhere Anzahl an requests wäre schön nicht übel. Ein T. schrieb: > Im Übrigen warte ich auf Deinen ersten konstruktiven Beitrag zum Thema > "Linux: nur einer Anwendung Zugriff auf ein verschlüsseltes Verzeichnis > geben". Ach.. OK für dich nochmal: Kilo S. schrieb: > Wie wäre es zu verhindern das du irgendeinen "Schädling" in dein system > rein lässt? Ist ja nicht so als wäre das "unmöglich". Trotzdem ist mir das zu Paranoid gedacht, theoretisch ist das Szenario legitim, praktisch wäre es möglich unter der Vorraussetzung er ist ein lohnendes Ziel. Aber der schiebt hier nen Klapperzahn weil "Ein Kumpel möglicherweise"... Ah ja, nutze nur Live Systeme zum abrufen der Mails und Speicher die auf einem sicheren (nur mit dem live System bearbeiteten) Stick. Und denk blooooooos nicht drüber nach das sogar deine Hardware (UEFI) möglicherweise auch kompromittierbar ist.
Ein T. schrieb: > Wie genau soll das funktionieren? Das kannst ja Du sicher erklären, > oder? In dem man dem ganzen die entsprechenden "Regeln/Gesetze" von Anfang an mit gibt. Die Grundidee gibt's ja schon sehr lange: https://de.m.wikipedia.org/wiki/Robotergesetze
:
Bearbeitet durch User
@Kilo S. (kilo_s) Könnt ihr Kindsköpfe nicht endlich eure albernen Streitereien wo anders fortsetzen?
Noch eine Anmerkung. Das was Dir vorschwebt ist letztendlich nur noch "Schadensbegrenzung". Statt dafür Energie aufzuwenden halte ich es für sinnvoller, dafür zu sorgen, dass es für einen "Einbrecher" möglichst schwer ist, ein Userkonto zu übernehmen und noch schwerer, Root zu werden. Und da sind Jails schon mal ein guter Ansatz. Und z.B. die /etc/sudoers auf das wirklich Allernotwendigste begrenzen.
Niklas G. schrieb: > Was genau hindert andere Programme daran auch auf die Datei zuzugreifen? > Verschlüsselte Dateisysteme bringen erstmal nichts, weil eben > grundsätzlich alle laufenden Programme Zugriff haben. Aber nur solche Programme die auf der betreffenden User Ebene laufen und bei div. Programmen auch nur dann, wenn dafür der Zugriff auf den Crypt Container erlaubt wurde. Alle anderen User incl. root können nicht auf diese Dateien zugreifen. Probiers aus, wennst es nicht glaubst. Da bekommst immer ein permission denied.
Joerg W. schrieb: > Noch eine Anmerkung. Das was Dir vorschwebt ist letztendlich nur noch > "Schadensbegrenzung". Statt dafür Energie aufzuwenden halte ich es für > sinnvoller, dafür zu sorgen, dass es für einen "Einbrecher" möglichst > schwer ist, ein Userkonto zu übernehmen und noch schwerer, Root zu > werden. Ja natürlich ist das Schadensbegrenzung und das ist unabhängig von Schutzmaßnahmen gegen einen Einbruch. Woher weiß man, dass man nicht schon eine Laus im Pelz hat? Und wieso soll man es so einer – wahrscheinlich – Standard-Laus von der Stange nicht weiter erschweren, an sensible Daten heran zu kommen?
Mit visudo kannst du gezielt festlegen, dass ein Benutzer unter Linux nur ein bestimmtes Kommando mit sudo ausführen darf – und sonst nichts. Hier ist ein Beispiel: Beispiel: Benutzer max darf nur /sbin/reboot mit sudo ausführen 1. Öffne die sudoers-Datei sicher mit: sudo visudo 2. Füge am Ende (oder besser in einem passenden Abschnitt) folgendes hinzu: max ALL=(ALL) NOPASSWD: /sbin/reboot Erklärung: max: der Benutzername ALL=(ALL): auf allen Hosts und als jeder Benutzer NOPASSWD: kein Passwort nötig (optional – weglassen, wenn Passwort verlangt werden soll) /sbin/reboot: exakt dieses Kommando darf ausgeführt werden
Moriz schrieb: > Ganz simpel: Ich will verhindern, dass irgend welche > wie auch immer aufgebaute Malware auf meinem System > an die EMails kommen kann. Anders formuliert: Du möchtest den heiligen Gral der Netzwerksicherheit, nämlich die eine einzige Maßnahme, die Dich zuverlässig gegen sämtliche -- auch zukünftige, heute noch unbekannte -- Bedrohungen schützt. Sicherheitsfritzen, deren berufliches tägliches Brot die Computersicherheit ist, verweisen immer wieder darauf, dass das ein untauglicher Ansatz ist. Kannst Du Dir -- außer Geldgier -- noch weitere, valide Gründe für deren Sicht vorstellen? > Hintergrund: einem Bekannten wurden möglicherweise seine > Mails gestohlen [...] Ahh. Es ist nicht sicher, DASS die Mails gestohlen wurden; es ist nicht klar, AUF WELCHEM WEG die Mails gestohlen wurden -- aber Du suchst eine TECHNISCHE Maßnahme, die Dich schützt. Super.
Moriz schrieb: > Woher weiß man, dass man nicht schon eine Laus im > Pelz hat? Woher weisst Du, dass Dein Internetprovider nicht sowieso von jeder Deiner Mails einen Durchschlag an die NSA schickt? Woher weisst Du, dass nicht der Provider Deiner Mail- partner genau dies tut?
Hippelhaxe schrieb: > Es ist nicht sicher, DASS die ... Wenn gestohlen, dann wären die Emails weg. Gestohlene Autos sind stehen ja auch nicht brav wie immer vor der Haustür. Das hätte der TO oder sein Bekannter garantiert gemerkt. Wenn kopiert, dann sind die Emails noch da. Das kann der TO und sein Bekannter nicht merken. Wenn ein crawler auf Schlüsselwortsuche durchging, dann sind die Emails noch da. Das kann der TO und sein Bekannter nicht merken. Wenn korrigiert auf correctness, dann sind die Emails noch da. Das könnte der TO und sein Bekannter vielleicht merken, wenn da die Texte geändert wurden. D.h. es finden sich keine Wörter mehr Master, Slave, Zigeuner, und ungegendertes mehr in Emails in seinem Postfach (Orwell 1984++). Wenn diese sich darüber beschweren sollten, wird beiden eine Wahrnehmungsstörung diagnostiziert und wandern bald in ein Erziehungszentrum. ;) Wenn ... (tbc)
Dieter D. schrieb: > Wenn gestohlen, dann wären die Emails weg. Selten, daß von Dir was vernünftiges kommt. Wirklich selten. Hier aber hast Du recht. Bis auf den letzten Absatz, der ist natürlich wieder Schwurbeldieter in Reinstform. Au weia.
Harald K. schrieb: > Bis auf den letzten Absatz, ... Dein Framing (Brunnen vergiften) ist den meisten hier bekannt. Aber es ist nicht mein Problem, dass Dir bei solchen Aussichten oder Gedanken die Nackenhaare hochstehen und kalter Schweiß ausbricht. Wenn Du suchst, findest Du auch einen ernsten Fachartikel dazu. Wer den gefunden haben sollte, kann bei interesse das in einem anderen Unterforum weiterdiskutieren.
Dieter D. schrieb: > Dein Framing (Brunnen vergiften) ist den meisten hier bekannt. Das ist nicht "mein Framing". Lass' einfach die Unterstellungen bleiben. Dieter D. schrieb: > Wenn Du suchst, findest Du auch einen ernsten Fachartikel dazu. Ja, das schreibt jeder Schwurbler. Du bist krank.
Joerg W. schrieb: > Noch eine Anmerkung. Das was Dir vorschwebt ist letztendlich nur noch > "Schadensbegrenzung". Fachleute sprechen in diesem Zusammenhang von "Multi-Layer Security" oder "Defense in Depth".
Angehängte Dateien:
-
security.png
26 KB
Es ist wohl wieder an der Zeit, den xkcd einzuwerfen. ;) https://xkcd.com/538
:
Bearbeitet durch User
(prx) A. K. schrieb: > Es ist wohl wieder an der Zeit, den xkcd einzuwerfen. ;) > https://xkcd.com/538 Auch gegen solche Angreifer gibt es Abwehrmöglichkeiten [1]. Davon abgesehen habe ich mich jetzt mal ein paar Minuten hingesetzt und etwas mit Docker und Docker-Compose gebaut, siehe Anhänge. [1] https://shorturl.at/7P8uZ
Dieter D. schrieb: > Hippelhaxe schrieb: >> Es ist nicht sicher, DASS die ... > > Wenn gestohlen, dann wären die Emails weg. Autist. Sachlich richtig -- aber komplett am Wesentlichen vorbei. In mehrlei Hinsicht...
(prx) A. K. schrieb: > Es ist wohl wieder an der Zeit, den xkcd einzuwerfen. ;) > https://xkcd.com/538 Und wie funktioniert das praktisch? Über das Remote attack by wrench protocol?
Hippelhaxe schrieb: > Über das Remote attack by wrench protocol? Etwa über NPP, dem Nigeria Prinzen Protokoll. Man bringt den Betreffenden dazu, das Gerät selbst zu öffnen, weil darin die versprochenen Millionen vergraben sind. Das Werkzeug nutzt dieser später in Eigenanwendung, wenn er kapiert hat, wie er sich verarschen liess. ;)
:
Bearbeitet durch User
(prx) A. K. schrieb: > Etwa über NPP, dem Nigeria Prinzen Protokoll. Geht heutzutage viel, viel einfacher: https://blog.fefe.de/?ts=96f596d6 (Hier insbesondere die beiden Updates ansehen)
Hippelhaxe schrieb: > Über das Remote attack by wrench protocol? Natürlich per rfc2549, IP over Avian Carriers with Quality of Service Siehe: https://www.rfc-editor.org/rfc/rfc2549
Harald K. schrieb: > (Hier insbesondere die beiden Updates ansehen) Beim letzten Update wird unter dem Link das Beispiel nicht mehr angezeigt. Anscheinend musste die "Anleitung" oder "Vorbild" aus Nachahmungsgründen entfernt werden.
Hippelhaxe schrieb: > Sachlich richtig -- aber... ... spitzfindig, wenn Du es genau wissen willst. Mittel um den Thread hoch zu holen. Bei einem von Deinen Posts vor meinem Post, hätte ich erwartet, dass eine bestimmte Person im Forum aktiv wird. Vermute diese hat es nur verschlafen.
Dieter D. schrieb: > Beim letzten Update wird unter dem Link das Beispiel nicht mehr > angezeigt. Nö, das ist noch da.
:
Bearbeitet durch User
Harald K. schrieb: > Nö, das ist noch da. Gerade den Link auch noch mal aufgerufen. Ja, die Seite geht. Vielleicht hielt der Server um halb neun mich für eine Gefahr beim Aufrufen der Seite?
@admin: Thread bitte dicht machen – hier kommt ja nur noch dummes Zeug.
Wer verschiedene Seiten kritischer Informatiker im Netz querliest, könnte auch wissen, dass im Lande solches Know How nicht wirklich gefördert wurde. Es gibt von IT-Sicherheitsfirmen Systeme, die genau das machen, was Moritz eigentlich sucht. Allerdings nutzen diese eine vom Betriebssystem für diese Zwecke spezielle Schnittstelle für direkte Zugriffe auf bestimmte Ressourcen. Das ist nur wenige Jahre her, wo diese Anwendungen zum sicheren remoten Arbeiten für Firmen angepriesen wurden. Bei bestimmter Hardware (Chipsätze) in privaten Geräten, hätten auch diese benutzt werden können.
Dieter D. schrieb: > kritischer Informatiker Ist das sowas wie "besorgte Bürger"? Frage für einen Freund. (Denn daß so jemand wie Herr von Leitner gemeint wird, halte ich hier für sehr, sehr unwahrscheinlich)
Ich tippe auf einen Immigranten, aus Sicht von Zypern.
:
Bearbeitet durch User
Harald K. schrieb: > Dieter D. schrieb: >> kritischer Informatiker > > Ist das sowas wie "besorgte Bürger"? Dieter meint bestimmt den frauenfeindlich schwurbelnden Informatiker, dem seine ahnungslosen Eltern ausgerechnet einen Frauennamen verpasst haben.
Harald K. schrieb: > Frage für einen Freund. Das steht nicht grundlos im Plural. Übrigens fefe wäre auch darunter, Informatiker aus dem ccc sind dabei auch nicht ausgelassen worden. Was schade ist, dass man halt nicht genügend Zeit hat alle zu lesen. Sporadisch kann man halt immer mal wieder hinschauen, die Texte überfliegen und nur eine Auswahl wirklich lesen. Lustig ist es dann halt nur, wenn man zufälligerweise einem Produktleiter einer Firma zu seinem IT-Sicherheitsproduktes erklären darf, warum sein Produkt im inneren so einen Workaround macht. ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.