[gelöst] NoExec in Homedirs

[TomL]

Moin @ all

Gestern abend habe ich auf einem anderen Kanal, quasi hinter den Kulissen, eine Idee bekommen oder wurde dazu inspiriert (was auch immer), auf die ich von alleine wohl nicht gekommen wäre.... die mir aber durchaus sinnvoll erscheint. Dabei gehts um das Thema der unbemerkten Infiltration des eigenen Rechners durch andere/fremde. Tatsache ist wohl, dass bei einer Online-Infiltration das Homedir eines Users ein primärer Weg ins System ist, in dem dort ein Schad-Code ausgeführt wird. Oder ums anders auszudrücken, das Problem ist der berechtigte User, der Schad-Code ausführen darf und das vielleicht unbemerkt durch einen falschen Click auch tut. Ich erinnere mich dabei an mein Beispiel, in dem mit einer einzigen Bashzeile und der Verwendung des 15-Min-Pwd-Keep ein Schad-Code sich vollständige root-Rechte verschaffen kann.

Jetzt habe ich mal ein wenig rumgebastelt und würde meine Lösung gerne mal zum Draufhauen anbieten.... ... ich habe jetzt allen Homedirs mit einer Service-Unit das Recht auf "execute" entzogen. Selbst root kann in den User-Homedirs jetzt keine Anwendung mehr starten. Der Starts meines Netzwerk-Tools als root sagt z.B.:

Code: Alles auswählen

root@thomaspc:/home/thomas/Downloads
# ./selnic
bash: ./selnic: Keine Berechtigung

Nach einigen Tests war mein erster Eindruck "Geil... das ist ja klasse". Bislang konnte ich keine negativen Aspekte feststellen, alles was funktionionen soll, tuts auch, nur eben in den Homedirs kann nichts mehr ausgeführt/gestartet werden.

Das ist meine Unit, also die erste laufende Version:

Code: Alles auswählen

/etc/systemd/system/noexec-home.service

Code: Alles auswählen

[Unit]
Description=thlu:noexec-home.service:   Disable execute-permissions
After=local-fs.target

[Service]
Type=oneshot
ExecStart=/bin/mount --bind /home /home
ExecStart=/bin/mount -o remount,noexec /home

[Install]
WantedBy=basic.target

Ich würde mich sehr über den einen oder anderen konstruktiven Kommentar oder Kritik oder Meinung freuen.

[MSfree]

ich habe jetzt allen Homedirs mit einer Service-Unit das Recht auf "execute" entzogen. Selbst root kann in den User-Homedirs jetzt keine Anwendung mehr starten.

Ich schlage dir folgenden Test vor, um das zu verifizieren:

Code: Alles auswählen

echo '#!/bin/bash
cd
find . -type f
' > test.script
/bin/bash test.script

[TomL]

Boar, msfree, du oller spielverderber... mit nur einem Schuss versenkt....

Schade, wäre ja wirklich zu schön gewesen.....

[MSfree]

mit nur einem Schuss versenkt....

Ich hatte es befürchtet.

Das Problem ist, daß zwar verhindert wird, als ausführbar gekennzeichnete Dateien direkt zu starten, der Umweg über eine Shell aber nicht abgefangen wird.

[uname]

Selbst wenn. Wie sieht es denn mit /tmp aus?

[breakthewall]

Also grundsätzlich ist es korrekt, dass man Volumes via noexec deutlich resistenter machen kann. Und da dieser Schutz quasi auf Low-Level-Ebene seitens des Dateisystems ansetzt, gilt das für alle Nutzer gleichermaßen, da die Verarbeitung der Nutzerrechte erst später abgearbeitet wird. Zuzüglich solltest auch noch nodev und nosuid hinzunehmen, was aber in der fstab eintragen kannst ganz ohne Systemd-Unit. Auch Volumes wie /tmp und ganz besonders /dev/shm, sollten mit diesen Mountoptionen eingehängt werden.

