Debian als Betriebssystem

[Debian99]

Hallo,

ich nutze seit 2 Wochen nun debian stable. Mich interessieren jetzt nur noch ein paar Fragen, die ich nicht ganz so kapiere. Debian stable ist ja auch für den normalen Desktop-PC (normaler PC-Nutzer) zu empfehlen, und nicht nur für Server, oder? Wenn ich jetzt Testing verwenden würde, ist das auch für den normalen PC-Nutzer zu empfehlen? Denn die Sicherheitsupdates werden ja nicht vom Team Sicherheit betreut. Ist Testing dann überhaupt sicher? Insbesondere Online-Banking?

VG

[TomL]

Du müsstest vielleicht vorher kurz erklären, welche Verbesserung du dir von einem Wechsel nach Testing versprichst. Funktioniert irgendwas mit 'stable' nicht wie gewünscht? Im Normalfall, also ohne konkreten Grund, würde ich nicht nach Testing wechseln .... wozu auch, wenn nicht konkrete Vorteil damit verbunden sind?
'stable' läuft mittlerweile so rund, dass es fast wirklich schon wieder langweilig ist. Mit 'testing' sind hingegen durchaus auch mal Aufreger möglich. Also, was möchtest du mit 'testing' verbessern?

Mein Rat wäre: Nach nur 2 Wochen erstmal bei 'stable' bleiben und in dem Umfeld die Geheimnisse und Tiefen von Linux erkunden.

[geier22]

Debian stable ist ja auch für den normalen Desktop-PC (normaler PC-Nutzer) zu empfehlen, und nicht nur für Server, oder?

Vermisst du denn irgendwas in deiner Installation ?
Server laufen meist ohne graphische Oberfläche und bieten einem Netzwerk spezielle Server- Dienste an.
Das Grundsystem ist aber das selbe.

Wenn ich jetzt Testing verwenden würde, ist das auch für den normalen PC-Nutzer zu empfehlen?

Wenn du bereit bist dich in Debian einzuarbeiten und manchmal auch Schwierigkeiten überwinden kannst (willst), weil eben noch nicht alles so funktioniert wie es soll, hast du den Vorteil, stets aktuelle Software zur Verfügung zu haben.
Sicherheitsupdates gibt es in testing genauso. Wer die betreut kann ich nicht sagen.

ist Testing dann überhaupt sicher? Insbesondere Online-Banking?

Jedes Betriebssystem ist so sicher, wie das Sicherheits- Bewusstsein in des jeweiligen Nutzers. Dies gilt erst mal für Linux genauso wie für Windows und irgendwelche anderen Betriebssysteme. Bei Linux hast du den Vorteil, dass du - was die Verbreitung betrifft - mit einem "exotischem" Betriebssystem arbeitest, für das es sich meist nicht lohnt, Schadsoftware zu entwickeln.
Zum Online - Banking gibt es gerade hier im Forum viele sehr nützliche Threads z.B Live System für Online Banking und Surfen. Ich empfehle dir, diesen und andere Threads sorfältig zu lesen und dann noch offene Fragen zu stellen.

[guennid]

Die Frage taucht immer wieder auf und ist pauschal eigentlich nicht zu beantworten.

Du müsstest vielleicht vorher kurz erklären, welche Verbesserung du dir von einem Wechsel nach Testing versprichst. Funktioniert irgendwas mit 'stable' nicht wie gewünscht? Im Normalfall, also ohne konkreten Grund, würde ich nicht nach Testing wechseln.

Konziser kann man's kaum formulieren.

"Große" aktuellere Software für stable kriegt man (problemlos, behaupte ich mal) als Debian-Paket auch bei den jeweiligen Herstellern - falls überhaupt benötigt (z.B. webbrowser, office).

