Apple wieder mal Vorreiter

[/mecki78]

Nicht nur, dass Apple mit 10.7 (Lion, 2011) App Sandboxen im System eingeführt hat und seither Apps, die aus dem App Store kommen in einer Sandbox laufen müssen (Apps aus anderen Quellen dürfen, müssen aber nicht in einer laufen), seit 10.11 (El Capitan, 2015) hat Apple SIP eingeführt (System Integrity Protection) und das Basissystem zu einem monolithischen Block gemacht, der zur Laufzeit nicht verändert werden kann (auch nicht vom root Nutzer), sondern nur durch ein Systemupdate, welches nur direkt nach einem Neustart eingespielt werden kann (und nur dann, wenn es korrekt von Apple signiert wurde).

Seit 10.13 (High Sierra, 2017) nutzt Apple auch APFS als Dateisystem und hier liegt das Basissystem sogar auf einem eigenen Read-Only Volume (vorher wurde SIP nur über Zugriffsbeschränkungen im Kernel umgesetzt) und ist somit sogar noch stärker vom restlichen System abgekoppelt. Während bei HFS Volume und Partition das gleiche sind, beschreibt bei APFS Partition den physischen Speicherplatz und Volumes sind so etwas wie logische Partitionen innerhalb der physischen Partition. Mit APFS besteht macOS aus einer physischen Partition, die aber in verschiedene Volumes unterteilt ist und eines davon beinhaltet das komplett Basissystem und ist schon auf APFS Ebene unveränderbar, sobald das System einmal gebootet wurde. So muss der Kernel nur noch das überwachen und nicht mehr den Zugriff auf einzelnen Dateien/Verzeichnisse unterbinden, so wie das bei HFS noch der Fall war (weil da lag alles auf einem einzigen Volume).

Jetzt müsste Linux nur dazu übergehen auch Code zu signieren und standardmäßig unsignierten Code nicht mehr auszuführen (zumindest nicht ohne explizite Ausnahmeregel), denn das hatte Apple mit 10.9 (Mavericks, 2013) schon eingeführt und stellt für Angreifer eine weitere hohe Hürde da (nicht unüberwindbar, aber macht Malware schon das Leben schwer).

Was genau davon kann eigentlich Windows mittlerweile? Ich glaube nicht viel, ansonsten kann ich mir nicht erklären, wie kleinste Einfallstore immer derart gravierende Auswirkungen haben können.

/Mecki

[MarcusK]

/mecki78 schrieb:
--------------------------------------------------------------------------------
> Nicht nur, dass Apple mit 10.7 (Lion, 2011) App Sandboxen im System
> eingeführt hat und seither Apps, die aus dem App Store kommen in einer
> Sandbox laufen müssen (Apps aus anderen Quellen dürfen, müssen aber nicht
> in einer laufen), seit 10.11 (El Capitan, 2015) hat Apple SIP eingeführt
> (System Integrity Protection) und das Basissystem zu einem monolithischen
> Block gemacht, der zur Laufzeit nicht verändert werden kann (auch nicht vom
> root Nutzer), sondern nur durch ein Systemupdate, welches nur direkt nach
> einem Neustart eingespielt werden kann (und nur dann, wenn es korrekt von
> Apple signiert wurde).
>
> Seit 10.13 (High Sierra, 2017) nutzt Apple auch APFS als Dateisystem und
> hier liegt das Basissystem sogar auf einem eigenen Read-Only Volume (vorher
> wurde SIP nur über Zugriffsbeschränkungen im Kernel umgesetzt) und ist
> somit sogar noch stärker vom restlichen System abgekoppelt. Während bei HFS
> Volume und Partition das gleiche sind, beschreibt bei APFS Partition den
> physischen Speicherplatz und Volumes sind so etwas wie logische Partitionen
> innerhalb der physischen Partition. Mit APFS besteht macOS aus einer
> physischen Partition, die aber in verschiedene Volumes unterteilt ist und
> eines davon beinhaltet das komplett Basissystem und ist schon auf APFS
> Ebene unveränderbar, sobald das System einmal gebootet wurde. So muss der
> Kernel nur noch das überwachen und nicht mehr den Zugriff auf einzelnen
> Dateien/Verzeichnisse unterbinden, so wie das bei HFS noch der Fall war
> (weil da lag alles auf einem einzigen Volume).
>
> Jetzt müsste Linux nur dazu übergehen auch Code zu signieren und
> standardmäßig unsignierten Code nicht mehr auszuführen (zumindest nicht
> ohne explizite Ausnahmeregel), denn das hatte Apple mit 10.9 (Mavericks,
> 2013) schon eingeführt und stellt für Angreifer eine weitere hohe Hürde da
> (nicht unüberwindbar, aber macht Malware schon das Leben schwer).
>
> Was genau davon kann eigentlich Windows mittlerweile?
der Kern von Windows läuft schon lange als Read-Only-Image.