Und das dieser Schutz nun in dieser Situation unwirksam war, bedeutet jetzt nicht, dass hier etwas umgangen wurde. Denn noexec wirkt nur bei einer direkten Ausführung von Binaries und Shellscripten, während ein Shellscript das mittels einer Binary wie der Bash, die unter /bin liegt und ausgeführt werden darf, natürlich über die Bash interpretiert ausgeführt wird. Das ist ja in diesem Sinne keine direkte Ausführung mehr, und hat nichts mehr mit noexec am Hut. Würdest der Bash unter /bin nun das Execute-Bit entziehen, dann wäre das Shellscript natürlich nicht ausgeführt worden. Nur das wäre jetzt auch recht unpraktikabel, weshalb es mehr Sinn macht, sich einen zusätzlichen Nutzer anzulegen, dem via Konfiguration der Zugriff auf eine Login-Shell verwehrt wird. Doch auch das verhindert nicht, sich mittels anderem tty dennoch anmelden zu können. Und um das unmöglich zu machen, muss man natürlich verhindern, dass es tty1 bis tty7 überhaupt gibt, womit der Systemdienst dahinter anders konfiguriert werden muss. Nur ist das im Problemfall nicht gerade ideal, und letztlich könnte man den grafischen Desktop auch zum Absturz bringen, und landet dann in der Login-Shell im tty0, wo dann wieder etwas schädliches ausgeführt werden könnte. Inwieweit solche Szenarien nun realistisch sind, steht wieder auf einem anderen Blatt. Was man aber auch nicht vergessen sollte ist, dass es auch noch eine Dash gibt, und Perl und Python sind auch nicht gerade weniger bedrohlich. Man sieht also das man hier an vieles denken muss, um die ganzen potenziellen Angriffsvektoren abzustellen, womit ein Nutzer Zugriff nehmen könnte. Daher ist es umso wichtiger hier schon den Browser, als auch Systemdienste isoliert auszuführen.

[uname]

Sehr interessanter Vergleichsfall bei Windows 10:

https://www.heise.de/security/meldung/D ... 62158.html

[TomL]

Also grundsätzlich ist es korrekt, dass man Volumes via noexec deutlich resistenter machen kann.

Ich musste auch erst noch mal ne Runde spazierengehen und drüber nachdenken. Und ich habs jetzt testweise doch noch mal wieder aktiviert. Es verhindert zumindest, dass ein aus dem Web runtergeladenes Binary oder auch ein Script allein durch Click gestartet werden kann. Auf der regulären Position unter /usr/local/bin konnte ein Script vom Filemanager mit Mouse-Click schon immer problemlos gestartet werden, was ja auch ok ist, was jetzt aber im home-dir nicht mehr geht. Via Desktopstarter funktionierts auch nicht. Es ist kein vollkommener Schutz, aber doch wieder eine weitere Hürde, die den Anwender vielleicht vor seiner eigenen Fahrlässigkeit schützt.

Alle unsere Netzwerk-Mounts waren sowieso immer schon mit den Optionen "nosuid,nodev,noexec" gemountet. Ebenso alle weitere Platten, die irgendwie hinzugemountet werden, und natürlich auch alle USB-Sticks, die ausschließlich durch mein Script auto-gemountet werden. Von all diesen Datenträgern war noch nie der direkte Execute eines Binary oder Script möglich.

Dank Eurer Hinweise habe ich auch meiner Mount-Unit für /tmp, welches bei uns seit jeher nach /tmpfs gemountet ist, jetzt ebenfalls "nosuid,nodev,noexec" verpasst. Und in gleicher Rutsche via remount-Service-Unit auch für /dev/shm. Ich teste das jetzt erst mal 2-3 Tage auf meinem Rechner und wenn ich hier nix nachteiliges bemerke, werden diese neuen Units auf alle unsere Clientes ausgerollt. Ich halte diese Maßnahmen nun für eine weitere Verbesserung.... nichts mehr, aber auch nichts weniger...

Ein paar weitere Kommentare - gerne auch kritisch - sind willkommen ... ich denke, das kanns nur besser machen... so hat mich doch msfree's Blattschuss zumindest noch mal darüber grübeln lassen, ob das wirklich nur Schlangenöl ist oder obs vielleicht doch hilft.

[uname]

Ein Vorteil von GNU/Linux gegenüber Windows ist vielleicht auch noch, dass die gedownloadete Datei erst mal nicht ausführbar ist. Der Anwender muss also "gefahr.exe", "gefahr.sh" bzw. "gefahr" erst mal ausführbar machen. Daran scheitert vielleicht der eine oder andere Anwender bzw. es vergeht so viel Zeit, dass er sein Handeln noch mal überdenkt. In deinen Fall wird der Anwender per GUI die Rechte ändern können aber bei der Ausführung aufgrund von "noexec" scheitern. Den Umweg über die Bash kennt er vielleicht nicht.

[breakthewall]

Ein Vorteil von GNU/Linux gegenüber Windows ist vielleicht auch noch, dass die gedownloadete Datei erst mal nicht ausführbar ist. Der Anwender muss also "gefahr.exe", "gefahr.sh" bzw. "gefahr" erst mal ausführbar machen.