geier22s-Hinweise verschleiern die Hürden eher, als dass sie sie offenlegen: "einarbeiten in Debian" heißt in diesem Fall, zu lernen/in der Lage sein, selbst mal was zu kompilieren (ich nenn's mal: rudimentäres Programmieren), shell-Syntax auf gehobenenem Nivau formulieren zu können/wollen. Das vorausgesetzt, könnte man wohl auch testing ins Auge fassen. Die Frage ist, ob man sich dann noch als "normaler PC-Benutzer" begreifen kann. Man darf sich aber dann wohl durchaus zumindest als Nerd-Beginner fühlen.

Passen diese Voraussetzungen einerseits nicht und Debian stable ist einem andererseits nicht aktuell genug, sollte man sich fragen, ob Debian die richtige Linux-Distribution für einen ist.

Grüße, Günther

[Radfahrer]

Also, von Shell-Scripting auf hohem Niveau bin ich Lichtjahre entfernt. Habe es aber auch noch nie benötigt, um Testing am Laufen zu halten. Und selber kompilieren musste ich auch noch nie was.

Trotzdem nutze ich seit Jahren Testing ohne Probleme. Und zwar permanent (habe testing in meiner sources.list stehen).
Habe auch mal eine Zeit Unstable benutzt, aber das war mir nicht langweilig genug. Also wieder Testing.

Falls mal etwas nicht funktioniert, muss man halt in der Lage sein, sich zu informieren. Meistens wird man schnell fündig und kann den Fehler beheben. Passiert nicht oft.

Grundsätzlich stimme ich aber zu, als Anfänger sollte man sich erst einmal mit den Grundlagen befassen, bevor man zu Testing wechselt.

[wanne]

Sicherheitsupdates gibt es in testing genauso. Wer die betreut kann ich nicht sagen.

Meines Wissens betreut die eben niemand. Es kommen halt mit 2 Tagen Verzögerung die updates für unstable. Gibt Betriebssysteme bei denen man Wochen auf updates warten muss auf der anderen Seite habe ich so 40h nach nach der Veröffentlichung von hardbleed massenhaft anfragen auf 443 auf meinem Server gesehen. (Der da btw. nicht mal https spricht.) Besonders gefählich ist, dass ein Paket, das in Testing ist einfach aus debian rausfliegen kann. Dann hast du eine alte Version, für die es gar keine Updates mehr gibt. Das dürfte dann aber auch relativ selten sein. Je nach paranoiastufe kann einem das schon Bauchschmerzen bereiten.

[guennid]

Shell-Scripting auf hohem Niveau

Ich sprach bewusst von "gehobenem" nicht von hohem Niveau. Einfach wäre für mich vielleicht eine batch-Datei, und selbst die kann bei Linux ganz schön kompliziert sein, finde ich jedenfalls, und ich behaupte mal, im Jahre des Herrn 2016 weiß ein "normaler PC-Nutzer" nicht mal, was eine batch-Datei ist und weiterhin meine ich, dass er das auch nicht unbedingt zu wissen brauchen sollte, wenn er Debian-stable benutzen will.

Schönes Beispiel ist geier22s wannes letzter Beitrag: Ein "normaler PC-Nutzer" formuliert sowas nicht. Er weiß weder was mit 443 gemeint ist noch was hardbleed (heartbleed?) ist. "paranoiastufe"

Grüße, Günther

[edit]

Ach du gute Güte, da habe ich geier was unterstellt, was wanne geschrieben hat! Ich hab's korrigiert.

[Debian99]

Hallo,

danke für die vielen Antworten . Also meine Linuxkenntnisse würde ich schon als ein wenig Fortgeschritten bezeichnen. Nutze auf Linux basierte Distributionen schon seit ca. 3-4 Jahren. Habe halt sehr oft gewechselt. Die meisten Distributionen waren mir aber zu unstabil bzw. basierten auf eine Firma. Da für mich auch OS und die Community wichtig sind, bin ich bei Debian angelangt. Früher habe ich immer gelesen, das die Software sehr veraltet ist, was ich nicht "wirklich" bestätigen kann. Zum anderen warum ich zu Debian gewechselt bin, ist dass Debian eigentlich die Mutter von vielen Distributionen. Zu guter Letzt, wie oben schon erwähnt, möchte ich KDE nutzen. Da dies bei den meisten Distributionen (Plasma 5) immer abstürzt bzw. Probleme bereitet (die Übersetzung ins Deutsche lässt bis jetzt auch zu wünschen übrig), bin ich zu Debian stable (KDE 4) gewechselt. Ich habe Debian schon lange im Auge gehabt, habe mich aber nie wirklich "getraut" zu wechseln. Bis jetzt bin ich aber mehr als zufrieden.

Zum Online-Banking: Ich würde es schon gerne im Browser ohne Live-CD nutzen. Ist dies denn nicht zu empfehlen?

Was ich mir von Testing erwarte:
- KDE Plasma 5
- etwas aktuellere Software
- den aktuelleren Linux-Kernel

Ich hoffe ich habe jetzt nicht zu viel geschrieben .

VG
Debian99

[wanne]

den aktuelleren Linux-Kernel

Den bekommst du auch aus den backports

Zum Online-Banking: Ich würde es schon gerne im Browser ohne Live-CD nutzen. Ist dies denn nicht zu empfehlen?

Wenn du dir den Thread gut durchließt, siehst du dass viele der Ansicht sind, dass man mit einer Live-CD magels updates sogar eher unsicherer surft als mit einer aktuellen Distro. Gab aber auch viele andere Ideen alla eigener Nutzer für's online Banking, die ich für deutlich sinnvoller halte. Ich mache es genau umgekehrt für anfällige sachen wie surfen mit Plugins, wine, steam und ähnliches habe ich eigene user (mit eigenem Chrome etc. als Nutzer installiert und ggf ohne Internetzugang (wine).) Außerdem fürs banking ein eigenes Profil mit angepassten Einstellungen.

Da dies bei den meisten Distributionen (Plasma 5) immer abstürzt bzw. Probleme bereitet (die Übersetzung ins Deutsche lässt bis jetzt auch zu wünschen übrig), bin ich zu Debian stable (KDE 4) gewechselt
[…]
Was ich mir von Testing erwarte:
- KDE Plasma 5
- etwas aktuellere Software

Das ist eben das Ding: Die Erfahrungen, die du mit Distos gemacht hast, die neuere Software und damit insbesondere Plasma 5 schneller adaptieren wirst du in testing in vermutlich ziemlich ähnlicher Form machen. Das mehr an Stabilität in Debian stable kommt eben von der etwas abgehangenen SW. Nutzt du testing bist du defakto halt wieder an nem Mint oder so.

[geier22]

Zum Online-Banking: Ich würde es schon gerne im Browser ohne Live-CD nutzen. Ist dies denn nicht zu empfehlen?

Grundsätzlich ist ein Browser nicht sicher. Das einzige Verfahren, bei dem noch keine geglückten Angriffe bekannt sind, ist die Kombination von Banking Programm / Secoder 2. In dem Thraed weiter hinten (deshalb :Lesen ) Werden verschiedene Möglichkeiten beschrieben (VM mit Banking - Programm / separater User)

Was ich mir von Testing erwarte:
- KDE Plasma 5
- etwas aktuellere Software
- den aktuelleren Linux-Kernel

Plasma 5 würde ich dir im Augenblick als Produktivsystem noch nicht empfehlen. In einer VM läuft es bei mir inzwischen recht stabil,
aber als Hauptsystem hatte ich damit bisher ziemlich viel Ärger. Soweit ich weiß, soll Plasma 5 ja auch irgendwann auf Wayland umgestellt werden, was auch Problem geben wird.

Ich nutze z.Z. Xfce und Cinnamon im Dual-Boot als Produktive Systeme - beide Testing - und habe damit bisher wenig bis gar keine Probleme gehabt. Für spezielle Aufgaben (Banking, Downloads, ein paar Windows-Programme, die ich noch brauche bzw. mal gekauft hatte usw.) habe ich jeweils extra VM' s)

[wanne]

Das einzige Verfahren, bei dem noch keine geglückten Angriffe bekannt sind, ist die Kombination von Banking Programm / Secoder 2.

Ich nenne das mal haltlose Werbung.
Gegen Chrome 49 sind überhaupt keinerlei Angriffe bekannt. Mehr oder weniger die gesamte Chrome Reihe (Habe nur die Security hole des letzten Jahres angeschaut.) besitzt keinerlei bekannte Schwachstellen, wenn man ausschließlich online Banking macht. (Nur vertrauenswürdige HTTPS-Seiten ansurft.)
HBCI Benutzt btw. zum Absichern genauso auf TLS wie Klassisches Online Banking vermutlich werden sie, je nach Hersteller exakt die Gleiche lib wie Konqueror nur halt vermutlich in irgend einer Steinaltversion.

Als zusätzliche Absicherung gib's dann ChipTAN:
Demgegenüber scheint das BSI durchaus Schwachstellen in ChipTAN zu kennen. Hält es aber im Moment nicht für eine Gefahr für Onlinebanking. (Vermutlich weil der Aufwand deutlich größer ist, als das was man danach erbeuten könnte.)
Dem verwendeten Algorithmus wurde eine Klassifizierung als "sicher" ausdrücklich verwehrt. Stattdessen gab es "ausreichend sicher".
Und ChipTAN ist noch gar kein Produkt sondern nur ein Algorithmus. In diversen Eingabegeräten bestimmter Hersteller wurden schon massenhaft Lücken gefunden.

Edit: Sauberere forumuliert.

[geier22]

Ich nenne das mal haltlose Werbung.

nun, zumindest behauptet das auch Wikipedia:
Homebanking Computer Interface

Was Chrome betrifft: hier mal schnell gegoogelt : von 2014:
Bankraub digital

[KP97]

Edit: Sauberere forumuliert.

Echt? Ist mir gar nicht aufgefallen....
@geier22 spricht von einer Bankingsoftware und einem Kartenleser mit HBCI Chipkarte.
Und das ist nun mal die sicherste Variante und hat mit Werbung für irgendwas schlichtweg nichts zu tun.

[wanne]

Ich nenne das mal haltlose Werbung.

nun, zumindest behauptet das auch Wikipedia:
Homebanking Computer Interface

Da steht, dass keine erfolgreichen Bankraube bekannt sind. Das gilt btw. auch für so kaputte standards wie SSL 2.
Und liegt in erster Linie daran, dass man bekanntermaßen unsicheres Zeug nicht mehr verwendet. (Ausnahme war mTAN, da war jedem von Anfang an klar, dass das unsicher ist. Warum es trotzdem verwendet wurde musst du dir selbst überlegen. Keiner Tipp: Smartphonenutzung gilt als sehr attraktiv und Täter sind vergleichsweise einfach zu fassen.) Das was man aktuell nutzt ist entsprechend nie bekanntermaßen anfällig.
Zum zweiten ist es aber auch verdammt schwer nachzuweisen, dass wirklich eine Schwachstelle ausgenutzt wurde. Kommt man in die nähe von sowas zahlen die Banken lieber freiwillig. Der Imageverlust und die möglichen Nachahmer sind deutlich teurer.

Bankraub digital

Gelesen? Möglich. Verstanden? Offensichtlich nicht.
Keinerlei Lücken in Chrome. Nutzer wurde zuerst dazu überredet sich Malware (als Administrator!) auf den PC zu installieren. Danach konnte man die Inhalte in Chrome genauso abändern wie jede andere HBCI Software. (Und ich würde mal tippen, dass er das auch gemacht hat. Wurde wegen der Unbekanntheit der SW nur nicht extra angemerkt. Genausowenig wie Konqueror oder Surf. )
ChipTAN hätte tatsächlich geholfen. Eben genau aus dem oben genannten Grund:
Es wird ausschließlich zum Onlinebanking verwendet. Leute zu überreden da Malware aufzuflashen wird deutlich schwieriger als einfach einen Bildschirmschoner zu verbreiten.

[wanne]

Edit: Sauberere forumuliert.

Echt? Ist mir gar nicht aufgefallen....
@geier22 spricht von einer Bankingsoftware und einem Kartenleser mit HBCI Chipkarte.
Und das ist nun mal die sicherste Variante und hat mit Werbung für irgendwas schlichtweg nichts zu tun.

Sagen die Banken die das anbieten. – Und limitieren die maximal damit zu transferierenden Geldmengen und setzen selbst für größere Beträge BCS ein...

HBCI+ChipTAN mag das Anwenderfreundlichste und trotzdem ausreichend sichere Modell sein. (Vor allem weil man wenig versehentlich falsch machen kann.) Aber das sicherste ist es garantiert nicht.

[geier22]

@wanne : was willst du uns denn damit alles sagen ????

Ich mache Banking eben nicht mit einem Browser z.B. deshalb:
aus : https://www.cert-bund.de/advisoryshort/ ... UPDATE%202

Beschreibung
Chromium ist die Open-Source Variante des Google Chrome Browsers. Chromium ist für verschiedene Betriebssysteme, u.a. für BSD, Linux und Windows verfügbar.
Chrome ist ein kostenfreier Webbrowser des Google-Konzerns. Er ist für Windows (ab Windows XP), Mac OS X, Linux, Android und iOS verfügbar. Das Programm ist ein integraler Bestandteil des Google Chrome OS.
Mehrere Schwachstellen in Google Chrome vor Version 49.0.2623.108 auf Windows, Mac und Linux Systemen ermöglichen einem entfernten, nicht authentifizierten Angreifer die Ausführung beliebigen Programmcodes und verschiedene Denial-of-Service-Angriffe (DoS-Angriffe). Die Schwachstellen werden mit dem Stable Channel Update auf die Chrome Version 49.0.2623.108 behoben, darüber hinaus steht bereits die neuere Version 49.0.2623.110 von Google Chrome zum Download bereit. Debian stellt für die Distribution Debian Jessie (stable) Sicherheitsupdates für den Chromium Browser auf die Version 49.0.2623.108 bereit. Update: Für openSUSE 13.2 und openSUSE Leap 42.1 stehen Sicherheitsupdates für den Chromium Browser auf die Version 49.0.2623.110 bereit.

Wollen wir mal zusammenzählen, wie viele Sicherheitslücken in den letzten Jahre in großen Browsern entdeckt wurden?
Dass sie dann irgendwann gefixt wurden, heist doch nur, dass sie entdeckt wurden. Seit wann sie bestanden weiß kein Mensch.

Aber vielleicht erklärst du mal stattdessen - statt mir ein Smartphone fürs Banking zu empfehlen - wie man eine Transaktion
mit einem Banking Programm und einem Chipkartenleser Klasse 3 nach Secoder 2 - Standard in einer VM in der nur das Banking - Programm ins Internet kann manipulieren soll? Ich will nicht behaupten, dass das unmöglich ist, jedoch sind die Hürden um ein vielfaches höher als mit einem Browser, bei dem alle paar Wochen ein neues Leck gefunden wird.

[geier22]

Und noch eine aufklärender Artikel vom BSI:
aus: Lebenszyklus einer Schwachstelle

Bug Bounties und Schwachstellen-Broker
Im Zusammenhang mit dem Suchen und Finden von Schwachstellen haben sich mittlerweile verschiedene
Geschäftsmodelle entwickelt. Einige Hersteller, wie etwa Google oder Mozilla, zahlen Entdeckern einen be­
stimmten Geldbetrag, wenn diese sicherheitskritische Schwachstellen im Rahmen einer Coordinated
Disclosure melden. Diese Bug Bounties, also „Kopfgelder auf Schwachstellen“, können einen deutlichen An­
reiz für die Suche nach und die Meldung von Schwachstellen darstellen. Andere Hersteller, wie etwa Adobe
und Microsoft, lehnen hingegen eine Bezahlung für die Meldung einzelner Schwachstellen ab.
Auch per Zwischenhandel funktioniert dieses Geschäft: Schwachstellen-Broker wie TippingPoint (Zero-Day
Initiative) oder iDefense (Vulnerability Contributor Program) bezahlen ebenfalls für an sie gemeldete
Schwachstellen. Anschließend arbeiten sie üblicherweise mit den betroffenen Herstellern im Rahmen einer
Coordinated Disclosure zusammen. Gleichzeitig nutzen sie die erworbenen Informationen, um eigene
Dienstleistungen und Produkte zum Schutz vor diesen Schwachstellen anzubieten. Andere Unternehmen,
wie beispielsweise VUPEN, handeln wiederum auch mit Schwachstellen, die sie unter anderem Geheim­
diensten und Ermittlungsbehörden zur Verfügung stellen.
Zusätzlich existieren inoffizielle und zum Teil auch kriminelle Märkte, auf denen insbesondere Zero-Day-
Exploits für effiziente Angriffe gehandelt werden.

Meine Suche allein für Chrome in diesem Jahr auf https://www.cert-bund.de/search:

01.04.16 4
CB-K16/0473 Update 2

Google Chrome, Chromium: Mehrere Schwachstellen ermöglichen u.a die Ausführung beliebigen Programmcodes
30.03.16 4
CB-K16/0473 Update 1

Google Chrome, Chromium: Mehrere Schwachstellen ermöglichen u.a die Ausführung beliebigen Programmcodes
29.03.16 4
CB-K16/0473

Google Chrome, Chromium: Mehrere Schwachstellen ermöglichen u.a die Ausführung beliebigen Programmcodes
21.03.16 4
CB-K16/0438

Bibliothek Libvpx: Eine Schwachstelle ermöglicht die Ausführung beliebigen Programmcodes mit den Rechten des Dienstes
21.03.16 4
CB-K16/0378 Update 4

Google Chrome, Chromium: Mehrere Schwachstellen ermöglichen u.a die Ausführung beliebigen Programmcodes
18.03.16 4
CB-K16/0378 Update 3

Google Chrome, Chromium: Mehrere Schwachstellen ermöglichen u.a die Ausführung beliebigen Programmcodes
11.03.16 4
CB-K16/0378 Update 2

Google Chrome, Chromium: Mehrere Schwachstellen ermöglichen u.a die Ausführung beliebigen Programmcodes
10.03.16 4
CB-K16/0378 Update 1

Google Chrome, Chromium: Mehrere Schwachstellen ermöglichen u.a die Ausführung beliebigen Programmcodes
09.03.16 4
CB-K16/0378

Google Chrome, Chromium: Mehrere Schwachstellen ermöglichen u.a die Ausführung beliebigen Programmcodes
17.02.16 4
CB-K15/0733 Update 14

17.02.16 4
CB-K15/0733 Update 14

TLS/Logjam: Eine Schwachstelle ermöglicht das Umgehen von Sicherheitsmaßnahmen

[wanne]

Das Problem ist, dass die Sichtweise mehr bekannte Sicherheitslücken == unsicherer absolut dämlich ist, wenn man ungleiche Sachen vergleicht. (Was auch schon ganz massiv Java völlig zu unrecht in Verruf gebracht hat.)

Beipiel:

Beschreibung
Chromium ist die Open-Source Variante des Google Chrome Browsers. Chromium ist für verschiedene Betriebssysteme, u.a. für BSD, Linux und Windows verfügbar.
Chrome ist ein kostenfreier Webbrowser des Google-Konzerns. Er ist für Windows (ab Windows XP), Mac OS X, Linux, Android und iOS verfügbar. Das Programm ist ein integraler Bestandteil des Google Chrome OS.
Mehrere Schwachstellen in Google Chrome vor Version 49.0.2623.108 auf Windows, Mac und Linux Systemen ermöglichen einem entfernten, nicht authentifizierten Angreifer die Ausführung beliebigen Programmcodes und verschiedene Denial-of-Service-Angriffe (DoS-Angriffe). Die Schwachstellen werden mit dem Stable Channel Update auf die Chrome Version 49.0.2623.108 behoben, darüber hinaus steht bereits die neuere Version 49.0.2623.110 von Google Chrome zum Download bereit. Debian stellt für die Distribution Debian Jessie (stable) Sicherheitsupdates für den Chromium Browser auf die Version 49.0.2623.108 bereit. Update: Für openSUSE 13.2 und openSUSE Leap 42.1 stehen Sicherheitsupdates für den Chromium Browser auf die Version 49.0.2623.110 bereit.

Dieses Verhalten wäre für Online-Banking-Software keine Sicherheitslücke. Schließlich, werden beim Online Banking die Gegenstellen als sicher angesehen. Die Lücke ist total harmlos, wenn man nur seine Bank ansurft. (Die Überprüfung der Echtheit der Gegenstelle ist nicht betroffen.) Da Chrome eben auch für das Surfen auf unsicheren Seiten ausgelegt ist, gibt es massenhaft Sicherheitslücken, die so bei Banking-Software nie als solche eingestuft würden. Kurz: Bei Chrome wird viel mehr Verhalten als Sicherheitslücke eingestuft als bei Banking-Software => Mehr Sicherheitslücken. Defakto ist Chrome aber gerade wegen der Anforderung auch im "wilden" Internet zurechtzukommen um Längen stärker gegen Angreifer gehärtet.

Dazu kommt, dass du nie eine Spezielle Software genannt hast, sondern nur ein Protokoll. Wenn du in HBCI Sicherheitslücken forderst dann müsstest du entsprechend welche HTML zeigen. Was natürlich völliger Quatsch ist. Das Protokoll, dass für die Sicherheit verantwortlich ist, ist in beiden fällen TLS. Entsprechend kann ich absolut keinen Vorteil für eine der Seiten sehen.
Wenn du mit Chrome vergleichst müsstest du einen entsprechende Banking-Software udn auch da gibt es extreme Unterschiede: Nutzt du Hibiscus (Ich glaube das ist so das beliebteste, was es im Moment so gibt.) Dann hat das in letzter Zeit einige wirklich schwerwiegende Sicherheitslücken gehabt. (Und zwar wirklich welche die für's Banking relevant sind.) Die laufen aber eben nicht unter Hibiscus sondern unter den entsprechenden Java Laufzeitumgebungen. Wärend Chrome seine eigene SSL lib mitbringt und für Fehler einen CVE eintrag bekommen würde, nimmt Hibiscus die reichlich kaputte von Java. Chrome macht extrem viel selbst. (Weil die Google Leute meinen, dass sie vieles besser könnten als andere.) Auf der einen Seite führt das zu vielen Sicherheitslücken. Auf der anderen Seite waren chrome Nutzer von praktisch keiner Sicherheitslücke die sich so im Umfeld ergab sicher. (Massenhaft privilege escalations im Linux Kernel und diverse Fehler in den Web-libs von Windows.) Das ist im übrigen schon wieder so ein schönes Beispiel: Chrome setzt im Gegensatz zu praktisch jeder anderen Software nochmal eigene Sandboxen ein. Kann da jemand ausbrechen, gilt das als Sicherheitslücke. Da in anderer SW nie was eingesperrt wird, kann da auch nie was ausbrechen. Zusätzliche Sicherheitsfeatures führen so zu zusätzlichen Lücken. Software die von Natur aus total unsicher ist, kann dann auch keine Lücken bekommen. Das hat Java auch so in Verruf gebracht. Die garantieren Speichersicherheit. Da gab es massenhaft Lücken drin. Deswegen zu sagen dass Java unsicher sei ist quatsch. (Auf der anderen Seite ist das natürlich ein Problem sobald sich Leute darauf verlassen, wie das in Applets geschah. Solange das aber eben nur ein zusätzliches Sicherheitsfeature ist, ist das Natürlich nicht unsicherer, nur weil das nicht mehr funktioniert.)

wie man eine Transaktion
mit einem Banking Programm und einem Chipkartenleser Klasse 3 nach Secoder 2 - Standard in einer VM in der nur das Banking - Programm ins Internet kann manipulieren soll? Ich will nicht behaupten, dass das unmöglich ist, jedoch sind die Hürden um ein vielfaches höher als mit einem Browser, bei dem alle paar Wochen ein neues Leck gefunden wird.

Genau da ist es wieder: Es gab massenhaft anfällige Chips die Anfällig waren und dann ausgetauscht wurden. (Vor allem in Brasilien war das wohl gerade Massenphänomen.) Aber natürlich keine Lücken im Standard. Genauso wie es massenhaft Lücken in Browsern gab. Aber eben keine im TLS1.2 Standard.
Und vor allem: Kaum welche die direkt für's Onlinebanking relevant waren. Sie haben dir lediglich bei anderen Tätigkeiten den Rechner versäucht. Und genau da hilft ein eigener Browser genau gleich viel wie eine eigene Bankingsoftware. Bekommt die Mallware ausreichend rechte, kann sie Browser wie HBCI-SW angreifen. Bekommt sie die nicht, ist sie irrelevant fürs Banking.
Mit HBCI+ChipTAN hast du zwei unabhängige Sicherheitssysteme die jeder für sich eigentlich Sicher sein sollten. (Mal abgesehen von Massentransaktionen, wo Chiptan nur bedingt schützt.)
Das gleiche hast du aber auch mit Browser+ChipTAN. Da ist schlicht kein Unterschied.

Steckst du mit HBCI+ HBCI und ChipTAN in eine Tüte, gibt es keine Angriffe mehr weil es meines Wissens niemand gelang gleichzietig ChipTAN UND eine passende TLS Verbindung zu knacken. Deswegen ist HBCI+ immer noch das selbe wie die kombination aus HBCI ChipTAN wo es dann auf beide Teile Angriffe gab.

Mehr Sicherheit geht aber eben durchaus. Die Sicherheit mit BCS Signaturen ist ChipTAN garantiert um Längen überlegen. (Nur als Privater kommst du da nicht so einfach dran.)
Und eigene Hardware fürs Banking ist natürlich in jedem Fall ein Schutz.

[Debian99]

Hi,

also den neuen Kernel habe ich nun installiert. Funktioniert einwandfrei. Man sollte nur vorsichtig bei den Backports umgehen, oder? Also werde ich wohl bei Stable bleiben.

[Evox]

Hi,

also den neuen Kernel habe ich nun installiert. Funktioniert einwandfrei. Man sollte nur vorsichtig bei den Backports umgehen, oder? Also werde ich wohl bei Stable bleiben.

Backports nur sehr sparsam einsetzen und den Multimedia Port noch weniger

Ansonsten viel Spaß mit Debian und "Angst" sollte man nicht haben vor Testing oder Unstable.

BTW:
Unstable (Sid) läuft hier seit Jahren sehr Stabil, ja es gibt immer mal wieder kleinere Probleme aber Dank einer noch recht offenen Kommunikation nicht wirklich weiter schlimm.

[Patsche]

Unstable (Sid) läuft hier seit Jahren sehr Stabil, ja es gibt immer mal wieder kleinere Probleme aber Dank einer noch recht offenen Kommunikation nicht wirklich weiter schlimm.

Manche Sachen lassen sich auch nicht fixxen. Beispielsweise funktioniert der proprietäre Treiber für AMD-Grafikkarten (fglrx-driver)nicht mit dem "neuen" Xorg-Server 1.18 ....
Auch funktioniert mal einen Abend lang keine Maus und keine Tastatur. Dies lag auch am neuen Xserver....da hilft dann nur warten, oder vorher informieren und solch ein Update blocken und die alte Version pinnen. Das ist aber nichts für Laien.
Ansonsten, wenn der Xserver nicht gerade erneuert wird, laufen testing und sid gut.

[sahne99]

@Debian99

Also Debian empfiehlt für fortgeschrittene User unstable als Desktop-System. Für einen Server oder unerfahrenen User stable. Testing wird von Debian als Desktop-System nicht empfohlen.

[thoerb]

Also Debian empfiehlt für fortgeschrittene User unstable als Desktop-System.

Ich habe noch nicht gesehen, dass das irgendwo empfohlen wurde.

Was relativ sicher ist, nach dem Freeze von Stable auf Testing zu gehen. Da ist dann die Wahrscheinlichkeit ziemlich gering, dass in der Zeit zwischen dem Freeze und dem nächsten Stable-Release noch irgendwas zerschossen wird.

[sahne99]

Also Debian empfiehlt für fortgeschrittene User unstable als Desktop-System.

Ich habe noch nicht gesehen, dass das irgendwo empfohlen wurde.

Was relativ sicher ist, nach dem Freeze von Stable auf Testing zu gehen. Da ist dann die Wahrscheinlichkeit ziemlich gering, dass in der Zeit zwischen dem Freeze und dem nächsten Stable-Release noch irgendwas zerschossen wird.

Hier Auszüge von https://www.debian.org/doc/manuals/debi ... ng.de.html

Da heisst es:

Wenn Sie Desktop-Benutzer sind, bereits über etwas Erfahrung mit Linux verfügen und Sie der eine oder andere seltsame Fehler von Zeit zu Zeit nicht stört, dann benutzen Sie unstable. Es bietet topmoderne Software und Fehler werden üblicherweise rasch behoben.

Testing wird deshalb nicht empfohlen, weil kaputte Pakete nicht schnell genug in Testing aufgenommen werden und dadurch sogar monatelang kaputt bleiben können. Sogar das komplette System kann kaputt bleiben monatelang.
Als Beispiel wird folgendes angegeben:

3.1.7 Wie kann es sein, dass Testing monatelang kaputt ist? Würden die in Unstable eingepflegten Fehlerkorrekturen nicht direkt in Testing einfließen?

Die Fehlerkorrekturen und Verbesserungen aus der Distribution Unstable gelangen nur langsam nach einer bestimmten Anzahl von Tagen nach Testing. Nehmen wir an, dieser Wert liegt bei zehn Tagen. Die Pakete in Unstable gelangen erst nach Testing, wenn dafür keine neuen veröffentlichungskritischen Fehler mehr gemeldet werden. Wenn also ein veröffentlichungskritischer Fehler für das Paket vorliegt, wird es auch nicht nach zehn Tagen nach Testing gelangen.

Die Idee ist folgende: wenn das Paket irgendwelche Fehler hat, dann würden diese von Benutzern entdeckt werden, die Unstable verwenden und würden bereinigt, bevor das Paket nach Testing kommt. Das hält Testing für die meiste Zeit in einem benutzbaren Zustand. Insgesamt ein brillantes Konzept. Allerdings sind die Dinge nicht immer so einfach. Überdenken Sie folgende Situation:

Stellen Sie sich vor, Sie wären am Paket XYZ.dd interessiert.

Nehmen wir an, dass am 10. Juni die Version XYZ-3.6 in Testing ist und Version XYZ-3.7 in unstable.

Nach zehn Tagen wandert XYZ-3.7 von Unstable nach Testing.

Also haben am 20. Juni sowohl Testing als auch Unstable XYZ-3.7 in ihren Repositories.

Sagen wir, ein Benutzer der Testing-Distribution bemerkt, dass ein neues XYZ-Paket verfügbar ist und macht ein Update von XYT-3.6 zu XYZ-3.7.

Nun entdeckt am 25. Juni jemand der Testing oder Unstable benutzt, einen veröffentlichungskritischen Fehler in XYZ-3.7 und meldet diesen an das BTS.

Der Betreuer von XYZ behebt den Fehler und lädt ein neues Paket nach Unstable hoch, sagen wir am 30. Juni. Wir nehmen hierbei an, dass der Betreuer fünf Tage braucht, um den Fehler zu beheben und die neue Version hochzuladen. Die Zahl von fünf Tagen sollte hier nicht falsch verstanden werden. Es kann länger dauern oder auch nicht, in Abhängigkeit von der Schwere des vorliegenden veröffentlichungskritischen Fehlers.

Die neue Version ist nun in unstable. Laut Plan soll XYZ-3.8 daraufhin Testing am 10. Juli erreichen.

Aber schon am 5. Juli entdeckt wieder jemand einen veröffentlichungskritischen Fehler in XYZ-3.8.

Nehmen wir an, der Betreuer löst das Problem und lädt die neue Version von XYZ nach fünf Tagen hoch.

Also ist am 10. Juli XYZ-3.7 in Testing und XYZ-3.9 in unstable.

Die neue Version XYZ-3.9 soll nach dem neuen Zeitplan nun am 20. Juli in Testing ankommen.

Nachdem Sie ja Testing verwenden und XYZ-3.7 fehlerhaft ist, könnten sie wahrscheinlich XYZ erst wieder nach dem 20. Juli benutzen. Im Endeffekt hätten Sie dann rund einen Monat lang ein kaputtes Paket XYZ gehabt.

Die Angelegenheit kann noch weitaus komplizierter werden, wenn etwa XYZ von vier anderen Paketen abhängt. Das kann dann zu einer monatelang nicht benutzbaren Testing-Distribution führen. Das soeben vorgestellte Szenario ist zwar konstruiert, kann aber im echten Leben tatsächlich vorkommen. Allerdings geschieht das nur selten.

Aber es heisst auch:

Wenn Ihnen Sicherheit und Stabilität am wichtigsten sind, dann installieren Sie stable. Das ist üblicherweise der bevorzugte Weg.

und

Wenn Sie erstmals Debian benutzen, und es auf einem Desktop-Rechner installieren wollen, beginnen Sie mit stable. Ein Teil der enthaltenen Software ist zwar etwas veraltet, dafür handelt es sich um die am wenigsten mit Softwarefehlern belastete Arbeitsumgebung. Sobald Sie es sich dann zutrauen, können Sie mit wenig Aufwand zum etwas moderneren Unstable wechseln.

[thoerb]

Manche Sachen lassen sich auch nicht fixxen. Beispielsweise funktioniert der proprietäre Treiber für AMD-Grafikkarten (fglrx-driver)nicht mit dem "neuen" Xorg-Server 1.18 ....
Auch funktioniert mal einen Abend lang keine Maus und keine Tastatur. Dies lag auch am neuen Xserver....da hilft dann nur warten, oder vorher informieren und solch ein Update blocken und die alte Version pinnen. Das ist aber nichts für Laien.

Muss halt jeder selber wissen was er macht. Ich habe auf so was keine Lust mehr.