> Ich glaube nicht
> viel, ansonsten kann ich mir nicht erklären, wie kleinste Einfallstore
> immer derart gravierende Auswirkungen haben können.
Windows kann eine Menge, die Linux erst mit SE-Linux lernen musste. Windows kann auf sämtliche Objekte und Konfigs ACL vergeben, nicht nur User und Gruppen.

[/mecki78]

MarcusK schrieb:
--------------------------------------------------------------------------------
> Windows kann eine Menge, die Linux erst mit SE-Linux lernen musste. Windows
> kann auf sämtliche Objekte und Konfigs ACL vergeben, nicht nur User und
> Gruppen.

Und warum schützen die dann nicht niemanden, wenn ein Excel Makro per Exchange kommt, ausgeführt wird und dann Ransomware installiert, die das ganze System verschlüsselt? Nichts davon sollte dann eigentlich möglich sein. Ein ACL System, dass standardmäßig jedem alles erlaubt ist halt auch komplett nutzlos, das ist wie Banktresore, deren Türen 24/7 offen stehen und Alarmanlagen, die immer aus sind.

/Mecki

[MarcusK]

/mecki78 schrieb:
--------------------------------------------------------------------------------
> MarcusK schrieb:
> ---------------------------------------------------------------------------
> -----
> > Windows kann eine Menge, die Linux erst mit SE-Linux lernen musste.
> Windows
> > kann auf sämtliche Objekte und Konfigs ACL vergeben, nicht nur User und
> > Gruppen.
>
> Und warum schützen die dann nicht niemanden, wenn ein Excel Makro per
> Exchange kommt, ausgeführt wird und dann Ransomware installiert, die das
> ganze System verschlüsselt?

weil der Anwender zugriff auf seinen "eigenen Dateien" hat. Das wirklich das Windows infiziert wird geht wirklich nicht mehr so einfach. Auch bei Linux kann ein Script daten im User-Verzeichnis verschlüsseln.

[JackyChun]

Das ist einfach zu beantworten. Wenn eine Bank sich entscheidet die Tresortür offen stehen zu lassen, kann der Tresor noch so viele (Schutz)Funktionen haben, der Einbrecher läuft rein, läuft raus und ist reich.

Mac OS ist leider auch kein sicheres System, es ist einfach eine Nische, darum gibt es dafür kaum Massenschädlinge sondern eher zielgerichtete Angriffe von denen wir in der Presse nichts/wenig hören.

Live with an open mind, or die with your mouth shut.

[Zoigl]

/mecki78 schrieb:
--------------------------------------------------------------------------------

> Was genau davon kann eigentlich Windows mittlerweile?

So gut wie nichts natürlich. Dieses OS bekommt ja jetzt erst out-of-the-box Unterstützung zum Auspacken gebräuchlicher Archive.

Was Du noch bei macOS vergessen hast: schon seit immer™ (NextStep-Zeiten) gibt es Fat-Binaries mit Code für mehrere Architekturen in einer Lib/Executable. Als hätte damals schon jemand geahnt, daß sowas mal wichtig wird. Solche Trauerspiele wie /lib vs. /lib64 wie unter Linux blieben damit erspart.

Ebenso: seit ewig™ (wieder NextStep-Zeiten) gibt es App-Bundles für einfache Installation/Deinstallation von Programmen. Das ist der feuchte Traum, den Snap/Flatpack/AppImage gerade mehr oder weniger erfolglos versuchen nachzuahmen. Das Geheimnis ist dabei natürlich, daß das OS ein fest definiertes und umfangreiches Set von APIs bereit stellt, deren Libs dann gar nicht erst in den Bundles enthalten sein müssen, was diese dann schlank hält. Sowas widerspricht natürlich der Wahlfreiheit unter Linux, weshalb es da wohl nie befriedigende Lösungen geben wird.



2 mal bearbeitet, zuletzt am 01.06.23 22:27 durch Zoigl.

[dododo]

Zoigl schrieb:
--------------------------------------------------------------------------------
> Ebenso: seit ewig™ (wieder NextStep-Zeiten) gibt es App-Bundles für
> einfache Installation/Deinstallation von Programmen. Das ist der feuchte
> Traum, den Snap/Flatpack/AppImage gerade mehr oder weniger erfolglos
> versuchen nachzuahmen. Das Geheimnis ist dabei natürlich, daß das OS ein
> fest definiertes und umfangreiches Set von APIs bereit stellt, deren Libs
> dann gar nicht erst in den Bundles enthalten sein müssen, was diese dann
> schlank hält. Sowas widerspricht natürlich der Wahlfreiheit unter Linux,
> weshalb es da wohl nie befriedigende Lösungen geben wird.