Das stimmt zwar weitgehend, doch das lässt sich mittels tar umgehen. Wenn man nun ein Shellscript mittels tar packt, welches ein Execute-Bit besitzt, dann wird das mit ins Archiv aufgenommen. Wird das Archiv nun andernorts wieder entpackt, dann wird auch das Execute-Bit gesetzt, womit das Shellscript sofort ausführbar wird. Dem könnte man jedoch mit einer veränderten umask entgegenwirken, wodurch jeder neu erstellen Datei das Execute-Bit genommen wird. Aber in der Praxis ist das eher lästig, wenn man mit ausführbaren Shellscripten arbeiten muss.

[NAB]

TomL, hast du dich mal näher mit SELinux beschäftigt? (Ich nämlich nicht)

Aber wenn ich das richtig sehe, müsstest du damit die andere Hälfte des Puzzels eingesetzt kriegen.

SELinux kann auf einzelne Prozesse oder Prozessgruppen aufpassen:
https://security.stackexchange.com/ques ... y-on-linux
Und es ist per Policy möglich, den Zugriff auf bestimmte Verzeichnisse zu sperren - auch abhängig vom Benutzer:
http://blog.siphos.be/2015/07/restricti ... -a-folder/

Damit müsste man /bin/bash verbieten können, Dateien aus /home zu lesen (und tmp und was sonst noch alles möglich ist). Und natürlich nicht nur bash sondern auch php, perl, java, exec(?) und allem, was sonst noch Code ausführen könnte. Das dürfte ein übles Gefrickel werden, und wenn man's gründlich vernageln will, musst du auch cat script.sh | bash - verbieten ... perfekt wird das also nie, aber etwas dichter.

[MSfree]

... den Zugriff auf bestimmte Verzeichnisse zu sperren

Das hilft gegen so etwas leider nicht:

Code: Alles auswählen

echo 'cd
find . -type f
' | /bin/bash 

musst du auch cat script.sh | bash - verbieten

Mein Beispiel oben kommt sogar komplett ohne eine Zwischendatei (script.sh) aus. Das Pipen von Befehlsketten in eine Shell zu verbieten, egal ob aus Datei oder über "echo", ist letztlich wenig zielführend. Mit einem dermassen vernagelten System raubst du dem Nutzer auch alle Möglichkeiten der skriptgesteuerten Datenverarbeitung. Gegen kriminelle Machenschaften nützen die bis jetzt vorgeschlagenen Maßnahmen jedenfalls gar nichts. Sie erschweren den Einbruch ins System in keinster Weise.

Von Aussagen wie "etwas dichter" halte ich gar nichts, das klingt so wie "etwas schwangerer". Solange ein Benutzer irgendwelche Programme ausführen darf, gibt es auch Mittel, etwas böses zu machen, und die professionellen Kriminellen kennen viel mehr Wege als wir uns hier mit unserem Bescheidenen Wissen vorstellen können. Ein System, auf dem man gar nichts mehr ausführen darf, ist zwar sicher, aber gleichzeitig auch völlig nutzlos.

[breakthewall]

TomL, hast du dich mal näher mit SELinux beschäftigt? (Ich nämlich nicht)

Ich hatte SELinux längere Zeit im Einsatz, aber würde aufgrund der Erfahrungen nicht dazu raten. Denn allein die Konfiguration ist eine Mammutaufgabe, und muss stets penibel gepflegt werden. Dazu kommt, dass ein winziger Konfigurationsfehler, der bei solch einer Komplexität schnell passieren kann, mitunter die Sicherheit gänzlich aufheben kann. Hier besteht einfach kein erträgliches Verhältnis, zwischen Aufwand und Sicherheit. Für mich hat sich das zumindest nicht gelohnt, da die Arbeit irgendwann nur noch lästig wird, wenn man sich zur Unkenntlichkeit einschränkt. In Sachen Sicherheit steht zwar ausser Frage, dass SELinux funktioniert, aber meiner Meinung nach lohnt sich das nicht. Es ist einfach nicht richtig, für mehr Sicherheit soviel aufgeben zu müssen, wo die Sicherheitsarchitektur dringend modernisiert werden muss. Und letztlich sind in diesem Bezug alle Betriebssysteme veraltet.

