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
Angehängte Dateien:
-
vmware.jpg
270 KB
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?
Da Du alle bereits vorhandenen Lösungen als "vollkommen unbrauchbar" und "Schrott" betrachtest, gibt es keine Dir angemessenen Lösungen. Baue eine!
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.
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.