Wobei ich hier sagen muss, da finde ich den Weg von Flatpak eigentlich ganz gut, hier definieren Anwendungen ja immer eine Runtime als Basis (meist KDE oder GNOME) die dann über alle Anwendungen mit gleicher Runtime geteilt wird. Das erlaubt auch mehrere Versionen der gleichen Runtime (etwa GNOME3 und GNOME40), welche aber jeweils nur einmal installiert wird. So bleiben die eigentlichen Anwendungscontainer auch klein. Letztlich ähnlich wie du es für macOS beschreibst nur flexibler, da man die Wahl aus mehreren Runtimes hat.

[shekhinah]

/mecki78 schrieb:
--------------------------------------------------------------------------------
> Nicht nur, dass Apple mit 10.7 (Lion, 2011) App Sandboxen im System
> eingeführt hat und seither Apps, die aus dem App Store kommen in einer
> Sandbox laufen müssen (Apps aus anderen Quellen dürfen, müssen aber nicht
> in einer laufen), seit 10.11 (El Capitan, 2015) hat Apple SIP eingeführt
> (System Integrity Protection) und das Basissystem zu einem monolithischen
> Block gemacht, der zur Laufzeit nicht verändert werden kann (auch nicht vom
> root Nutzer), sondern nur durch ein Systemupdate, welches nur direkt nach
> einem Neustart eingespielt werden kann (und nur dann, wenn es korrekt von
> Apple signiert wurde).
>
> Seit 10.13 (High Sierra, 2017) nutzt Apple auch APFS als Dateisystem und
> hier liegt das Basissystem sogar auf einem eigenen Read-Only Volume (vorher
> wurde SIP nur über Zugriffsbeschränkungen im Kernel umgesetzt) und ist
> somit sogar noch stärker vom restlichen System abgekoppelt. Während bei HFS
> Volume und Partition das gleiche sind, beschreibt bei APFS Partition den
> physischen Speicherplatz und Volumes sind so etwas wie logische Partitionen
> innerhalb der physischen Partition. Mit APFS besteht macOS aus einer
> physischen Partition, die aber in verschiedene Volumes unterteilt ist und
> eines davon beinhaltet das komplett Basissystem und ist schon auf APFS
> Ebene unveränderbar, sobald das System einmal gebootet wurde. So muss der
> Kernel nur noch das überwachen und nicht mehr den Zugriff auf einzelnen
> Dateien/Verzeichnisse unterbinden, so wie das bei HFS noch der Fall war
> (weil da lag alles auf einem einzigen Volume).
>
> Jetzt müsste Linux nur dazu übergehen auch Code zu signieren und
> standardmäßig unsignierten Code nicht mehr auszuführen (zumindest nicht
> ohne explizite Ausnahmeregel), denn das hatte Apple mit 10.9 (Mavericks,
> 2013) schon eingeführt und stellt für Angreifer eine weitere hohe Hürde da
> (nicht unüberwindbar, aber macht Malware schon das Leben schwer).
>
> Was genau davon kann eigentlich Windows mittlerweile? Ich glaube nicht
> viel, ansonsten kann ich mir nicht erklären, wie kleinste Einfallstore
> immer derart gravierende Auswirkungen haben können.

NixOS existiert seit 2003

[KlugKacka]

/mecki78 schrieb:
--------------------------------------------------------------------------------
> Nicht nur, dass Apple mit 10.7 (Lion, 2011) App Sandboxen im System
> eingeführt hat und seither Apps, die aus dem App Store kommen in einer
> Sandbox laufen müssen

Ach ja?
Die haben nur wieder Kopiert.
https://en.wikipedia.org/wiki/FreeBSD_jail
Und das hat sogar 12 Jahre gedauert.
Apple kann nichts ausser Kopieren, verklagen und die User bezirzen.

[wasdeeh]

/mecki78 schrieb:
--------------------------------------------------------------------------------

> Was genau davon kann eigentlich Windows mittlerweile?

Nachdem du ja so selbstbewußt und wortreich die Vorreiterschaft Apples in den Raum gestellt hast, hast du dich doch sicher auch vergleichbar mit den Alternativen auseinander gesetzt, um deinen Ausführungen ein Mindestmaß an Fundierung zu geben, oder? Oder?
(Ist natürlich rhetorisch gefragt - offensichtlich hast du das nämlich nicht...)

[qwertzuiop_98]

Seit ich Ubuntu nutze, (2021) schätze ich macOS mehr Wert.

[lunarix]