Und da sehe ich Sandboxing weit vorne, was ja letztlich anhand von Flatpak, Systemd und auch Wayland deutlich wird. Hier soll ja schon grundlegend angesetzt werden, dass Programme niemals ohne Isolation laufen, in erheblichem Maße hinsichtlich der Systemressourcen eingeschränkt werden, und ausschließlich nur noch eigene Dateien und Verzeichnisse sehen bzw. lesen können. Durch solche Sicherheitsmechanismen, wird vieles was bereits angesprochen wurde quasi obsolet, weil diese Lösungen aus guten Gründen kaum genutzt werden, und wahrscheinlich wird sich das niemals ändern. Auch wenn ich restriktive Mountoptionen als zusätzliche Schutzschicht, auch weiterhin sinnvoll finde. Generell kann Sicherheit nie auf nur einer Komponente basieren. Und was einfach nutzbar ist wird auch genutzt werden, was man unter anderem auch an Firejail sieht.

Leider sieht man sich bezüglich der Mehrheit aller Menschen, auch mit dem Problem konfrontiert, dass Sicherheitsfunktionen niemals optional sein dürfen, wenn sich das jemals verbreiten soll. Das beste Beispiel dafür wären Krypto-Messenger, die erst garnicht unverschlüsselt kommunizieren können. Doch an Telegram sieht man deutlich, wie geringfügig die optionalen Secret-Chats genutzt werden, weil sich zuviele nicht darum scheren. Und damit ist Telegram faktisch nicht zu gebrauchen, ebenso wie OpenPGP bezüglich E-Mails und vieles mehr. Darum muss es Lösungen wie Flatpaks oder auch UWP-Apps geben.

Interessant ist nebenbei auch, dass Redhat daran arbeitet, die Struktur regulärer Linux-Distributionen komplett zu verändern. Somit soll es im Bezug auf Fedora zukünftig so aussehen, dass das System in zwei Bereiche unterteilt wird, einmal mal in das Basissystem und einmal in einen Nutzerbereich, der nur noch aus Flatpaks bestehen soll. Das soll das grundlegende Konzept erheblich vereinfachen, wodurch auch Updates und Abhängigkeiten an Aufwand verlieren. Allerdings gab es dazu schon Gegenwehr, da so manche Distributionsmaintainer offenbar ihre Zukunft bedroht sehen.

[MSfree]

Somit soll es im Bezug auf Fedora zukünftig so aussehen, dass das System in zwei Bereiche unterteilt wird, einmal mal in das Basissystem und einmal in einen Nutzerbereich, der nur noch aus Flatpaks bestehen soll.

Oh bitte nicht!

Das bringt kein Fünkchen Sicherheit, verbraucht dafür aber Unmengen an Plattenplatz und Hauptspeicher, ist langsamer und viel zu komplex.

[TomL]

Von Aussagen wie "etwas dichter" halte ich gar nichts, das klingt so wie "etwas schwangerer".

Da bin ich jetzt nach weiterem Überlegen völlig anderer Meinung.... ganz einfach deshalb, weil es verschieden-akut vorhandene Bedrohungsszenarien und verschiedene Perspektiven auf die eigene private IT-Welt gibt. Und der Grad, wie akut Bedrohungen durch Attacken aufs eigene IT-System tatsächlich sind oder auch nur zu betrachten sind, steht auch immer in direkter Relation zur eigenen Bedeutungslosigkeit. Was heisst das...?... ganz einfach, das bedeutet, dass ich für wirklich akute Bedrohungsszenarien und tatsächliches fremdes Interesse speziell und gezielt an meiner kleinen digitalen Welt einfach zu bedeutungslos bin. Unsere Rechner könnten vielleicht zufällig Opfer von ungezielten Hackerattacken werden, von Malware, von Script-Kiddies, aber genau hierzu behaupte ich , dass unsere Systeme nicht einfach so als Mitnahmeeffekt weder von innen noch von außen gehackt werden können. Und ich behaupte, dass unsere Maßnahmen -jede einzelne für sich- jeweils eine kleine weitere Hürde sind, die das Kapern der Rechner erschweren. ... und sei es auch nur deshalb, weil gerade die Kenntnisse des Users an der Tastatur überfordert sind.

Und ja, das ist mir natürlich durchaus bewusst, wenn es wirklich jemals gezieltes Interesse an unseren Systemen oder Daten geben sollte, dann werde ich das wahrscheinlich sowieso nicht verhindern können, weil 'die' dann vermutlich einfach unsere Hardware mit physischen Zugriff direkt kompromittieren. Aber ich vermute mal, für so ein Interesse bin ich/sind wir schlichtweg zu bedeutungslos.

