Linux Flame

Bei mir nicht. Dem Satz da oben fehlt "per default".

Ist doch egal ob per Default oder nicht. Linux wird von seinen Fans immer als das sichere Betriebssystem angepriesen. Und oft genug werden Laien überredet diesen Murks als "sichere Windows-Alternative" zu nutzen. Da sollte man wohl erwarten, dass Passwörter nicht unverschlüsselt auf der Platte landen oder wenigstens ein Hinweis erscheint, dass dem so ist und wie man dieses Verhalten ändern kann.
 
Ist doch egal ob per Default oder nicht. Linux wird von seinen Fans immer als das sichere Betriebssystem angepriesen. Und oft genug werden Laien überredet diesen Murks als "sichere Windows-Alternative" zu nutzen. Da sollte man wohl erwarten, dass Passwörter nicht unverschlüsselt auf der Platte landen oder wenigstens ein Hinweis erscheint, dass dem so ist und wie man dieses Verhalten ändern kann.

Das ist ja auch ein bisschen historisch bedingt.
Bei Serversystemen haben wir es ja ständig mit solchen Sachen zu tun: Datenbank Configs, SSH Keys usw. Und wenn jemand den Server aufmacht, haben wir eben ein Problem.

Linux wollte ja auch mal den Servermarkt aufmischen, was ja auch in Sachen Geschwindigkeit geglückt ist, nachdem das Projekt Linux von Google, IBM, Microsoft, Sun, Cisco etc. übernommen worden ist. Klar - da sitzt immer noch ein Linus rum. Aber in den letzten 10 Jahren wurde kein innovativer Codeschnipsel mehr von der "Linux Gemeinde" geliefert. Die Entwicklung wird mittlerweile komplett von Großkonzernen betrieben. Und was die nicht hinbekommen oder wollen, wird sich bei den BSDs geholt.

Die "Linux Gemeinde" darf noch ein bisschen Lizenzwächter spielen und sich den Arsch auf irgendwelchen OSS Konferenzen Plattsitzen.

Jedenfalls - Die "Fans" haben noch immer nicht begriffen dass unter den tollen bunten Bildchen noch immer X wuselt und das so manche "harmlose" Applikation tief in die Kernel-Hose greift und innerhalb des Universums einer "Distribution" von Standardisierung und Harmonisierung keine Rede ist. Da sind MS und Apple Lichtjahre voraus...
 
Linux macht Hardware kaputt: "No POST after rm -rf /"

https://bbs.archlinux.org/viewtopic.php?id=207549
So today me and a friend ran "rm -rf --no-preserve-root /" on a MSI Notebook because we wanted to get rid of the pretty bloated Arch installation.
...
We weren't dumb enough to leave important partitions mounted. We unmounted everything except of root (/).
But the unpleasant surprise came when we tried to boot into the BIOS afterwards:
It didn't work. The screen stays off, the HDD LED turns on for a second but nothing else happens.
Mit Linux ist es also ziemlich einfach, seinen langweiligen Laptop zu einem coolen Schneidebrett umzufunktionieren :)

Die Ursache des Problems ist einfach:
https://github.com/systemd/systemd/issues/2402
Mounting efivarfs read/write by default can lead to accidental deletion of the EFI variables. It was already reported on Arch Linux forums, that running 'rm -rf' over a directory structure with mounted efivarfs did actually "hard-brick" some MSI notebook.

Das Statement eines der Linux-Hauptentwickler lässt aber keine Hoffnung übrig:
poettering commented 6 hours ago
To make this very clear: we actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.
 
systemd

Hallo

@CDW
Das Problem ist doch eher eine Scheiß Implementation von UEFI (sprich firmware) bei MSI.

Soon scheiß haten wir schon öfters
unter Linux bei CD-ROM (Hersteler afaik samsung) + Mandriva , und auch unter win95 bei einigen MB.


Also den Ball mal ein bischen flach halten.

das da MSI Scheiße gebut aht, kann weder systemd noch Poettering was für.

mfg
schwedenmann

P.S. Außerdem sollte man als Admin mit rm sparsam umgehen;)
 
Linux-Sicherheit
.. das ist so wie permanente Serienwiederholung .. immer und immer wieder die gleiche Leier.

Wenn man mal nichts über Linux Bugs hört liegt das jedenfalls nicht daran, dass es nichts zu berichten gibt. Nein - es ist nur auch den Hackern mittlerweile zu öde, ihre credits an Linux Bugs abzureiben.

Das ist so als wenn man mit nem Kescher aus einer Badewanne angelt, die bis zum Rand mit Fischen vollgestopft ist...da klatscht halt auch keiner..
 
Wenn ich aus dem Artikel zitieren darf:

Ein US-Forscher-Team hat Firmware-Images auf Linux-Basis (...)

Die Forscher haben nicht nur die Ergebnisse in "Towards Automated Dynamic Analysis forLinux-based Embedded" Firmware veröffentlicht.


Also geht es hier um Linux Systeme.

Es steht dir außerdem frei, den Rest meiner sachlichen Aussage durch Fakten zu widerlegen..(was wirklich schwer sein dürfte).

