Geschwindigkeit vs. Sicherheit
-
Optimizer schrieb:
rüdiger schrieb:
Wie würde das Beispiel durch den Einsatz von Java sicherer werden?
Java compiliert das nicht.
Ich weiß jetzt so spontan gar nicht, ob ein C++-Compiler das kompilieren muss. Aber selbt wenn, es reicht doch, das er warnt. Natürlich wäre es toller, wenn er so etwas nicht kompiliert und wir eine magische Programmiersprache hätten, die alle Fehler verhindert. Aber hey, ob der Compiler nun das Detail schluckt oder die XSS-Schwachstelle in deinem Java-Programm. (Komm mir nicht mit, das letztere könnte man nicht erkennen. Ruby kann das).
Ich verstehe einfach nicht, wie man so eine Panik um Bufferoverflows verbreiten kann und dann als Lösung eine Programmiersprache
vorschlägt, dessen VM genau solche Probleme en mas hat(te.
Ich schlage keine Sprache vor. Ich stelle vor, dass Java (nicht als einzige Sprache) ein ausgereiftes Konzept hat, um buffer overflows zu verhindern. Was die VM damit zu tun hat, ist mir ein Rätsel. Schließlich ist das ein Implementierungsdetail, genauso wie ein C++ Compiler falschen Code generieren könnte. Wir reden doch über Sprachen und darin eingebaute Sicherheit, oder?
Gut, Java bedingt eben eine große VM und daher viel Code, der geschrieben wird. Viel Code ist Fehleranfällig (praktisch bewiesen durch die Fehler, die in der VM waren). Ergo, ist es keine gute Idee Sicherheit durch mehr Code zu erreichen. Das ist mein Punkt.
Aber bitte, wenn wir alle der Meinung sind, das Java hier als Beispiel fehl am Platz ist oder zumindest irrelevant, dann können wir uns ja auf eine Alternative einigen, die wir hier diskutieren.
-
Artchi schrieb:
Hem, und wer garantiert mir, das nicht ein beliebiges Java-Programm, welches ich mir aus dem Netz lade (egal ob über WebStart oder so zum entpacken) nicht auch mein Homeverzeichnis löscht? Das kann die JVM nämlich auch nicht verhindern, denn jedes Java-Programm (außer Applets) kann Dateioperationen ohne Nachfrage ausführen. In dem Fall auch mal locker rekursiv mein Home löschen.
Du kannst jedes Java-Programm mit einem SecurityManager als Parameter starten, den du so konfigurieren kannst, dass dieses Java-Programm z.B. nicht mal deine Umgebungsvariablen lesen darf. So viel zu diesem Thema...
Ich finde es immer wieder lustig wie sich die Leute hier von beiden Seiten gegenseitig zerfleischen, und was da z.T. für schwachsinnige Kommentare abgegeben werden. Fehler macht jeder Programmierer, auch wenn er noch so perfekt ist, und da spielt auch die Sprache keine Rolle.
Java verfolgt einfach eine andere Philosophie als C++, deshalb ist es IMHO auch schwachsinnig ständig jeden einzelnen Bereich der beiden Sprachen zu vergleichen um dann zu sagen, dass die andere ja doch viel besser ist. Es gibt Bereiche für die Java "besser" geeignet ist, und es gibt auch Bereiche für die C++ "besser" geeignet ist und es gibt eben auch Bereiche in denen beide Sprachen etwa gleichwertig sind. Wo ist das Problem ? Ich programmiere z.B. in beiden Sprachen und wenn ich ein neues Projekt anfange, dann entscheide ich mich eben für diejenige Sprache von der ich denke, dass sie besser geeignet ist...Achja, aber mal zum Thema... in Java gibt es viele Sicherheitsmechanismen schon von Haus aus, wie eben z.B. den SecurityManager um nur mal einen zu nennen... Nur kennen das viele Leute gar nicht, deshalb kann man schon sagen, dass Java - zumindest von Haus aus - sicherer als C++ ist. Übrigens... in Java gibt es auch viele Fallstricke... die sind zwar "anders" als die von C++, aber die gibt es dennoch, und deshalb sind so Aussagen wie "Jeder schlechte Programmierer kann in Java gute Programme schreiben; in C++ geht das aber nicht" einfach nur daneben.
-
Bzgl. Alternativen: Ich probiere nicht alles freakige sofort aus, aber ich habe Erfahrungen (unterschiedlichen Ausmaßes) beispielsweise in C++, C, Java, C#, Prolog, Lisp, PHP, Python, verschiedene Basic-Dialekte und desweiteren gemacht. Vor allem Sachen wie Prolog sind, denke ich, auch mit einer gewissen Umstellung in der bekannten Denkweise verbunden. Ich mag auch nicht alle Sprachen davon außer C++.
Aber bei allen Sprachen habe ich eigentlich immer nur entdeckt, dass es völlig unmöglich ist, buffer overflows zu erzeugen - außer in C und C++. Das ist sozusagen ein Alleinstellungsmerkmal
Also welche Alternativen möchtest du diskutieren? 
Gibt es denn jetzt irgendeinen Grund zu glauben, dass ausgerechnet C++ für sicherheitskritische Anwendung toll ist?Sind denn alle anderen Sprachen für n00bs? Bei solchen Themen kommt es echt immer so rüber, dass alle Menschen, die je Sicherheitslücken verursacht haben, Idioten sind. Ich glaube das nicht, ich glaube vielmehr dass man aus gutem Grund einen Schutz vor solchen und anderen trivialen Fehlern in die Sprachen einbaut.
Und deshalb hilft auch das Argument "sowas triviales, wer das falsch macht, ist wirklich selber schuld" nicht - es geht genau um Trivialitäten.
-
nep schrieb:
Du kannst jedes Java-Programm mit einem SecurityManager als Parameter starten, den du so konfigurieren kannst, dass dieses Java-Programm z.B. nicht mal deine Umgebungsvariablen lesen darf. So viel zu diesem Thema...
Sorry, aber wieder so ein Beispiel, was ich über das OS abdecken kann. Ich muß bei Java die JAR per SecurityManager in ihrer Berechtigung einschränken? Ist ja i.O. Aber das kann ich auch mit Windows machen: "Ausführen als..." und dann führe ich die eine bestimmte Exe-Datei als Gast aus ohne mich ausloggen zu müssen.
Ich finde es immer beachtlich, das die Leute die Features der Java-VM/-Runtime aufführen, die ich auch schon in meinem OS eingebaut habe. Klar, Windows kann dann Fehler haben, aber auch die JavaVM! Also, was soll immer dieses "Ich mach das in Java einfach so." Ja, mein Gott, das mach ich halt über Windows, Linux oder BSD, weil das OS meine Runtime ist. Und VirtualPC habe ich auch kostenlos von MS, kann ich notfalls darin unbekannte Software sicher ausführen, wenn ich einen Level höher gehen will, bzgl. Sandbox.
Was ich sagen will: C++ ist nicht dazu verflichtet z.B. Sandbox-Features anzubieten. Das hat die Runtime auf der das C++-Programm läuft zu erledigen. Genauso wie Java als Sprache keine Sandbox kennt, sondern es die Java-Runtime/VM zu erledigen hat.
-
@Optimizer
AdaNatürlich gibt es Sprachen, die Fehlerquellen ausschließen, die andere Programmiersprachen erlauben. Aber das geht eben nur für bestimmte Fehler.
Gut, Java verhindert Index-Fehler. Aber was ist mit "unsicheren Strings", da bietet Java AFAIK nichts, so etwas gibt es aber in Ruby. Dennoch gab es zB eine kritische Sicherheitslücke in Ruby on Rails. Ada ist stark Typprüfend und hat für viele bekannte Bugs Laufzeitprüfungen. Aber dennoch ist die Ariane5 explodiert, weil der Code nicht mit dem Flugverhalten klar kam.
Man kann eben nicht sichere Programme durch eine Programmiersprache erzeugen. Aber genau der Eindruck wird hier vermittelt.
Sichere Programme sind das Ergebnis von Erfahrung, akribischer Planung/Prüfung und vor allem durch klaren und gut wartbaren Code (und keine fette Code-Base). Das hat nichts mit Java oder wer weiß was zu tun.
(Nur der Vollständigkeit halber:
http://sunsolve.sun.com/search/advsearch.do?collection=SUNALERT&type=collections&sort=date&queryKey4="category:security" "availability, security" category:security&max=100
http://java.sun.com/sfaq/chronology.html
)
-
@rüdiger: Was sind "unsichere Strings"?
Niemand sagt hier, dass man durch die Nutzung einer bestimmten Sprache gleich absolute Sicherheit kriegt. Aber die Sprache ist sicherlich ein Faktor, der Sicherheit entweder begünstigt oder auch nicht.
-
rüdiger schrieb:
Solltest Du die Suche da nicht auf Java einschränken?
-
Gregor schrieb:
@rüdiger: Was sind "unsichere Strings"?
Ich würde vermuten, er meint Benutzereingaben, die natürlich immer mit größtem Mistrauen zu behandeln sind. Klar, dass man nen Benutzer-String nicht gleich in ein SQL-Statement einbaut.
Und natürlich macht Java sowas nicht von allein. Genauso wie keine Programmiersprache garantiert, dass die Rakete korrekt fliegt. Die Sicherheitsprobleme, die sich aus der Semantik des Programms ergeben, sind immer da. Kein Grund, sich noch mehr Probleme aufzuhalsen.
-
@net: Full ACK.
MfG SideWinder
-
Optimizer schrieb:
Gregor schrieb:
@rüdiger: Was sind "unsichere Strings"?
Ich würde vermuten, er meint Benutzereingaben, die natürlich immer mit größtem Mistrauen zu behandeln sind. Klar, dass man nen Benutzer-String nicht gleich in ein SQL-Statement einbaut.
Das sollte ja die PreparedStatemants von Java abdecken
-
Artchi schrieb:
Sorry, aber wieder so ein Beispiel, was ich über das OS abdecken kann. Ich muß bei Java die JAR per SecurityManager in ihrer Berechtigung einschränken? Ist ja i.O. Aber das kann ich auch mit Windows machen: "Ausführen als..." und dann führe ich die eine bestimmte Exe-Datei als Gast aus ohne mich ausloggen zu müssen.
Naja du hast gefragt wer dir garantiert, dass ein Java-Programm z.B. nicht einfach dein ganzes Home-Verzeichnis löscht. Wenn du eh schon ne andere Möglichkeit hast, dann brauchst ja auch nicht zu fragen...
Wobei ich aber einfach mal behaupten will, dass du mit dem SecurityManager viel feingranularer bestimmte Berechtigungen vergeben bzw. verweigern kannst, wie durch das Ausführen als Gast...Und in anderen Betriebssystemen geht das nicht so einfach, behaupte ich jetzt auch einfach mal so, ohne mich da groß auszukennenIch will ja auch nicht unbedingt behaupten, dass C++ deshalb schlechter oder unsicherer ist. Ich wollte nur sagen, dass Java schon von Haus aus einige Sichherheitsmechanismen bereitstellt, die du in C++ so ohne Weiteres nicht hast. Und deshalb könnte man schon sagen, dass Java, zumindest von Haus aus sicherer ist.
-
Hier mal ein sehr interessanter Ausschnitt aus dem Blog des Hydranode-Projektleiters (Hydranode ist ein Opensource-P2P-Client der umfangreichen Gebrauch von der STL und Boost macht):
My greatest regret with Hydranode is that I didn't create a messy codebase; if I did that, there'd be a full-sized team behind the project already; but as it stands now, there's very little hope someone will pick up this project's maintainance, since developers knowing sufficient amount of C++/STL/Boost are hard to come by in OSS community, as it turns out. Personally, I know about 2-3 developers who'd have sufficient skillset to continue this project at these quality levels, and all of them are busy with other things.
Lesson learned - well-written codebase will cause most coders to run away in fear, rather than join in. However, I would never call Hydranode a waste of time; it's a great CV/Resume entry for me (I've gotten multiple job offers over the world already, from people who've seen Hydranode codebase), I've mastered advanced C++ (I knew very little C++ when I started this project), and I learned quite a lot about user interface design, usability testing and so on - all very valuable. I wrote Hydranode because I wanted to learn; towards that end, Hydranode has been a major success. But Hydranode failed as OSS project; next time I start some OSS project (doubtful it'll happen though), I'll create a messy codebase using basic C++ (no template metaprogramming, design patterns or any other of that "advanced crap"), and I'm willing to bet large sums of money that developers come running to join in.
Quelle: http://hydranode.com/blog/index.html
Das spiegelt sehr schön wieder, was wir in der C++ Welt eigentlich haben: die wenigsten kennen C++ und ihre Designmöglichkeiten. Ich habe mal einem Java-Kollegen, der seit Jahren auch C und C++ kennt, mal ein paar Hinweise bzgl. Templates u.ä. gegeben. Er selber kannte kein Boost, keine Namespaces ("warum hat mir das keiner gesagt?") und vorallem hat er 3D-Engines wie Irrlicht benutz. Mit dem Hinweis auf Templates und das diese nützlich sind und vorallem eine andere Denkweise als Java bedürfen, meinte er "Ja, aber die ganzen Frameworks wie Irrlicht werden von erfahrenen C++lern entwickelt, und ich habe noch nie Templates oder sowas darin gesehen! Die werden es ja wohl wissen?"
Eigentlich ist dieses Topic hier mal wieder so richtig sinnlos, weil bestimmt 99% der C++-Programmierer auf diesem Planeten kein Buch über die STL in der Hand hatten. Wenn man also mal wieder bei heise.de liest, das irgendwo ein Bufferoverrun ist, dann kann man davon ausgehen, das der Täter anscheinend keine Ahnung von C++ hat. Und das Hydranode-Projekt ist ein Belegt dafür.
-
Aspekte wie Sicherheit, Ergonomie, Design sind stark abhängig von Programmiere nicht von der Sprache/Framework. Sicher durch die Manageebene von Java und .Net wird der Programmiere entlasten von einige Sorgen, aber wenn ich eine Schadensfunktion in Java oder C++ realisiere, dann macht das die Applikation, ausser ich gebe der Applikation einen Sicherheitscontext, wo sie kein Schaden anrichten kann (Aber das geschieht eher selten oder? Hat Jemand sein Internetbrowser als Gast laufen?).
-
Erfrischend wär mal eine "Deutsch-vs-Französisch-Diskussion" (ich will ja nicht Flamewar sagen), aber ansonsten lerne, bzw. favorisiere ich einfach jene Sprache, die mir Arbeit und in Folge daraus Geld verschafft. Java ist für mich mehr als nur eine Sprache, bzw. für die Klugscheisser unter uns eine Runtime, sondern viel mehr auch sämtliche Tools, Frameworks und Communities, die dahinter stehen. Etwas ideologisch betrachtet ist es für mich momentan einfach der Ursprung der Innovation.
groovemaster schrieb:
Gute Frage. Schon mal aufgefallen, dass solche Sachen meistens von Java Anhängern ins Leben gerufen wird? Man mag ja 'ne Menge guter Sachen an Java finden, eine tolerante Community scheint wohl eher nicht dazu zu gehören.
Ein Troll hat diese Diskussion ins Leben gerufen, kein Java Anhänger. Außerdem habe ich eher den Eindruck, dass Java eher von allen Seiten angegriffen wird (Java - C++, Java - C#, neuerdings auch Java - Groovy, bzw. Java - Ruby, ...).
-
java anhänger schrieb:
Außerdem habe ich eher den Eindruck, dass Java eher von allen Seiten angegriffen wird (Java - C++, Java - C#, neuerdings auch Java - Groovy, bzw. Java - Ruby, ...).
Java vs. Groovy? Soetwas habe ich noch nicht gesehen. Wo gibt es denn solche Diskussionen?
-
java anhänger schrieb:
Java ist für mich mehr als nur eine Sprache, bzw. für die Klugscheisser unter uns eine Runtime, sondern viel mehr auch sämtliche Tools, Frameworks und Communities, die dahinter stehen.
Nicht zu vergessen die Firmen die fröhlich Lüg... äh... Unwahrheiten wie "Plattformunabhängigkeit" propagieren und den Managern ins Ohr legen... Toll gemacht
-
TactX schrieb:
Nicht zu vergessen die Firmen die fröhlich Lüg... äh... Unwahrheiten wie "Plattformunabhängigkeit" propagieren und den Managern ins Ohr legen... Toll gemacht
Mir kommt es immer so vor, als ob die C++ler bei allen möglichen Vorteilen von Java sagen: "Aber da habe ich ein Beispiel, bei dem das nicht so gut klappt. Also ist der ganze Vorteil zu negieren, nicht vorhanden."
Das stimmt natürlich nicht. Die Vorteile, die Java bietet, sind nicht als "absolute Vorteile" zu verstehen, sondern nur relativ im Vergleich zu anderen Sprachen, wie zum Beispiel C++. Ein Negativ-Beispiel macht den Vorteil nicht zu nichte. Was viel mehr zählt, ist die Wirksamkeit des Vorteils im Gesamten. Wenn so ein Vorteil viele Probleme behebt, dann ist es immer noch ein Vorteil, auch wenn er nicht alle Probleme behebt.
Das kann man auf Sicherheit beziehen, das kann man auf Plattformneutralität beziehen und auch noch auf andere Eigenschaften, die Java von deren Befürwortern gerne zugeschrieben werden. Es mag auch Probleme geben, Javaprogramme für verschiedene Plattformen verfügbar zu machen. Diese sind aber viel geringer als die Probleme, die sich einem da beispielsweise mit C++ stellen. ...solange eine entsprechende JRE für die entsprechenden Plattformen existiert.
-
Gregor schrieb:
TactX schrieb:
Nicht zu vergessen die Firmen die fröhlich Lüg... äh... Unwahrheiten wie "Plattformunabhängigkeit" propagieren und den Managern ins Ohr legen... Toll gemacht
Mir kommt es immer so vor, als ob die C++ler bei allen möglichen Vorteilen von Java sagen: "Aber da habe ich ein Beispiel, bei dem das nicht so gut klappt. Also ist der ganze Vorteil zu negieren, nicht vorhanden."
Es geht darum, dass einfach falsche Begriffe benutzt werden. Da gibt es kein "bißchen falsch", "ziemlich falsch" oder "total falsch". Plattformunabhängigkeit ist eine Lüge. Sie wird auch nicht wahrer wenn man sie "Plattformneutralität" nennt.
PS: So, ich gehe jetzt mal Eclipse auf meinem Handy starten...
PPS: Ich bin kein C++ler. Tut hier aber nichts zur Sache.
-
TactX schrieb:
Es geht darum, dass einfach falsche Begriffe benutzt werden. Da gibt es kein "bißchen falsch", "ziemlich falsch" oder "total falsch". Plattformunabhängigkeit ist eine Lüge. Sie wird auch nicht wahrer wenn man sie "Plattformneutralität" nennt.
PS: So, ich gehe jetzt mal Eclipse auf meinem Handy starten...
Musst aber ein gut ausgerüstetes handy haben. Wenn jetzt Doom 3 auf meinem Rechner nicht läuft heißt das also, dass bei mir nix was in C/C++ geschrieben wurde läuft
-
TactX schrieb:
Es geht darum, dass einfach falsche Begriffe benutzt werden. Da gibt es kein "bißchen falsch", "ziemlich falsch" oder "total falsch". Plattformunabhängigkeit ist eine Lüge. Sie wird auch nicht wahrer wenn man sie "Plattformneutralität" nennt.
Du hast da halt bestimmte Begriffsvorstellungen und andere Leute haben andere Begriffsvorstellungen. "Plattformunabhängigkeit" sehe ich zum Beispiel immer als Gegensatz zur "Portierbarkeit". Javaprogramme werden nicht auf andere Plattformen portiert. Wenn es da eine entsprechende JRE gibt, dann laufen sie da halt. Ich kann als Nutzer das Javaprogramm auf die neue Plattform mitnehmen. Beim Portieren spielt hingegen der Entwickler eine deutlich wichtigere Rolle.