Ich habe aktuell die Überzeugung, dass der beste Schutz der ist, der in erster Linie den Anwender vor sich selber schützt. Bei uns gibts deshalb also keine 'berechtigten' Anwender, also im Sinne von erweiterten Privilegien. Alle weiteren getroffenen Maßnahmen sind auf Kapselung, eingeschränkten Wirkungsbereich, restriktive Rechte und Reglementierung des Traffics ausgerichtet. Ich sehe das ganze Thema (ich hoffe) pragmatisch und glaube, ein Schutz sollte auch in unserer kleinen privaten EDV ganz sicher nicht vernachlässigt werden und durchaus angemessen wirksam sein, aber Schutzmaßnahmen sollten sich nicht in einer sich ausdehnenden Paranoia-Spirale dynamisch verselbständigen. Dann läuft imho irgendwas mit der Psyche unsereins normalbürger verkehrt.....

Ich betrachte unsere IT i.ü.S. als ein Haus mit unverschlossenen und zum Teil sogar geöffneten Türen und Fenstern. Und bei solcher Betrachtungsweise bin ich mit den wirklich einfachen Maßnahmen zufrieden, bei Abwesenheit einfach die Fenster zu schließen, Kippstellungen zu schließen und alle Haustüren zuzuschließen. Ich brauche keine zusätzliche hohe Mauer ums Grundstück, keine teueren Überwachungs- und Alarmsysteme, keinen Krokodil-Graben, keine freilaufenden Döbermänner, keine bewaffneten Wachen. Andere bekannte OS sind da imho ähnlich zu betrachten... allerdings gibts für die aus Redmond einen sehr hohen kriminellen Druck im Ökosystem und dagegen positioniert entsprechende Abwehrprogramme. Für z.B. Clem's OS hingegen, welches sehr gerne die Seitenwechsler aus Redmond übernimmt, besteht (zu seinem Glück) weder akuter Druck, noch sind Abwehrprogramme etabliert... gerade das letztere ist imho derzeit ein offenes Haus ohne Schließmechanismen an Türen und Fenstern, welches nur durchs Gartentörchen (dem Router) von 'draußen' abgegrenzt ist.

Ich denke, ich habe unsere Debian-Installationen so ausgerichtet, dass sie die Anwender primär vor der eigenen Fahrlässigkeit schützen. Jetzt auch noch zusätzlich in /home, /tmp und /dev/shm das Ausführen von Programmen zu verhindern, ist einfach nur ein weiterer Schritt, der keinerlei Aufwand verursacht und trotzdem wieder ein kleines bisschen die Sicherheit verbessert. Ich finds falsch zu sagen, bei Verlassen des Hauses bringt es eh nix, ein Fenster auf Kippstellung zu schließen, weil Profis einfach die Terassentür eintreten. Natürlich hält das den dicken Stiefel mit Stahlkappe nicht ab, das geschlossene Fenster hält aber vielleicht die ab, die keine Profis sind und zu doof sind die Terassentür einzutreten und stattdessen versuchen, mit einem Draht das Fenster in Kippstellung ganz zu öffnen.

Ein System, auf dem man gar nichts mehr ausführen darf, ist zwar sicher, aber gleichzeitig auch völlig nutzlos.

Ja, das glaube ich auch. Bei uns sind derzeit 3 stabile "Verteidigungslininen" etabliert, mit denen ich unsere kleine EDV als sehr sicher erachte, die aber dennoch nicht die Bedienung zu einer frustrierenden Angelegeheit machen. 1. Der Router reglementiert allen von außen ankommenden Traffic. 2. IPtables und NFtables reglementieren allen von den Clients nach außen gehenden Traffic. 3. Sehr restriktive Rechtevergaben auf den Clients für alle User sowieso strenge Kapselung von Datenbereichen und Zugriffsmöglichkeiten im Netzwerk regelementieren den Umgang mit Daten. Bei uns hat kein User das Recht, Programme mit root-Rechten auszuführen, nicht mal ich selber.

Diesen jetzt zuletzt hinzugekommenen Punkt betrachte ich einfach nur als den kleinen Umbau eines bestimmten Fensters im Haus, dessen Kippstellung man jetzt auch zuschließen kann.... was faktisch für uns keinerlei zusätzlichen Aufwand bedeutet, aber dennoch durchaus ein Vorteil sein kann.

[NAB]

... den Zugriff auf bestimmte Verzeichnisse zu sperren

Das hilft gegen so etwas leider nicht:

Code: Alles auswählen

echo 'cd
find . -type f
' | /bin/bash 

musst du auch cat script.sh | bash - verbieten

Mein Beispiel oben kommt sogar komplett ohne eine Zwischendatei (script.sh) aus.

Stimmt. Und hat damit so gar nichts mit "Zugriff auf Verzeichnisse" zu tun. Und auch nicht mit TomLs "noexec".