Es bleibt auch nach weit über 20 Jahren Entwicklung dabei - Linux ist das unsicherste System auf dem Markt und ist für seriöse Sicherheitsanwendungen eher ein Sodom und Gomorrha als eine echte Option.

Das ist schon recht nah an ner Zwangsstörung, oder?
Das kann sein. Ich musste nach meiner Ausbildung mal 2 Jahre Linux Admin sein und das hat mich doch wirklich geprägt. Das war zu Zeiten wo man noch den Kernel aufgrund von RAM und MHZ der Maschine neu gebaut hat und jedes Update russisches Roulette war. Ok.. die MHZ und das RAM sind kein Problem mehr..der Rest ist aber wie immer...


@Schwede
Soon scheiß haten wir schon öfters
unter Linux bei CD-ROM (Hersteler afaik samsung) + Mandriva , und auch unter win95 bei einigen MB.
Bei Windows 95 war das vor 20 Jahren :D
Aber da lässt sich was ableiten:

1. Linux ist selbstbewusst und besteht darauf, alle Fehler, die andere gemacht haben, auch noch einmal selbst zu machen
2. Linux ist gemütlich und hält einen Innovationsabstand von +- 20 Jahren zu allen anderen (außer die großen Konzerne machen einen Strich durch die Rechnung und
bauen einfach irgendwas neues ein...bähh)
3. Linux ist konservativ: Linus wusste schon aus seiner MINIX Liste, dass sein "neues" Systemmodell schon in den 90ern outdated war. Niemand (außer Linus) hätte ein neues
System nach diesem alten Konzept begonnen. Der Grund war, dass man so die vielen Codes als Vorlage hatte nehmen können, ohne wirklich etwas neues zu erfinden.
 
Also geht es hier um Linux Systeme.

Ok..sorry. Ich hatte dich wohl überschätzt. Ich dachte nicht, dass du zu denen gehörst, die ihre Infos alleine aus Heise Artikeln beziehen. Aber gut, DASS erklärt natürlich einiges.

Es steht dir außerdem frei, den Rest meiner sachlichen Aussage durch Fakten zu widerlegen..(was wirklich schwer sein dürfte).
Sicher, dass du den Artikel nicht etwas durch deine "Ich finde Linux blöd" Brille betrachtet hast? Oder wieso hast du

"Auch konstatieren die Forscher in ihren Ergebnissen kein spezifische Linux-Problem."

überlesen?

Ansonsten: firmadyne/paper.pdf at master * firmadyne/firmadyne * GitHub
 
Ok..sorry. Ich hatte dich wohl überschätzt. Ich dachte nicht, dass du zu denen gehörst, die ihre Infos alleine aus Heise Artikeln beziehen. Aber gut, DASS erklärt natürlich einiges.
Immerhin habe ich überrascht, während deine selektive Aufmerksamkeit beim Lesen solcher Artikel den typischen Fokus aufweist eben Zusammenhänge zu ignorieren.

"Auch konstatieren die Forscher in ihren Ergebnissen kein spezifische Linux-Problem."
Auch ein Laie ohne besondere Schriftkenntnisse sollte hier stolpern.

Es ist richtig, dass die Fehleranfälligkeit von einer bestimmten Art von Geräten kein Linux-spezifisches Problem ist. Dieses Zitat des Autors ist aber kompletter Unsinn (und unter journalistischen Gesichtspunkten ein Fehler), da sich der Artikel nun mal mit "auf Linux basierten" Geräten beschäftigt.

Also haben wir es hier mit einer genauer spezifizierten Untermenge zu tun, nämlich mit Geräten, auf denen Linux läuft.
Und wenn auf diesen Geräten (wenig überraschend) auffällig viele Bugs finden, dann liegt das an dem Umstand, dass da eben Linux drauf läuft. Bzw. liegt die Ursache des Bugs nunmal in der Gerätesoftware, die bei dieser Gruppe eben immer Linux basiert ist.

Würden auf den untersuchten Geräten Linux, Windows, Menutos, OpenBSD und Solaris laufen, wäre das Ergebnis das gleiche: Die meisten (wenn nicht alle) Bugs würde man wieder auf den Geräten finden, auf denen ein Linux System läuft.


Sicher, dass du den Artikel nicht etwas durch deine "Ich finde Linux blöd" Brille betrachtet hast? ...
Ja, ich finde Linux blöd - mit der gleichen Berechtigung wie ich schlecht sitzende Schuhe, Mundgeruch, Geldnot und Krankheit "blöd" finde. Nämlich weil es blöd _ist_.
 
Zitat:
Zitat von Chromatin Beitrag anzeigen
Würden auf den untersuchten Geräten Linux, Windows, Menutos, OpenBSD und Solaris laufen, wäre das Ergebnis das gleiche
Ach sieh an..du hast es ja doch verstanden. Wozu dann das ganze Gehampel?

Das kommt in meine Sammlung "goile Eigentore"!

:thumb_up:
 
Linux

Hallo