KlugKacka schrieb:
--------------------------------------------------------------------------------
> /mecki78 schrieb:
> ---------------------------------------------------------------------------
> -----
> > Nicht nur, dass Apple mit 10.7 (Lion, 2011) App Sandboxen im System
> > eingeführt hat und seither Apps, die aus dem App Store kommen in einer
> > Sandbox laufen müssen
>
> Ach ja?
> Die haben nur wieder Kopiert.
> en.wikipedia.org
> Und das hat sogar 12 Jahre gedauert.
> Apple kann nichts ausser Kopieren, verklagen und die User bezirzen.

Bei Dir ist der Name auch Programm oder?

https://opensource.apple.com/projects/

[leonardo-nav]

> Jetzt müsste Linux nur dazu übergehen auch Code zu signieren und standardmäßig unsignierten Code nicht mehr auszuführen (zumindest nicht ohne explizite Ausnahmeregel), denn das hatte Apple mit 10.9 (Mavericks, 2013) schon eingeführt und stellt für Angreifer eine weitere hohe Hürde da (nicht unüberwindbar, aber macht Malware schon das Leben schwer).

Naja. Da sind wa wieder beim klassischen "für wen ist das eigentlich".

Linux ist sehr, sehr groß im Vergleich zu Apples oder Microsofts Betriebssystemen. Damit meine ich nicht die Zahl der User, sondern die Möglichkeit der Anpassung. Erfahrene Nutzer lehnen solcherlei Gebahren häufig ab, weil sie selbst die Kontrolle haben wollen.

Unter Arch/Pacman kann man sich Quellen hinzufügen, wie man das für richtig hält. Standardmäßig sind das nur ständig überprüfte und signierte Quellen von Arch selber, aber man kann hinzufügen, was man für richtig hält. Das ist der Unterschied: Wenn man das will, kann man in einem extrem anpassbaren OS extrem sicherheitsbewusst vorgehen. Man kann's aber auch lassen.

Gerade das macht Linux für Angreifer aber auch gerne sehr unattraktiv. Der Angreifer hat bei nem Gentoo oder Debian keine Ahnung, was für ein System er eigentlich gerade versucht, anzugreifen, schließlich kann der Admin das System bauen, wie er's für richtig hält. Zudem gibt es über etwaige Sicherheitslücken vollständige Transparenz - sodass sie praktisch sofort geschlossen werden.

Und gerade das macht ein Windows oder Android so angreifbar: Alles genau dieselbe Basis, alles gleich konfiguriert. Die Lösung der Konzerne ist, den Nutzer von der Basis des OS noch weiter auszuschließen. Auch Ubuntu will einen solchen Weg gehen. Kann auch sinnvoll sein, da will ich gar nicht urteilen. Die meisten Linux Distros aber gehen den Weg in die exakt gegenteilige Richtung. Wenn der Nutzer sein OS unsicher konfigurieren will, dann darf er das bei den meisten Linux-Distros auch.

[smurfy]

/mecki78 schrieb:
--------------------------------------------------------------------------------
> Jetzt müsste Linux nur dazu übergehen auch Code zu signieren und
> standardmäßig unsignierten Code nicht mehr auszuführen (zumindest nicht
> ohne explizite Ausnahmeregel), denn das hatte Apple mit 10.9 (Mavericks,
> 2013) schon eingeführt und stellt für Angreifer eine weitere hohe Hürde da
> (nicht unüberwindbar, aber macht Malware schon das Leben schwer).

Ist auch nicht so das Allheilmittel, auch wenn es ähnlich wie ein Antivirensystem zumindest einen kleinen Beitrag zum Schutz leisten mag.

https://blog.fefe.de/?ts=9f8f9fbd
https://blog.fefe.de/?ts=9d77f2b4

[bernstein]

MarcusK schrieb:
--------------------------------------------------------------------------------
> der Kern von Windows läuft schon lange als Read-Only-Image.
Sag das mal meinem Windows 11 bei dem ich gewisse Dateien manipuliert habe. Man muss einzig den Systemdateiüberwachungsprozess überlisten dann markt Windows 11 nix von der Manipulation.

> Windows kann eine Menge
Stimmt sogar am meisten von allen Betriebssystemen. Das es trotzdem extrem Malwareverseucht ist liegt am grottenschlechten Uraltdesign und antrainiertem Nutzerverhalten.

> Windows kann auf sämtliche Objekte und Konfigs ACL vergeben, nicht nur User und Gruppen.
Linux demonstriert seit Jahrzehnten vom kleinsten ARM-Router bis zum Supercomputer dass ACLs eigentlich nicht notwendig ist. Liegt aber auch daran, dass kaum ein nicht Informatiker/Sysadmin Linux nutzt.