Ich denke, dass schon das "noexec" so einiges bringt - das dürfte den durchschnittlichen Cryptotrojaner stoppen, die sind nämlich meistens in C geschrieben und seltenst in "Bash".

Auf der anderen Seite sind TomLs Überlegungen offensichtlich unausgereift ... er weiß selber nicht so genau, wie und gegen was er sich wie stark schützen will. Sein "Prove of Concept" - "Schaut, ich kann mein eigenes Script nicht mehr ausführen" wirkt nicht so richtig überzeugend. Und auf dein Beispiel bezogen - wenn der User "find" ausführen darf, ob nun mit Bash oder ... eh ... mit Bash, sieht das auch nicht so richtig bedrohlich aus. Aber ich verstehe, was du meinst ... und es stellt sich die Frage "wo kommt das Script her?". Bei TomLs Einleitungstext mit "unbemerkte Online-Infiltration" dachte ich mir zuerst "Okay, reißen wir mal JavaScript aus dem Browser raus". Dann ging's plötzlich um Bash ... nunja ...

Somit ist mein Hinweis auf SELinux auch nicht als Allheilmittel zu verstehen sondern nur als weiteres Puzzelstück für TomLs Experimente und Gedanken.

Von Aussagen wie "etwas dichter" halte ich gar nichts, das klingt so wie "etwas schwangerer".

Aus der Perspektive darfst du gar kein Computersystem mehr benutzen. Irgendwo sind die immer undicht. Spectre schon abgedichtet? Oh, verzeihung, neuerdings werden Sicherheitslücken ja eh nicht mehr gestopft sondern nur noch "gemildert".

Ich hatte SELinux längere Zeit im Einsatz, aber würde aufgrund der Erfahrungen nicht dazu raten. Denn allein die Konfiguration ist eine Mammutaufgabe, und muss stets penibel gepflegt werden.

Stimmt, den Eindruck hatte ich auch. Ein komplettes System mit SELinux-Policies abzusichern ist eine Mammutaufgabe. Da braucht es einen Anbieter, der einen guten Regelsatz mit ausliefert, wie Fedora. Aber auch die sind meineswissens primär darauf ausgelegt, das System gegen sich selber und gegen den User zu schützen. TomL will hier den User gegen sich selber schützen. Wieweit er da Neuland betritt, weiß ich nicht, aber ich finde den Ansatz interessant.

Interessant ist nebenbei auch, dass Redhat daran arbeitet, die Struktur regulärer Linux-Distributionen komplett zu verändern. Somit soll es im Bezug auf Fedora zukünftig so aussehen, dass das System in zwei Bereiche unterteilt wird, einmal mal in das Basissystem und einmal in einen Nutzerbereich, der nur noch aus Flatpaks bestehen soll.

Hier wirfst du Red Hat und Fedora durcheinander. Die beiden sind zwar eng verwandt, aber sich nicht immer einig. Aber um mal auf's Thema zurückzukommen: Mit flatpak kriegst du eine Sandbox gratis. Aber auch die scheint mir beim groben Überfliegen vorallem dazu gedacht, das System gegen den User zu schützen. Wieweit die auch taugt, einzelne User-Anwendungen gegeneinander abzuschotten, weiß ich mal wieder nicht.

[reox]

bzgl SELinux: Ist nicht apparmor genau aus dem Grund gebaut worden, dass es einfacher konfigurierbar ist? Vllt sollte man sich eher das ansehen als SELinux.

Ich persönlich würde noexec nicht im home dir aktivieren, da ich da viel zu viele Sachen kompiliere und teste

[TomL]

Ich denke, dass schon das "noexec" so einiges bringt - das dürfte den durchschnittlichen Cryptotrojaner stoppen, die sind nämlich meistens in C geschrieben und seltenst in "Bash".

Genau um solche Kandidaten geht es.

Auf der anderen Seite sind TomLs Überlegungen offensichtlich unausgereift ... er weiß selber nicht so genau, wie und gegen was er sich wie stark schützen will.

Das ist eine Interpretation, die so nichts mit unserer Realtiät zu tun hat und ohne Kenntnis aller anderen der bei uns getroffenen Maßnahmen eigentlich bedeutungslos ist.

Sein "Prove of Concept" - "Schaut, ich kann mein eigenes Script nicht mehr ausführen" wirkt nicht so richtig überzeugend.