@chrom
Das mit mandriva und dem CDROM hat absolut nichts mit Mandriva a ka Linux zu tun. Der Fehler lag bei CDROM Hersteller, der hat bei der Firmware gepatzt. Es gibt ja einen Standard für IDE, das sind für jeden PIN der IDE-Leitung Kommandos vorgesehen, andere PIns waren reserviert (ohne Komamdobelegnung). Geanu diese ungenutzen PINS habne die Mandrivaenntwickler benutzt, nur waren die von Samsung entgegen der Spezifkation von den en mit Kommndos belegt. Ergebnis, CDROM wurde in den Tiefschlaf geschickt und konnte nciht mehr aufgeweckt werden.

Und das mit deinem jetzgen link auf embedged-Linuxe ist nun auch nicht das gelbe vom EI und Linux als Sicherheitsrisiko darzustellen. Wenn man Linux eben nicht korrekt konfiguriert (was ja hier der Fall ist) wird es unsicher. Ein aktuelles, gewartetes Linux ist kein Sicherheitsrisiko und dei Vergleich mit früher hinkt natürlich auch gewaltig, ich habe seit Jahren keinen Kernel mehr kompiliert, oder kompiliern müssen, da ist auch nie was schiefgegangen, außer man patcht den Kernel, möglichst mit obskuren patches (sonst wären sie ja im kernel schon mit drin).

Für mch ist da win das System, das (seit Win10) man getrost als Bot bezeichnen kann, mit Sicherheitslücken so groß und soviele Löcher wie ein schweizer Käse (Stichwort IE) und bei win10 kommt ja noch die Gängelung bei den updates dazu (Stichwort update auf win10, was m.M. schon ganz nahe an den Straftatbestand der Nötigung rankommt.:D

mfg
schwedenmann
 
Und das mit deinem jetzgen link auf embedged-Linuxe ist nun auch nicht das gelbe vom EI und Linux als Sicherheitsrisiko darzustellen. Wenn man Linux eben nicht korrekt konfiguriert (was ja hier der Fall ist) wird es unsicher.

Was heißt hier nicht korrekt gewartet? Die Linux Systeme in den Kisten sind verbuggt. Dabei ist es eine Sache Bugs schnell zu fixen, denn das betrifft alle Systeme (mehr oder weniger). Eine andere Sache ist es aber in einem so "alten" System noch immer Bugs am Fließband zu finden.

Auch haben alle anderen Hersteller mittlerweile die Notwendigkeit umfänglicher Code Audits erkannt und setzen diese mit Erfolg um. Auch waren alle anderen hier und da mal Innovativ bei proaktiven Sicherheitsfeatures - alle außer Linux...

Unterm Schnitt ist es schon fast fahrlässig, auf solchen Geräten überhaupt Linux laufen zu lassen, sofern man da nicht einen anständigen Paketfilter vor stellt...
 
Würden auf den untersuchten Geräten Linux, Windows, Menutos, OpenBSD und Solaris laufen, wäre das Ergebnis das gleiche: Die meisten (wenn nicht alle) Bugs würde man wieder auf den Geräten finden, auf denen ein Linux System läuft.

Windows auf einem WLAN-Router? Ist das dein Ernst? Selbst wenn das klappen sollte, wäre ein seit 6 Jahren nicht mehr gefixtes Windows XP auch nicht besser.
Dass Embedded-Geräte hauptsächlich mit Linux ausgeliefert werden, hat einen einfachen Grund: Spätestens seit Einführung der Device Trees lässt sich kein anderes Betriebssystem so einfach auf die kleinen Kisten bringen. Die Liste der in Linux bereits integrieten Treiber ist überwältigend - da kann weder ein BSD, noch ein Solaris mithalten.
Des Weiteren ist der Kernel selbst eher selten das Problem. Mögliche Sicherheitslücken in der Glibc hat man dann jedoch auch unter Debian/kFreeBSD, wohingegen eine Linux uClib/Busybox-Lösung nicht betroffen sein muss.
Das eigentliche Problem ist aber eher, dass es in Zukunft nicht mehr erlaubt sein wird, eigene Software auf WLAN-Router zu spielen und dass sich die Hersteller der Geräte nicht wirklich um das Thema kümmern.
 
Linux

Hallo

Das eigentliche Problem ist aber eher, dass es in Zukunft nicht mehr erlaubt sein wird, eigene Software auf WLAN-Router zu spielen


Das stimmt so nicht. Es geht i Grunde um die Einhaltung der entsprechenen Vorschriften, was bei einigen freine Roterse nciht gegeben ist, da kann man nämlich am Empfang drehen, sprich die Sendeleisuf außerhalb der Spezifikation hochschrauben, was dann die Post mit ihren entsprechndn Prüfwagen auf den Plan ruft.
Im übrigen hat afaik tp-link schon angekündigt, weiterhin firmware auszuliefern, die das Aufspielen freier Routersw erlaubt.

mfg
schwedenmann
 
Ist doch schön zu sehen, dass wenigstens eine (vll ein paar) Firma mitdenkt, und dem User die Möglichkeit gibt, sein Device wirklich einfach zu rooten.
Also von mir +1
 
Zurück
Oben