Tach zusammen,
wir haben uns mit ein paar Freunden überlegt, uns eine online-IDE zur
Pythonentwicklung einzurichten, da wir häufig an verschiedenen
Standorten und auf wechselnden Computern unsere Projekte bearbeiten.
Vorhandene Anbieter lehnen wir ab, da keiner ausreichend auf die
Sicherheitsaspekte eingeht, die ich unten anspreche. Auch wir werden
bald Freunde von Freunden, deren Freunde, usw. usf. zum Mitmachen
einladen, so dass wir auch damit rechnen müssen, dass nicht jeder Nutzer
nur gute Absichten hat.
Trotz aller Versuche, die Pythonfunktionalität einzuschränken
("restricted python"), damit ein Benutzer nicht beliebigen Code
ausführen kann, existiert bis heute keine brauchbare Lösung, die
produktiv einsetzbar ist und trotzdem Exploits wirksam verhindert. Wir
gehen also davon aus, dass ein Nutzer der Python-IDE beliebigen
Maschinencode einschleusen kann und damit auch Root-Rechte auf dem
Server erlangen kann.
Das wäre zwar an sich der GAU, doch wir werden jede Instanz der IDE in
einer Virtuellen Maschine laufen lassen, womit wir den Sicherheitsaspekt
auf die Unmöglichkeit des Ausbruchs aus einer VM verschoben hätten.
Welche Lösungen gelten als ausbruchssicher? VMWare? Virtualbox? Docker?
LXC? Solange Nutzer sich nur innerhalb der VM austoben können, haben wir
kein Problem. Es darf jedoch nicht passieren, dass sie auf das
Filesystem des Hosts zugreifen können oder unkontrollierten
Netzwerkverkehr starten.
Wie lösen vorhandene Anbieter (cloud9, pythonfiddle, repl.it, ...)
dieses Problem?
Ist es möglich, sofort zu erkennen, wenn der Python-Interpreter über
irgendwelche Umwege Root-Rechte erlangt? Dann könnten wir dessen VM
sofort abschalten und den Benutzer blockieren.
Sollte sich keine Lösung finden, können wir die Online-IDE immer noch im
kleinen (vertrauenswürdigen) Entwicklerkreis einrichten. Doch hätte dies
den gravierenden Nachteil, dass wir nicht mal eben weitere Entwickler
involvieren könnten, ohne die Sicherheit zu gefährden.
Danke, dass Du bis hierher durchgehalten hast. Wir hoffen auf eine
lebendige und zielführende Diskussion.
Hagen
Hagen schrieb:> eine online-IDE zur> Pythonentwicklung einzurichten, da wir häufig an verschiedenen> Standorten und auf wechselnden Computern unsere Projekte bearbeiten.
Wie wärs mit Versionskontrolle stattdessen und lokal installierter IDE?
Bis ihr ne online IDE aus dem Boden gestampft habt die an ein lokal
installiertes PyDev auch nur ansatzweise herankommt vergehen doch Jahre.
Und dann ist es immer noch nur eine Online IDE, wo soll der geschriebene
Code denn letztendlich laufen? Das ist doch umständlich hoch drei!
Es geht wirklich nur ums Absichern der IDE. Technisch ist alles fertig,
so dass wir zwar noch ohne großartige grafische Spielereien, aber doch
schon sehr effizient mit unserem "Proof of concept" arbeiten. Die
Bedienungsfreundlichkeit können wir natürlich noch perfektionieren, aber
darum geht es hier nicht.
Bernd K. schrieb:> Und dann ist es immer noch nur eine Online IDE, wo soll der geschriebene> Code denn letztendlich laufen? Das ist doch umständlich hoch drei!
Das ist das kleinste Problem. Selbstverständlich versionieren wir auch
und können den Code dann auf jedem anderen Rechner installieren. Doch
unsere Projekte erfordern oft eine langwierige Installationsorgie von
Abhängigkeiten, die wir nicht "mal eben" zu Testzwecken beim Kunden
einrichten können, dass passiert erst bei der Übergabe.
Besten Dank für deine Einschätzung, doch unsere Frage zielt leider in
eine vollkommen andere Richtung.
Hagen
Hagen schrieb:> Welche Lösungen gelten als ausbruchssicher?
So etwas gibt es nicht. Das was Du willst ist absolute Sicherheit ->
Kein System ist sicher! Verabschiede dich also von dem Gedanken des
"unmoeglichen ausbruchs", und zwar ganz schnell.
Alles was du tun kannst ist es maximal schwer zu machen, sodass ein
Angreifer die Lust verliert bevor er ausgebrochen ist. Alles andere ist
dumme Illusion.
Hagen schrieb:> VMWare? Virtualbox? Docker? LXC?
Neben den gennanten gibt es noch Firejail, chroot, bsdjail...
Firejail soll wohl inverbindung mit Grsecurity ziemlich gut sein.
Firejail: https://wiki.archlinux.org/index.php/Firejail
Aber wie gesagt: Absolute Sicherheit gibt es nicht.
Kaj schrieb:> Hagen schrieb:>> Welche Lösungen gelten als ausbruchssicher?> So etwas gibt es nicht.
Du sagst also, bei cloud9 & Co könnte man mit den bekannten
Sicherheitslücken die anderen Benutzerkonten übernehmen? Ich habe es
nicht ausprobiert, doch ich gehe zumindest davon aus, dass es nicht ganz
so trivial ist. Was machen sie deiner Meinung nach anders?
> Hagen schrieb:>> VMWare? Virtualbox? Docker? LXC?> Neben den gennanten gibt es noch Firejail, chroot, bsdjail...
chroot und BSD jails sind als vollkommen unbrauchbar bekannt. Danke für
den Hinweis zu Firejail. Davon hatte ich noch nicht gehört, und wenn es
mit dem Konzept von BSD jails nichts zu tun hat, werde ich mich mal
schlau machen.
Danke
Hagen
Hagen schrieb:> Du sagst also, bei cloud9 & Co könnte man mit den bekannten> Sicherheitslücken die anderen Benutzerkonten übernehmen? Ich habe es> nicht ausprobiert, doch ich gehe zumindest davon aus, dass es nicht ganz> so trivial ist.
Lies doch bitte weiter:
> Alles was du tun kannst ist es maximal schwer zu machen,
Du kannst jeden x beliebigen ITler, der sich mal ernsthaft mit
IT-Sicherheit beschaeftigt hat, fragen, und jeder wird dir genau das
selbe sagen:
1. Absolute Sicherheit gibt es nicht.
2. Alles was du tun kannst, ist es so schwer wie moeglich zu machen.
Das werden dir auch Leute wie Bruce Schneier, Edward Snowden, Fefe, FX,
und andere sagen.
Selbst Firmen wie die NSA oder Google, Facebook, Microsoft, etc. haben
Probleme damit ihre Systeme "sicher" zu machen. Cloudflare wirbt damit
Webseiten vor DDoS-Attacken schuetzen zu koennen... und trotzdem gehen
immer wieder Seiten die von Cloudflare gehostet werden wegen DDoS down.
Die genannten Loesungen (Virtuelle Maschine, Jails, was auch immer) sind
eben genau dieses "maximal schwer", aber ausbruchssicher sind sie nicht.
Schau dir doch nur mal die Hackerwettbewerbe an, wie schnell die z.B.
aus einer Sandbox im Browser ausbrechen.
Em Ende besteht das "maximal schwer" darin, die Rechte der Anwendung
soweit wie moeglich einzuschraenken (VM/Sandbox, Jails,
Rechteverwaltung/ACLs, Firewall,...)
Ich haeng da mal ein Bild (auszug aus einem Buch ueber Embedded
Security) an. Soviel zum Thema "Sicherheit". Trotz super duper
Sicherheitszertifikat nach 3 Tagen kaputt. Das ist auch heute nicht
anders.
Sicherheit ist nichts was man auf Knopfdruck bekommt. Sicherheit ist
kein Produkt. Sicherheit ist ein Prozess.
Es ist immerhin loeblich, dass Ihr euch ueber sowas gedanken macht. :)
Hier noch was zu virtual machine escape:
https://en.wikipedia.org/wiki/Virtual_machine_escape
Und hier was zu Jail escape:
https://github.com/netblue30/firejail/issues/240
Und hier noch was zu Docker:
https://news.ycombinator.com/item?id=7909622
Kaj schrieb:> 2. Alles was du tun kannst, ist es so schwer wie moeglich zu machen.
Sorry, aber ich sehe keinen wesentlichen Unterschied zwischen "fast
nicht schwanger" und schwanger.
> Hier noch was zu virtual machine escape:> https://en.wikipedia.org/wiki/Virtual_machine_escape>> Und hier was zu Jail escape:> https://github.com/netblue30/firejail/issues/240>> Und hier noch was zu Docker:> https://news.ycombinator.com/item?id=7909622
Ok. Darf ich fragen, warum du also 3 unbrauchbare Methoden vorgeschlagen
hast?
Du scheinst dich ja mit der Materie beschäftigt zu haben. Wenn es also
keine Möglichkeit gibt, den Ausbruch zu verhindern, ist es möglich, den
Ausbruch automatisiert zu erkennen und durch Abschalten Schaden zu
verhindern?
Danke
Hagen
Hagen schrieb:> Kaj schrieb:>> 2. Alles was du tun kannst, ist es so schwer wie moeglich zu machen.>> Sorry, aber ich sehe keinen wesentlichen Unterschied zwischen "fast> nicht schwanger" und schwanger.
Der Unterschied ist die Wahrscheinlichkeit, mit der das Ereignis
eintritt. Und das ist so ziemlich das einzige, was bei Sicherheits- bzw.
Risikobetrachtungen wichtig ist: Schaden x mit Wahrscheinlichkeit y.
[...]
> Du scheinst dich ja mit der Materie beschäftigt zu haben. Wenn es also> keine Möglichkeit gibt, den Ausbruch zu verhindern, ist es möglich, den> Ausbruch automatisiert zu erkennen und durch Abschalten Schaden zu> verhindern?
Dafür gilt das gleiche: du kannst nicht alle Fälle erkennen und es kann
eine gewisse Zeit dauern, in der das system mißbraucht werden kann ->
Schaden.
Du kannst, wie Kaj schon schrieb, nur versuchen, den Mißbrauch so teuer
zu machen, daß es sich für den Angreifer nicht lohnt. Aber auch das ist
schwammig und von der subjektiven Bewertung aus Sicht des konkreten
Angreifers abhängig (der ja irrationale Maßstäbe anlegen kann, z.B. wenn
er sich rächen will).
Wenn ein Einbruch weder finanziellen Gewinn bringt (z.B. Botnetze), noch
einen Imagegewinn (Trophäe) und du dir keine Feinde schaffst, die aus
der Beschädigung eine emotionale Befriedigung ziehen können, dann hats
du recht gute Chancen, in Ruhe gelassen zu werden. Auf mehr kann man
nicht hoffen.
Hagen schrieb:> Kaj schrieb:>> 2. Alles was du tun kannst, ist es so schwer wie moeglich zu machen.>> Sorry, aber ich sehe keinen wesentlichen Unterschied zwischen "fast> nicht schwanger" und schwanger.
Doch, es gibt einen ganz wesentlichen unterschied!
Der Unterschied ist: Brauch ich 10 Minuten, 1 Tag, 1 Woche oder 1 Monat
zum ein-/ausbrechen?
Je laenger es dauert ("maximal schwer"), desto groeser ist die
Wahrscheinlichkeit, dass der Angreifer aufgibt bevor er sein Ziel
erreicht hat.
Angreifer suchen sich hauptsaechlich Ziele die leicht zu knacken sind.
Das ist eine ganz einfache Rechnung: Habe ich ein System nach Zeit X
noch immer nicht geknackt, so gehe ich weiter und suche neue (leichtere)
Ziele. Denn in der selben Zeit die ich hier gerade verbraten habe,
haette ich schon wieder 3 andere Systeme knacken koennen.
Damit da ein Angreifer 1 Monat Zeit verbrennt muesste das System schon
ziemlich Wertvoll sein (exorbitante rechenleistung, strategisch gut
platziert, was auch immer).
Je nach dem was ich fuer Absicheten verfolge ist jede Minuten, die ich
mit deinem System verbringe, verlorenes Geld. Wenn es darum geht z.B.
ein Botnetz wie Mirai aufzubauen brauche ich Ziele die leicht zu knacken
sind. Denn je schneller ich Bots akquirieren kann, desto schneller
kann ich damit Kohle verdienen. Ich waere ja schoen dumm, wen ich da 1
Tag an Zeit verschwende und nichts bekomme, wenn ich in der selben Zeit
schon 200 neue Bots haette haben koennen.
Das "maximal schwer" schuetzt schon mal vor grob 90% der Angreifer. Bei
den restlichen 10% kannst du nur hoffen, dass sie dein System nicht
interessant genug finden um sich die Muehe zu machen.
Hagen schrieb:> Darf ich fragen, warum du also 3 unbrauchbare Methoden vorgeschlagen> hast?
Virtuelle Maschinen und Docker hast Du vorgeschlagen ;)
Ich hab einfach mal 3 Beispiele dafuer rausgesucht, dass das alles nicht
absolut sicher ist. Unbrauchbar sind diese Methoden deswegen aber noch
lange nicht.
Hagen schrieb:> ist es möglich, den> Ausbruch automatisiert zu erkennen
Ehrlich gesagt: Keine Ahnung ob ein IDS (Intrusion Detection System)
diese Art von Angreifer erkennen kann.
https://de.wikipedia.org/wiki/Intrusion_Detection_System
Hier nochmal ein aktuelles Beispiel:
Alle RHEL-Server in Microsofts Azure-Cloud waren angreifbar
https://www.heise.de/newsticker/meldung/Alle-RHEL-Server-in-Microsofts-Azure-Cloud-waren-angreifbar-3506326.html
Ralf D. schrieb:> Der Unterschied ist die Wahrscheinlichkeit, mit der das Ereignis> eintritt. Und das ist so ziemlich das einzige, was bei Sicherheits- bzw.> Risikobetrachtungen wichtig ist: Schaden x mit Wahrscheinlichkeit y.
Wie ich es hier lese, geht es aber um Schaden x mit Wahrscheinlichkeit
100% und Aufwand y. Die Exploits stehen doch offen im Netz, es gibt
Werkzeuge die einen nach dem anderen durchprobieren, die die Frage ist
nur, ob es 10 oder 20 Sekunden dauert, bis einer zum Erfolg führt.
Einzig mit einem Captcha bei der Anmeldung kann man verhindern, dass der
Einbruch vollkommen automatisch erfolgt. Ein System ist entweder
(bisher) sicher oder geknackt, 90% sicher gibt es nicht.
> Du kannst, wie Kaj schon schrieb, nur versuchen, den Mißbrauch so teuer> zu machen, daß es sich für den Angreifer nicht lohnt.
Wie ich oben schrieb, ist der zu erwartende Schaden bei Datenklau der
Grund, warum wir Anbieter wie cloud9 ausschließen. Softwareprojekte
können leicht in die Hunderttausende gehen. Und da lohnt sich eine ganze
Menge Aufwand.
> Wenn ein Einbruch weder finanziellen Gewinn bringt (z.B. Botnetze), noch> einen Imagegewinn (Trophäe) und du dir keine Feinde schaffst, die aus> der Beschädigung eine emotionale Befriedigung ziehen können, dann hats> du recht gute Chancen, in Ruhe gelassen zu werden. Auf mehr kann man> nicht hoffen.
Bestimmten Konkurrenten WIRD ein Einbruch beträchtlichen finanziellen
Gewinn bringen. Und DAS möchten wir verhindern.
Danke
Hagen
Kaj schrieb:> Das "maximal schwer" schuetzt schon mal vor grob 90% der Angreifer. Bei> den restlichen 10% kannst du nur hoffen, dass sie dein System nicht> interessant genug finden um sich die Muehe zu machen.
1% oder 0.1% oder 0.001%der Benutzer WIRD das System interessant genug
finden, auch einen Monat lang 100 professionelle Hacker darauf
anzusetzen.
Kann es sein, dass du Wirtschaftsinformatiker bist? Und jedes Problem
mit der 80-20-Regel erschlägst? Und dann die tatsächlichen Fachkräfte
zur Schnecke machst, weil du ihnen nur 20% Resource bewilligt hast, um
ein Problem zu 80% zu lösen, was vielleicht in deiner
Wirstschaftstheorie das Optimum ist, aber jeden realen Betrieb killt?
> Hagen schrieb:>> Darf ich fragen, warum du also 3 unbrauchbare Methoden vorgeschlagen>> hast?> Virtuelle Maschinen und Docker hast Du vorgeschlagen ;)Kaj schrieb:> Neben den gennanten gibt es noch Firejail, chroot, bsdjail...
Die kamen von dir! Dass chroot und bsdjail Schrott sind, ist allseits
bekannt. Dass Firejail Schrott ist, hast du nun im Nachhinein bestätigt.
> Hagen schrieb:>> ist es möglich, den>> Ausbruch automatisiert zu erkennen> Ehrlich gesagt: Keine Ahnung ob ein IDS (Intrusion Detection System)> diese Art von Angreifer erkennen kann.> https://de.wikipedia.org/wiki/Intrusion_Detection_System
Dann würde ich meine Frage gerne dahingehend umdefinieren, ob der
Übergang eines nichtprivilegierten Prozesses zum Start eines Prozesses
mit Rootrechten zuverlässig detektiert werden kann.
Danke
Hagen
Hagen schrieb:> Kann es sein, dass du Wirtschaftsinformatiker bist?
Noe, ich war 4 Jahre Softwareentwickler bei einer Firma fuer
Geldspielgeraete, unteranderem mit Manipulationsanalyse betraut, und
jetzt studiere ich IT-Sicherheit an der Uni Bochum.
Zu dem Rest von deinem Geschreibsel sag ich schon nichts mehr.
Mach doch einfach wie du willst, mir ist das herzlich egal.
Kaj schrieb:> jetzt studiere ich IT-Sicherheit an der Uni Bochum.
Erstsemester? Jedenfalls wünsche ich dir dabei mehr Erfolg als bisher!
Danke für deine Bemühungen zu meiner Frage.
Hagen schrieb:> Erstsemester? Jedenfalls wünsche ich dir dabei mehr Erfolg als bisher!> Danke für deine Bemühungen zu meiner Frage.
Für jemanden, der andere um Hilfe gebeten hat, aber schon mit der
schlichten Wahrheit, daß es absolute Sicherheit nicht gibt, offenbar
völlig überfordert bist, kanzelst Du Menschen, die Dir helfen wollten,
sehr herablassend ab.
Vielen Dank. Gut zu wissen, daß man sich die Mühe sparen kann.
Hagen schrieb:> Jedenfalls wünsche ich dir dabei mehr Erfolg als bisher!
Wie kommst du darauf das ich Erfolg brauche? Und wie kommst du darauf
das ich bisher keinen Erfolg gehabt haette?
Kaj schrieb:> Ich haeng da mal ein Bild (auszug aus einem Buch ueber Embedded> Security) an. Soviel zum Thema "Sicherheit". Trotz super duper> Sicherheitszertifikat nach 3 Tagen kaputt. Das ist auch heute nicht> anders.
EAL 4 ist bei weitem kein "super duper Sicherheitszertifikat", sondern
ein Papiertiger. Durch das Zertifikat wird nur bescheinigt, dass der
Antragsteller in der Lage ist, alle Papiere formal korrekt
zusammenzutragen. Der Zertifizierer führt bei EAL 4 aber z.B. keine
Penetrationstest o.ä. durch, sondern kontrolliert, ob z.B. laut
Antragsteller Reviews durchgeführt werden.
Bei den höheren Stufen ab EAL 5 wird das ganze dann plötzlich sehr viel
aufwändiger, da dort mit formalen mathematischen Methoden gearbeitet
wird.
Eine Schwäche aller EAL-Zertifizierungen besteht aber auch darin, dass
das Augenmerk eigentlich nur auf der Software liegt und manche
Seiteneffekte der eingesetzten Hardware nicht hinreichend untersucht
werden müssen. Weiterhin muss man sich bei jedem EAL-zertifizierten
Produkt das sog. "Security Target" (ST) anschauen, in dem auch die sog.
"Security Functional Requirements" (SFR) explizit aufgelistet werden.
Die Festlegung der SFR erfolgt jedoch durch den Antragsteller, d.h. es
werden für bestimmte Geräteklassen, z.B. Firewalls, keine konkreten
SFR-Mindestanforderungen durch den Zertifizierer vorgegeben. Falls man
also als Antragsteller bei der Prüfung bestimmter SFR durchfällt, kann
man diese immer noch aus dem ST streichen.
Als Außenstehender, der nicht sehr tief in der Materie steckt, hat man
also eigentlich kaum eine Chance, die Aussagekraft eines EAL-Zertifikats
zu beurteilen.
Tach,
es entsteht der Eindruck, als ob sich da gewaltig verzettelt wird und
das Interesse böser Mächte an Hobbyprojekten unter Freunden gewaltig
überschätzt ist.
Richtig ist schon: Viele Sandboxen gelten nur als sicher, bis ein
Exploit/Chip-Bug auftritt. Es gibt aber durchaus Möglichkeiten, eine
pure Python-Sandbox beweisbar sicher hinzukriegen und auch entsprechend
zertifiziert zu bekommen. Geht halt auf Kosten gewisser Funktionalität.
Es ist aber recht simpel:
Solange man keine root-Rechte bekommt, bricht man auch aus einem chroot
nicht aus. Wenn ihr da glaubt, dass manche Cloud-Anbieter solche
Probleme weniger im Griff hätten als ihr, seid ihr gehörig auf dem
Holzweg.
Mal abgesehen davon ist die Idee hirnrissig, online an Code
rumzufrickeln, welches Projekt das auch immer werden soll.
Synchronisiert euch lieber per github, und wenn dynamisch Codeobjekte
durch die Gegend wandern sollen, dann nutzt halt die Features, die
Python diesbezüglich mitbringt.
Irgendwie widerspricht das 100k€ teure Softwareprojekt nach welchem sich
die bösen Hacker die Finger ausstrecken auch dem Konzept, dass mal ein
paar Freunde von Freunden gemeinsam an Code rumpfriemeln...
Mir ehrlich gesagt zuviel Bla und Wichtigtuerei.
Fitzebutze schrieb:> Es gibt aber durchaus Möglichkeiten, eine> pure Python-Sandbox beweisbar sicher hinzukriegen und auch entsprechend> zertifiziert zu bekommen.
Hast du dazu eine Quelle? Beweisbar sicher halte ich für ausgeschlossen,
wenn das Python noch etwas mit Python zu tun haben soll, das Nachladen
von native Libraries nicht ausgeschlossen wird, und nicht 10x langsamer
als CPython läuft.
Uns würde schon eine Lösung reichen, die keine dokumentierten und seit
Jahren ungepatchten Einfallstore bietet.
Danke
Hagen
Fitzebutze schrieb:> Es gibt aber durchaus Möglichkeiten, eine> pure Python-Sandbox beweisbar sicher hinzukriegen und auch entsprechend> zertifiziert zu bekommen. Geht halt auf Kosten gewisser Funktionalität.
Ich bezweifele, dass sich wirklich jemand die Mühe machen würde, einen
formalen Korrektheitsbeweis (EAL-Sprech: "formal verifizierter Entwurf
und getestet") durchzuführen, da der hierfür benötigte Aufwand immens
wäre. Der Mehraufwand gegenüber der ansonsten üblichen Testtiefe liegt
locker um einen Faktor 1000 oder mehr höher. Bereits für recht einfache
Systeme, z.B. ein sehr stark eingeschränkter RTOS-Kernel, reden wir über
einen Zeitbedarf von mehreren Jahren bis Jahrzehnten.
Man sollte durchaus auch beachten, dass es nicht ausreicht, die
Korrektheit der ausgeführten Software zu beweisen, sondern dies muss
insbesondere auch für die Hardware erfolgen. Für die allermeisten
Architekturen ist die formale Beweisbarkeit nicht gegeben, z.B. ARM,
WIMRE auch x86. Da muss man gar nicht erst mit dem Beweisversuch
beginnen.
Hi,
Links kann ich dazu keine anbieten. Es gibt aber einige Sandbox-Ansätze,
die nicht erlauben, Binärcode zu injizieren, gidf.
Zum Rest kann ich nur soweit aus dem Nähkästchen plaudern: Man muss sich
die eigentliche Stackmachine vornehmen. Die ist ansich recht atomar und
lässt sich recht gut sandboxen, zudem ist sie auf dem VM-Level
beweisbar. Aber es müssen einige builtin-Module kastriert werden, und
alle libc-functionen sind `guarded`. Externe .so sind natürlich nicht
zugelassen. Netzwerkkram wird nochmal über tun/tap virtualisiert. Das
ganze läuft als sicherer LXC, oder unter MicroPython auf Chip mit
abgetrenntem TCP-HWstack, also garantiert buffer-overflow-resistent.
Zu Andreas: m.W. gibt es einen 386er-Kern mit full coverage. ARM Cortex
M0 ist für SIL3 zertifizierbar, obwohl ich seit ARM7 keinem ARM-Core
mehr 100% trauen würde. In unserem Fall ist es eine Stack-Maschine, die
wegen ihres einfachen instruction sets mit vernünftigen Aufwand
beweisbar ist.
Jetzt kann man natürlich noch hardware-bugs (gekippte Bits,
Rowhammer-Methoden) versuchen auszunutzen. Dagegen hält dann ein
HW-Watchdog.
Fast alles obiger Massnahmen basieren aber auf "hypothetischen
Annahmen".
Ansich hat Hagen einen pragmatischen Ansatz schon genannt: setuid
monitoren, falls mal jemand aus der Sandbox ausbricht. Mit allem anderen
hat man schon 1-2 Jahre zu tun, aber nicht gerade 10. Die Zeiten haben
sich auch geändert...
Fitzebutze schrieb:> Externe .so sind natürlich nicht> zugelassen.
Also nicht brauchbar für ernsthafte Anwendungen :(
> Das ganze läuft als sicherer LXC, oder unter MicroPython auf Chip mit> abgetrenntem TCP-HWstack, also garantiert buffer-overflow-resistent.
Wozu der zusätzliche Sicherheitslayer? Traut man der Sandbox nicht?
> Ansich hat Hagen einen pragmatischen Ansatz schon genannt: setuid> monitoren, falls mal jemand aus der Sandbox ausbricht.
Und dazu gibt es keine Literatur? Es müsste doch möglich sein, den
Kernel so zu patchen, dass das System herunterfährt, sobald eine
potentiell bösartige Aktion aufgerufen wird, die nicht auf einer
Whitelist steht.
Nur, was ist eine vollständige Liste der zu überwachenden Aktionen?
Und wie wird es praktisch umgesetzt? Dazu muss es duch schon Lösungen
geben?
Danke
Hagen
Wenn die internen Datenstrukturen des Kernels am Kernel vorbei geändert
werden, kann der Kernel sich überwachen wie er lustig ist und er wird
nix merken.
Schizophrenie merken auch immer nur die anderen. Interessant übrigens
auch der Fakt, dass unser Hagen auch als Personaler unterwegs ist und
damit die Nutzungsbedingungen verletzt...
Ich hatte schon länger die Idee, eine art Webdesk zu machen die
Anwendungen im Browser ausführen kann. Mittlerweile hat jemand anderes
das aber schon gemacht, nennt sich browsix:
https://github.com/plasma-umass/browsix
Wenn man die dinge zur client seite verlagert, werden die Einfallstore
massiv reduziert.