Das sollte ja auch zu keiner Zeit überzeugend sein, zu dem Zeitpunkt habe ich noch von "dazu inspiriert" gesprochen und um Kritik gebeten... was msfree sehr schnell auch konkret getan hat.. und was mich dann dazu veranlasst hat, intensiv darüber nachzudenken. Meine Spaziergänge mit Hund bei diesem herrlichen Wetter sind dazu bestens geeignet. Die tiefergehende Bedeutung ist mir also erst viel später bewusst geworden, auch die Tatsache, dass msfrees Beispiel eine Sachkenntnis voraussetzt, die meine User nicht haben. Allerdings gebe ich zu, dass mein Beispiel zur Bestätigung wirklich dilettantisch war... was msfree ja schnell festgestellt hat. Aber wie gesagt, diese Kenntnisse hat hier keiner, die können alle nur klicken. Aber ich muss immer erst drüber nachdenken, um schließlich Wert oder Wertlos festzustellen.... aber wie gesagt, anfangs war erst mal nur eine Idee, ein Funke.

Bei TomLs Einleitungstext mit "unbemerkte Online-Infiltration" dachte ich mir zuerst "Okay, reißen wir mal JavaScript aus dem Browser raus". Dann ging's plötzlich um Bash ... nunja ...

Nein, hier ist kein Kontextwechsel angesagt... der Browser war nie ein Thema und es besteht hier für mich keinen Zweifel daran, dass der ziemlich scharf eingestellte UBlock-Origin solche Aktionen verhindert. Mit gings nach den mit dem Thema einhergehenden Überlegungen ausschließlich nur noch darum, einen Download in ~/Downloads nicht per Click via Filemanager starten zu können. Für alles andere fehlen hier die Sachkenntnisse... insofern war die Maßnahme ein voller Erfolg.

Somit ist mein Hinweis auf SELinux auch nicht als Allheilmittel zu verstehen sondern nur als weiteres Puzzelstück für TomLs Experimente und Gedanken.

Nee, ist es eher nicht... dazu würde der Absatz mit der Paranoia-Spirale in meinem vorherigen Posting passen. Ich werde keinen sich permanent ausdehnenden Aufwand für unser bedeutungsloses Netzwerk betreiben.

Ich halte es für unfachlich, sich allein auf diesen Miniaspekt in einem Gesamt-Konzept einzuschießen... und das Gesamt-Konzept ist hier gar nicht beschrieben. Dieser NoExec ist nur eine kleine und völlig unaufwendige Maßnahme, die sich nahtlos in ein schon bestehendes Gesamt-Konzept einfügt und unbedeutend ein klein wenig mehr die Sicherheit erhöht. Zum Beispiel dann, wenn meine Frau wieder mal von ihrer Facebook-Junkie-Freundin eine gutgemeinte Email mit einem Anhang zugesandt bekommt, der eine tolles Video enthält, welcher von seinem Datei-Charakter aber eine ausführbare Datei ist. Unter Windows wäre diese Exe dann durchaus ein Problem. Und wenns dann mal wirklich ein Linux-Binary wäre, könnte das jetzt nicht mehr mit einfachen Doppelklick gestartet werden. Wäre das dann sogar so eine Ransomware, könnte ich nun lächelnd sagen "ätschibätschie". Ich denke, das ist gut so.....

[TomL]

Ich persönlich würde noexec nicht im home dir aktivieren, da ich da viel zu viele Sachen kompiliere und teste

Das mach ich grundsätzlich nur in einer jeweils frischen systemd-nspawn-Umgebung in tempfs.... ich habe dafür ausreichend RAM. Und wenn ich X brauche, dann findet hinterher der Test in einer VM statt. Die Transfers geh'n einfach über Share-Dirs. Und wenn ich ausdrücklich eine eigene Hardware-Umgebung brauche, habe ich dafür einen Raspberry Pi als Test-Maschine. Mein eigener PC ist immer mehr und mehr nur noch ein Host für isolierte Sub-Systeme, wo ich den PC selber rigoros nach außen und vor Veränderungen abschirme und die installierte Software hinsichtlich der Anzahl der Programme seit Inbetriebnahme vor einem Jahr statisch ist.

[NAB]

Das ist eine Interpretation, die so nichts mit unserer Realtiät zu tun hat und ohne Kenntnis aller anderen der bei uns getroffenen Maßnahmen eigentlich bedeutungslos ist.

Völlig richtig! Ich bezog mich einzig auf den Thread hier, habe deine restlichen Threads und "Maßnahmen" nicht verfolgt und kann "eure Realität" überhaupt nicht beurteilen. Insofern: Nix für ungut

[breakthewall]

Ich denke, dass schon das "noexec" so einiges bringt - das dürfte den durchschnittlichen Cryptotrojaner stoppen, die sind nämlich meistens in C geschrieben und seltenst in "Bash".

Mit Python hätte man auch eine gute Basis für so eine Aufgabe. Zufälligerweise habe ich schon einmal einen Kryptotrojaner in Bash geschrieben, rein aus Interesse an der Sache. Und warum ausgerechnet in Bash ist einfach, zumal man sich mit der Kastration der Shell selbst sabotieren würde, weshalb die Shell-Variante nahezu immer funktionieren wird, wenn jemand naiv genug ist ihn auszuführen. Dagegen könnte eine Binary via noexec, leicht unschädlich gemacht werden.

bzgl SELinux: Ist nicht apparmor genau aus dem Grund gebaut worden, dass es einfacher konfigurierbar ist? Vllt sollte man sich eher das ansehen als SELinux.

Ich persönlich würde noexec nicht im home dir aktivieren, da ich da viel zu viele Sachen kompiliere und teste

Hier wäre AppArmor in der Tat einfacher, aber auch deutlich weniger wirksam als SELinux. Insbesondere die Konfiguration von AppArmor, ist sehr leicht verständlich, was auch Konfigurationsfehlern vorbeugt. An sich muss man /home nicht via noexec mounten. Und genau genommen stellt sich auch die Frage, inwieweit es überhaupt Sinn macht, die Shell an der Ausführung zu hindern. Ich meine es reicht doch schon, wenn Dateien oder Verzeichnisse via chattr geschützt werden, dann könnte sich hier ein Kryptotrojaner dumm und dämlich ackern, wenn die Originale schlicht nicht löschbar sind bzw. nicht manipuliert werden können. Und auf den restlichen Verzeichnisbaum besteht ohnehin kein Zugriff. Alternativ könnte man auch garnichts von Wert unter /home speichern, dann sieht die Angriffsfläche auch wieder anders aus. Doch zumindest aus eigener Sicht, ist mir jene Variante lieber, präventiv zu verhindern, dass überhaupt irgendetwas auf das System kommt. Und da ist wiederum ein abgesicherter Browser gefragt.

[Lohengrin]

Mit gings nach den mit dem Thema einhergehenden Überlegungen ausschließlich nur noch darum, einen Download in ~/Downloads nicht per Click via Filemanager starten zu können.

Kann man das dem Filemanager beibiegen?
Das Problem sitzt, wie so oft, vor dem Bildschirm. Der Benutzer will, dass auf Klick etwas passiert, und was das ist, überlässt er der Automatik, die das hoffentlich richtig errät. Und dann hat er das Schadprogramm gestartet.

Ein Versuch, das Problem zu beheben, ist, den Benutzer "Soll ich das Programm ausführen?" zu fragen. Aber die Erfahrung lehrt, dass man ebensogut "Willst du, dass dieses Fenster verschwindet?" fragen kann.

Wenn schon durch Klicken auf ein Icon, das durch das Abspeichern der Datei entstanden ist, ein Programm mit der Datei als Argument ausgeführt wird, oder eben diese Datei als Programm ausgeführt wird, dann wäre es gut, wenn das Icon auf das Programm schließen lässt, oder besagt, dass diese Datei ein Programm ist, das ausgeführt werden soll. Insbesondere darf dann die Datei nicht das Icon festlegen.
Das ist mMn ein böser Fehler im Konzept des Desktops, der schon damit beginnt, dass Verzeichnisse Ordner heißen und Dateien geöffnet werden.

[breakthewall]

Kann man das dem Filemanager beibiegen?

Das hatte ich völlig ausser Acht gelassen. Zumindest Nautilus unter Gnome, führt standardmäßig nichts aus, und öffnet ausführbare Dateien nur im Texteditor. Das muss in den Einstellungen schon explizit eingestellt werden, wenn sich Nautilus anders verhalten soll. Zu den anderen Dateimanagern kann ich aktuell nichts sagen, da diese lange nicht mehr verwendet wurden.

[smutbert]

Genau dasselbe wollte ich auch gerade schreiben, aber es stimmt nicht ganz: Die Einstellung bezieht sich nur auf Textdateien. Bei mir steht sie auf "Anzeigen" (im Gegensatz zu Nachfragen und Ausführen), aber das avidemux appImage wird beim Doppelklick (leider) ausgeführt.

[TomL]

@smutbert & breakthewall

Ihr sprecht aber jetzt vom normalen Verhalten des Filemanagers...?.... ohne Berücksichtigung des Umstands, das ich das Verzeichnis mit noexec gemountet habe? Nach meinem Verständnis sollte damit (egal welcher) kein einziger FM (egal mit welcher Einstellung) ein Binary mit simplem Doppelklick starten dürfen. Oder ist das doch noch wieder anders, je nach FM?