Ahoi! ich bin erst kürzlich von Win7 auf Win10 umgestiegen, was sich aber im nachhinein als Fehler entpuppte :-( Mit Win10 werde ich nicht wirklich warm. Mir gefällt der Explorer nicht, ich sehe den breiten Cortana "Balken" als störend an und die dauernden Meldungen in der komischen Sprechblase unten rechts nerven auch allmählich. Auf lange Sicht möchte ich mich eigentlich garnicht in Win10 einarbeiten, u.a. auch wegen den dubiosen Datenschutzrichtlinien - Also kommt Linux! soweit ich irgendwelche Programme benötige habe ich das schon abgeklärt, ob es unter Linux alternativen für mich gibt. Was ich nicht ganz verstehe ist, wieso Linux "an sich" sicherer sein soll als Windows? für mich als Linux-newbie sehe ich in einem neuem System erstmal eine (Bediener-)Schwäche. Abgesehen davon sollte es unter Linux doch genausso Viren und Trojaner geben, die man sich beim surfen dank Javascript einfängt!? wer sagt dass ein JPG nicht mit einem Trojaner ausgestattet werden kann, so dass ein bloßes Betrachten des JPGs infizierten code ausführt? unter Win gibt es auch sowas... Momentan sehe ich Linux nur deshalb sicher, da die Verbreitung nich so groß wie bei Win ist und es sich für Programmiere einfach nicht rechnet, für eine so kleine Zielgruppe einen virus zu programmieren, oder?
Fritz vom Deich schrieb: > Was ich nicht ganz verstehe ist, wieso Linux "an sich" sicherer sein > soll als Windows? Weil's keiner benutzt, Nutzerzahlen unter 1.5% http://de.statista.com/statistik/daten/studie/157902/umfrage/marktanteil-der-genutzten-betriebssysteme-weltweit-seit-2009/ und die meisten sind arme Schlucker die sich keinWindoof leisten können ei denen man nichts klauen kann. AmigaOS ist noch sicherer.
Software kommt fast immer aus signierten Paketquellen und nicht von dubiosen Webseiten, damit ist halt der #1 Angriffsvektor schonmal weg. Klar, Sicherheitslücken etc. gibt es genauso, aber es ist weniger lohnend die anzugreifen weil es viel weniger Benutzer gibt, die Benutzer typischerweise ein technisch höheres Niveau haben, und das ganze Ökosystem sehr viel heterogener ist als unter Windows.
Es gibt Ausnahmen (Heartbeat), aber im Allgemeinen werden OpenSource Programme von mehreren unabhängigen Augen betrachtet, denen eine Sicherheitslücke auffällt und als Bugreport die Verbreitung einer solchen verhindert. Da zudem die meisten Linuxprogrammierer nicht besonders profitorientiert sind, ist die Lust zur Datensammelei von Benutzern deutlich geringer. Schöne Ausnahme auch hier wieder: Android.
MaWin schrieb: > und die meisten sind arme Schlucker die sich keinWindoof leisten können > ei denen man nichts klauen kann. Du weist das man nen win7 bei amazon für 15€ bekommen kann? das kann man dann auf win10 Updaten. Außerdem ist es wirklich schwer günstig an nen PC zu kommen der keine Windows-Lizenz mitbringt. Ich kenn ja viele Gründe Linux oder Windows einzusetzen. Im privaten Umfeld sind Lizenzkosten fürs OS keiner davon. Bedien dich doch auch an den von Karl angebotenen Fischen :)
es liegt wohl kaum am geld ;-) wie ist das mit den unterschiedlichen Distributionen geregelt. Ich könnte mit ein Mint oder ubuntu installieren, beide haben Gnome als Desktopoberfläche und wenn mir etwas fehlen sollte, so kann ich nahezu jedes Linux-Programm bei beidenen nachinstallieren, richtig? Ich meine, es spielt dann also erstmal keine Rolle ob ich Ubuntu oder Mint nehme, wenn ich ein bestimmtes Programm suche kann ich es bei beiden Distributionen nachinstillieren?
sorry für die Rechtschreibfehler, ich wollte es nochmal durchlesen und habe aus versehen auf "Absenden" anstelle von "Vorschau" geklickt :-(
Karl schrieb im Beitrag #4597078:
> Hier ist dein Fisch
1 | | I wouldn't do that |
2 | | if I were you... |
3 | : / |
4 | J / |
5 | o\_ /o |
6 | ~~~~~~~~~/(_/~~~ ~~~(__\~~~ ~~~~~~ b'ger |
Fritz vom Deich schrieb: > groß wie bei Win ist und es sich für Programmiere einfach nicht rechnet, > für eine so kleine Zielgruppe einen virus zu programmieren, oder? Waere das schlimm? Eher nicht. bisl aelter, passt aber immer noch. http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Bei der Gelegenheit mal gucken wo eine IBM ueberall Linux aufsetzt. Auch als graphische Oberflaeche zur (klein)Server Administration ist das oft ein Ubuntu.
Ich bin von Xp zu Ubuntu gewechselt. Grund war auch bei mir das ich einfach keine Lust hatte mich mit einem neuen Windows anzufreunden. Bereut habe ich es bis heute nicht. Es gibt einfach weniger angriffe auf Linux Systeme weil sich das für die Angreifer kaum lohnt. Zuviel Arbeit bei zu wenig User. Ob du mit Linux glücklich wirst liegt natürlich auch an dir. Wenn man ein Problem hat muss man länger im Netz nach einer Lösung suchen weil auch weniger User dieses Problem beschreiben. Aber ich würde sagen wenn das System einmal läuft läuft es auch ordentlich stabil. Man kann über Wine & Co sogar viele Windows Programme einfach unter Linux verwenden. Oder man installiert gleich noch ein Virtuelles Windows 7 mit dazu. Das kann man vom Internet Trennen. Da kann man viel ausprobieren und über Snapshots immer wieder zum Heilen zustand zurück springen. Mit der zeit wirst du für fast alle Programme gute alternativen finden.
Hi Fritz, Du kannst mit Ubuntu fast nichts falsch machen. Lediglich zu beginn solltests du deine Privatsphäre schützen und ein besuch bei den "Profis" https://wiki.ubuntuusers.de/Einsteiger/ lohnt sich auch mal. Ich bin mit der gesammten Familie seit 10 Jahren auf Ubuntu umgestiegen und habe keine "Support anfragen" mehr, es erklärt sich alles selbst und es Funktioniert einfach :-) Selbst auf meinem Alten IBM X40 mit nur 1,2GHz und 1GB Ram keine Probleme und Stabiel. Selbst 90% der "gekauften" Windowssoftware läuft super und viel schneller. Viel spaß beim Ausprobieren ;-)
Sven schrieb: > Ich bin von Xp zu Ubuntu gewechselt. Grund war auch bei mir das ich > einfach keine Lust hatte mich mit einem neuen Windows anzufreunden. Ich bin von XP auf Win7 gewechselt! Grund war auch bei mir das ich einfach keine Lust hatte mich mit diesem Linux anzufreunden! Sven schrieb: > Bereut habe ich es bis heute nicht. Es gibt einfach weniger angriffe auf > Linux Systeme weil sich das für die Angreifer kaum lohnt. Bereut habe ich es bis heute nicht! Es gibt bei mir einfach keine Angriffe, weil ich meine Sicherheitskonfiguration im Griff habe
> Selbst 90% der "gekauften" Windowssoftware läuft super und viel schneller.
Bist du die Märchentante oder kannst du erklären warum Windowssoftware
auf deinem Linux schneller läuft? Um welche Windowssoftware handelt es
sich überhaupt?
Was bedeuten die Anführungszeichen im Satz? Das du die Software geklaut
hast?
>Ich bin von XP auf Win7 gewechselt! Grund war auch bei mir das ich >einfach keine Lust hatte mich mit diesem Linux anzufreunden!> > >Sven schrieb: >> Bereut habe ich es bis heute nicht. Es gibt einfach weniger angriffe auf >> Linux Systeme weil sich das für die Angreifer kaum lohnt. > >Bereut habe ich es bis heute nicht! Es gibt bei mir einfach keine >Angriffe, weil ich meine Sicherheitskonfiguration im Griff habe Ich kugle mich vor lachen, dieser Witz ist ein echter Brüller! :o)
Ich finde Windows einfach zu umstänmdlich: 1. Man muss sich ständig darum kümmern welchen Virenscanner man installiert und ob dieser noch aktuell und gut ist. Trotzdem muss man immer Angst vor unbekannten Mailanhängen haben. 2. Man muss sich zu seiner Hardware die ganzen Treiber händisch im Internet zusammen suchen. Zu alter Hardware findet man oft nichts. Bei Linux funktioniert alles ohne sich darum kümmern zu müssen. Nur wenn man ganz neue Hardware kaufen will sollte man sich vorher informieren ob das auch von Linux unterstützt wird. Doch das ist bei der ohnehin notwendigen Produktrecherche bei einer Neuanschaffung kein wirklicher Mehraufwand 3. generell werden neue Entwicklungen von Linux früher unterstützt als von Windows, siehe große Festplatten, diverse neue CPUs, USB3.0,... 4. Bei Linux wird so ziemlich alle Software von der Distribution angeboten, ist mit wenigen Klicks (oder über Kommandozeile) installiert und wird automatisch aktuell gehalten.
Bernd schrieb: > Ich finde Windows einfach zu umstänmdlich: > > 1. Man muss sich ständig darum kümmern welchen Virenscanner man > installiert und ob dieser noch aktuell und gut ist. Trotzdem muss man > immer Angst vor unbekannten Mailanhängen haben. wird bei Linux auch noch kommen. > 2. Man muss sich zu seiner Hardware die ganzen Treiber händisch im > Internet zusammen suchen. Zu alter Hardware findet man oft nichts. Bei > Linux funktioniert alles ohne sich darum kümmern zu müssen. Nur wenn man > ganz neue Hardware kaufen will sollte man sich vorher informieren ob das > auch von Linux unterstützt wird. Doch das ist bei der ohnehin > notwendigen Produktrecherche bei einer Neuanschaffung kein wirklicher > Mehraufwand genau andersrum, bei Linux muss man sich vorher Informieren ob seine Hardware wirklich läuft. Siehe aktuelle Notebooks. Wenn man einen Treiber braucht, muss man alles selber kompilieren was auch mal stunden dauert auf einen Raspi. (z.b. für den CP2102). Beim nächsten Kernelupdate darf man es wieder machen, weil man keine Treiber von einer Version auf die nächste mitnehmen kann. > 3. generell werden neue Entwicklungen von Linux früher unterstützt als > von Windows, siehe große Festplatten, diverse neue CPUs, USB3.0,... Linux hängt immer hinterher, wenn es im Stromsparen geht. Da ist Windows meist schon viel weiter. > 4. Bei Linux wird so ziemlich alle Software von der Distribution > angeboten, ist mit wenigen Klicks (oder über Kommandozeile) installiert > und wird automatisch aktuell gehalten. mag ja eventuell gut sein. Wenn man aber wirklich mal eine älter Software braucht artet das dann in tausend Versionskonflinkten aus.
Ich finde es interessant wie die Linux-User generell den Windows-User erklären wie dumm sie sind! Schon mal daran gedacht das auch Windows seine Berechtigung hat?
Marc H. schrieb: > Ich finde es interessant wie die Linux-User generell den Windows-User > erklären wie dumm sie sind! Ist andersrum aber auch nicht besser, eher schlimmer. Weil viele Windowsuser die gebrachten Argumente gar nicht lesen/verstehen wollen (siehe hier: Linux und neue Hardware) sondern nur stänkern wollen. Marc H. schrieb: > Schon mal daran gedacht das auch Windows > seine Berechtigung hat? Ja. Diese Anwendungen gibt es sicher, besteitet ja keiner. Was aber nicht am System selber liegt, sondern an den verfügbaren Anwendungen. Peter II schrieb: >> 1. Man muss sich ständig darum kümmern welchen Virenscanner man >> installiert und ob dieser noch aktuell und gut ist. Trotzdem muss man >> immer Angst vor unbekannten Mailanhängen haben. > wird bei Linux auch noch kommen. Warum? Bei Linux werden Bugs schneller erkannt und schneller behoben. Wozu braucht man da eine externe Frickelware? Bei Windows wird der Bug erstmal vertuscht dann nach einem Monat (gut in letzter Zeit auch mal schneller), nach ein paar Jahren, oder gar nicht, behoben. Peter II schrieb: > genau andersrum, bei Linux muss man sich vorher Informieren ob seine > Hardware wirklich läuft. Siehe aktuelle Notebooks. Was hast du an meiner Aussage bezüglich neuer Hardware und Linux nicht verstanden? Genau das selbe habe ich doch geschrieben! Aber hauptsache mal gestänkert. Peter II schrieb: > Wenn man einen Treiber braucht, muss man alles selber kompilieren was > auch mal stunden dauert auf einen Raspi. (z.b. für den CP2102). Beim > nächsten Kernelupdate darf man es wieder machen, weil man keine Treiber > von einer Version auf die nächste mitnehmen kann. Toller Vergleich mit dem Raspberry lach
Bernd schrieb: > Warum? > Bei Linux werden Bugs schneller erkannt und schneller behoben. Wozu > braucht man da eine externe Frickelware? > Bei Windows wird der Bug erstmal vertuscht dann nach einem Monat (gut in > letzter Zeit auch mal schneller), nach ein paar Jahren, oder gar nicht, > behoben. Was haben Bugs mit Virenscanner zu tun? Wenn ein User ein Virus aus dem Netz lädt braucht es keine Bugs sondern nur einen DAU Peter II schrieb: > > Wenn man einen Treiber braucht, muss man alles selber kompilieren was > > auch mal stunden dauert auf einen Raspi. (z.b. für den CP2102). Beim > > nächsten Kernelupdate darf man es wieder machen, weil man keine Treiber > > von einer Version auf die nächste mitnehmen kann. > Toller Vergleich mit dem Raspberry lach achso, du bekommst also aktuellen Treiber für den CP2102 auf einem PC ohne Kompilierern?
Peter II schrieb: > Was haben Bugs mit Virenscanner zu tun? Wenn ein User ein Virus aus dem > Netz lädt braucht es keine Bugs sondern nur einen DAU Was hat ein Trojaner mit einem Virus zu tun?
Fragender schrieb: > Was hat ein Trojaner mit einem Virus zu tun? für beides ist ein Virenscanner zuständig.
Der Sicherheitsvorteil von Linux kommt daher, weil sich die meisten Angriffe gegen Linux auf Serveranwendungen konzentrieren. Der Desktop lohnt sich nicht als Angriffsziel. Der nächste Vorteil ist, dass man sich als Linux-User aktiv für das OS entschieden hat und es selber installiert hat. In den meisten Fällen hat man ein gewisses Grundwissen. Hinzu kommt noch, dass die Rechteverwaltung nicht auf Komfort sondern auf Sicherheit ausgelegt ist. Deshalb muss man bei jedem Update und jeder Installation ein Passwort eingeben. Es können immer noch die eigenen Daten verschlüsselt werden, aber der Kernel bzw das OS bleibt meist verschont. Das alles gilt natürlich nur, wenn man weiß auf was man klickt und welche Befehle man ausführt. Einfach Copy&Paste aus irgendwelchen Anleitungen ist immer gefährlich.
Ich mische mich nur selten in den angeblichen Wettstreit Windows vs. Linux ein, da ich beide Systeme nutze (teilweise nutzen muss). Nur wie so oft werden Fehlinformationen, Vorurteile und auch Hass gegen die jeweilige andere Fraktion gestreut, die absolut unerträglich sind. Meinungen sind ok. Wenn ich bei manchen Dingen hier falsch liege, liegt es daran, dass ich beruflich wie privat nur die Systeme nutze und kein (System-)Programmierer bin. >> 1. Man muss sich ständig darum kümmern welchen Virenscanner man >> installiert und ob dieser noch aktuell und gut ist. Trotzdem muss man >> immer Angst vor unbekannten Mailanhängen haben. > wird bei Linux auch noch kommen. Ach... Und das Einfallstor Outlook (Word als Editor/Viewer, Vorschau mit IE) gibt es auch für Linux? Ich kenne kaum ein Mailprogramm, dass so unsicher konfiguriert geliefert wird wie Outlook. Das Anhänge nach Jahren erst von der Ausführung direkt in Outlook gesperrt wurden, dass zeigte eben, wie man im Hause Microsoft die Bequemlichkeit der User der Sicherheit den Vorzug gegeben hat. Neben den Missachtungen von RFCs abgesehen... >> 2. Man muss sich zu seiner Hardware die ganzen Treiber händisch im >> Internet zusammen suchen. [...] > genau andersrum, bei Linux muss man sich vorher Informieren ob seine > Hardware wirklich läuft. Siehe aktuelle Notebooks. > > Wenn man einen Treiber braucht, muss man alles selber kompilieren was > auch mal stunden dauert auf einen Raspi. (z.b. für den CP2102). Beim > nächsten Kernelupdate darf man es wieder machen, weil man keine Treiber > von einer Version auf die nächste mitnehmen kann. Schon ist dein Beispiel widerlegt: CONFIG_USB_SERIAL_CP210X=m im Kernel 4.6 (aktuell hier im Einsatz). Eine kurze Recherche ergab sogar schon für Kernel 3.13 einen Treffer. Es gibt nur wenige Treiber, die nicht in den Kernel zu finden sind (wegen schlechtem Design, wegen fehlender Herstellerunterstützung/Patentfragen oder mangels Notwendigkeit). Ansonsten einfach mal unter Staging schauen und sich vielleicht ärgern, dass die Packer der Lieblingsdistro den benötigten Treiber nicht mit kompiliert haben. >> 3. generell werden neue Entwicklungen von Linux früher unterstützt als >> von Windows, siehe große Festplatten, diverse neue CPUs, USB3.0,... > Linux hängt immer hinterher, wenn es im Stromsparen geht. Da ist Windows > meist schon viel weiter. Beim Stromsparen ist Linux bei Notebooks im Hintertreffen. Wegen teilweiser fehlerhafter ACPI-Tabellen war Stromsparen sogar unmöglich. Deine Aussage "immer" ist falsch. USB (egal welche Version) entspricht fast komplett den Zielen dieser Schnittstelle: einstöpseln, läuft. Windows braucht ja für fast jeden USB-Hardwaremist Treiber. USB-Sticks sind Storage-Devices und brauchen auch nur den Storage-Treiber. Das Protokoll gibt ja vor, was für ein Gerät da angemeldet werden will. USB-Stick rein, OS erkennt Storage-Device, lädt den Generic-Treiber und fertig. Auswerfen ist auch notwendig, sonst spinnt Windows gerne mal. Frage: Warum muss man manche USB-Serial-Konverter auswerfen?. Bei Storage-Devices ist das ja sinnvoll (und unter Linux auch nicht anders). Auch kann Windows nicht mit den IDs von USB-Geräten richtig umgehen. Bei vielen Sticks installiert Windows seine Treiber neu, wenn man ihn nur an einem anderen Port anstöpselt. Ob neuere Versionen (ich kenne nur Win bis 7 aus der Praxis) da besser geworden sind, bezweifel ich. >> 4. Bei Linux wird so ziemlich alle Software von der Distribution >> angeboten, ist mit wenigen Klicks (oder über Kommandozeile) installiert >> und wird automatisch aktuell gehalten. > mag ja eventuell gut sein. Wenn man aber wirklich mal eine älter > Software braucht artet das dann in tausend Versionskonflinkten aus. Selbst kompilieren. Ist aber nicht jeder Mann/Frau zuzumuten, zugegeben. Unter Windows kann man ältere Software oft nur eingeschränkt oder gar nicht mehr nutzen. Treibermodelle wurden früher mit jeder neuen Windowsversion geändert (u.a. bei Scanner, Drucker), so dass man auf den Hersteller warten musste. Teilweise wurden Geräte nur für eine einzige Windowsversion hergestellt und waren danach funktionsfähiger Schrott. Man sieht, dass beide (oder alle) Betriebssysteme Vor- und Nachteile haben. Daher gilt, dass man das OS nach seinen eigenen Anforderungen auswählt. Linux ist nun mal nicht für den Otto-Normal-Nutzer gedacht, der sich nicht einarbeiten will (siehe u.a. LIMUX-Projekt, bei denen Nutzer über Dinge meckern, die anders als unter Windows laufen, aber einfach gehen). Windows deckt einen großen Userkreis ab, ist wie iOS von Apple allerdings geschlossen. Freie Software gibt es auch dort, aber man kennt ja von der Arbeit meist nur die kostenpflichtigen Programme und die will man auch privat nutzen. BSD stelle ich der Einfachheit mal auf die Stufe mit Linux (auch wenn es nicht stimmt). Udo
Udo N. schrieb: > Ach... Und das Einfallstor Outlook (Word als Editor/Viewer, Vorschau mit > IE) gibt es auch für Linux? Ich kenne kaum ein Mailprogramm, dass so > unsicher konfiguriert geliefert wird wie Outlook. du redest über 15Jahre alte Software, schon mal ein aktuelles Windows und Outlook gesehen? Udo N. schrieb: > Schon ist dein Beispiel widerlegt: CONFIG_USB_SERIAL_CP210X=m im Kernel > 4.6 (aktuell hier im Einsatz). Eine kurze Recherche ergab sogar schon > für Kernel 3.13 einen Treffer. leider ist das eine veraltete Version vom Treiber, dieser unterstützt die IO-Pins nicht. Beim Hersteller gibt es dafür einen neuen Treiber.
Peter II schrieb: > du redest über 15Jahre alte Software, schon mal ein aktuelles Windows > und Outlook gesehen? Und Microsoft hat 20 Jahre gebraucht um ein System zu entwickeln das nur annähernd an Linux und die anderen UNIX-artigen Systeme heranreicht. Dabei war Linux für Microsoft schon immer ein Ansporn. Ohne Linux wäre Windows heute noch so unsicher wie vor 20 Jahren und die Netzwerkfunktionen würden das System noch immer zum Absturz bringen. Schonmal um 1995 ein Windows im Netzwerk benutzt? Peter II schrieb: > leider ist das eine veraltete Version vom Treiber, dieser unterstützt > die IO-Pins nicht. Beim Hersteller gibt es dafür einen neuen Treiber. Und unterstützt Windows das?
Name1 schrieb: > Peter II schrieb: >> leider ist das eine veraltete Version vom Treiber, dieser unterstützt >> die IO-Pins nicht. Beim Hersteller gibt es dafür einen neuen Treiber. > > Und unterstützt Windows das? ja, einfach Treiber laden und installieren. Name1 schrieb: >> du redest über 15Jahre alte Software, schon mal ein aktuelles Windows >> und Outlook gesehen? > > Und Microsoft hat 20 Jahre gebraucht um ein System zu entwickeln das nur > annähernd an Linux und die anderen UNIX-artigen Systeme heranreicht. > Dabei war Linux für Microsoft schon immer ein Ansporn. Ohne Linux wäre > Windows heute noch so unsicher wie vor 20 Jahren und die > Netzwerkfunktionen würden das System noch immer zum Absturz bringen. > Schonmal um 1995 ein Windows im Netzwerk benutzt? und Linux hat sich leider in der Zeit nicht weiterentwickelt. ACL sind unter Linux ein Kramp. Root darf alles User nichts. Damit kann man nicht sinnvollvoll aufgaben an andere Personen abgeben. Thread können nicht den Eigentümer wechseln. bräuchte man z.b. für den Apache. Dafür müsste man den Apache als root laufen lassen, das will aber auch niemand. Solche dinge gehen aber unter Windows, eventuell sollte Linux auch mal etwas von Windows abschauen.
Fritz vom Deich schrieb: > Was ich nicht ganz verstehe ist, wieso Linux "an sich" sicherer sein > soll als Windows? schlicht weil (ein desktop) linux weniger weit verbreitet ist als windows - es lohnt sich nicht exploits zu schreiben. aber auch weil viele automatismen die aus der windowswelt wohlbekannt sind bei linux nicht genutzt werden, "autostart" zum beispiel, oder das standardmäßige rendern von HTML-mails, etc pp. sicher ist jedoch, das jedes system das eingaben verarbeitet sich dabei verhaspeln kann, und diese fehler ausgenutzt werden können. eine eingabe ist zum beispiel diese microcontroller.net-seite - wenn mein browser einen bug hat (hat er! ;), kann diese eingabe genutzt werden um code auszuführen. da helfen nur weitere sicherungsmaßnahmen, die allerdings auch unter windows gelten: adblocker (auf µc.net zwar deaktiviert, bekomme aber trotzdem nichts angezeigt), noscript, random agent spoofer (um die browsersoftware/version zu verschleiern), flash deinstallieren… also die menge an code minimieren durch den daten laufen. linux ist vielleicht auch deswegen sicherer, weil jemand der sich entscheidet linux zu verwenden auch ein erhöhtes interesse an sicherheit hat, und deswegen vorsichtiger ist als "otto-normaluser".
Peter II schrieb: > Thread können nicht den Eigentümer wechseln. bräuchte man z.b. für den > Apache. Dafür müsste man den Apache als root laufen lassen, das will > aber auch niemand. > Solche dinge gehen aber unter Windows, eventuell sollte Linux auch mal > etwas von Windows abschauen. Meh, unter Windows kann ich nichtmal ein olles PDF überschreiben während es im krautigen PDF-Betrachter offen ist. Das wäre mir als Benutzer wichtiger als Threads die den Besitzer wechseln. SCNR Außerdem gibt es ja setuid(), ich würde mal vermuten damit kann man sich basteln was man braucht wenn man wirklich will ...
:
Bearbeitet durch User
Fritz vom Deich schrieb: > es liegt wohl kaum am geld ;-) ;-) > wie ist das mit den unterschiedlichen Distributionen geregelt. Ich > könnte mit ein Mint oder ubuntu installieren, beide haben Gnome als > Desktopoberfläche und wenn mir etwas fehlen sollte, so kann ich nahezu > jedes Linux-Programm bei beidenen nachinstallieren, richtig? > > Ich meine, es spielt dann also erstmal keine Rolle ob ich Ubuntu oder > Mint nehme, wenn ich ein bestimmtes Programm suche kann ich es bei > beiden Distributionen nachinstillieren? Ja, kannst Du.
Sven schrieb: > Ich bin von Xp zu Ubuntu gewechselt. Grund war auch bei mir das ich > einfach keine Lust hatte mich mit einem neuen Windows anzufreunden. > Bereut habe ich es bis heute nicht. Es gibt einfach weniger angriffe auf > Linux Systeme weil sich das für die Angreifer kaum lohnt. Zuviel Arbeit > bei zu wenig User. Das Gerücht, Linux werde aufgrund seines geringen Marktanteils so selten angegriffen, ist längst widerlegt. De facto gibt es eine riesige Anzahl an Linux-Systemen auf Servern und Embeddedgeräten, die zwar äußerst lohnende Ziele darstellen, aber trotzdem extrem selten und wenn, dann zuallermeist erfolglos angegriffen werden. Wenn die Verbreitung die Rolle spielen würde, die Windows-Apologeten oft als eher hilflose Erklärung dafür anbieten, daß ihre Software so häufig angegriffen wird, dann wäre der am verbreitetste Webserver Apache der am häufigsten angegriffene. Tatsächlich war es aber der weniger verbreitete IIS, der öfter, und viel öfter auch erfolgreich angegriffen wurde. Ob Softwaresysteme häufiger angegriffen werden, liegt also nicht an deren Verbreitung, sondern an anderen Faktoren: wie leicht läßt sich das System knacken, wie hoch ist das Erkennungsrisiko, wie groß ist das Risiko, daß der Angriff zum Angreifer zurückverfolgt werden kann. In allen diesen Bereichen hat Linux Vorteile: Linux-User haben sich bewußt für dieses System entschieden und dürften daher durchschnittlich bessere Computer- und Sicherheitskenntnisse haben. Linux-Distributionen sind sehr heterogen: dasselbe Programm, das unter Distribution X mit einem Exploit oder Trojaner A angegriffen werden kann, ist unter Distribution Y anders übersetzt und daher gegen den Exploit oft immun. Linux-Systeme tun sehr viel für die Sicherheit: angefangen bei einem eingängigen, konsistenten Berechtigungskonzept für Benutzer, Dateien und Prozesse bis hin zu eher technischen Lösungen wie der Address Space Randomization. Außerdem sind Linux und Linux-Anwendungen oft viel besser dokumentiert als kommerzielle Software, bei der sich der Hersteller noch an dem Verkauf von Informationen zu seiner Software bereichern möchte -- oder lieber weniger aussagekräftige Dokumentation liefert in der Hoffnung, daß ihn niemand auf zugesagte Features festnageln kann. Bei vielen kommerziellen Programmen ist die mitgelieferte EULA umfangreicher als die Dokumentation -- das gilt auch für Windows selbst, dessen "Hilfe" nach drei Fragen allzu oft in dem lapidaren Hinweis endet, man möge seinen Systemadministrator fragen. ;-) Und dann gibt es noch einen Riesenvorteil: unter Linux werden mit einem einzigen Befehl nicht nur das Betriebssystem, sondern auch alle Treiber und alle installierten Anwendungen aktualisiert. Unter Windows muß man sowas meist von Hand machen, was relativ aufwändig ist und deswegen oft dazu führt, daß zwar das System aktuell ist, installierte Treiber und Anwendungen jedoch oft vernachlässigt werden. Die Vorteile mögen nicht sehr groß sein, aber sie reichen aus, damit ein Linux-Benutzer weniger oft angegriffen wird als ein Windows-Benutzer. Und letztlich ist es für den einzelnen Benutzer ja auch nur wichtig, daß er weniger oft angegriffen wird -- warum, ist für ihn nebensächlich. ;-) Trotzdem: Sicherheit steht und fällt unter allen modernen Systemen vor allem mit dem Verhalten des Benutzers, und weniger mit der verwendeten Technik. Insofern gilt es, einen kühlen Kopf zu bewahren und nicht auf alles zu klicken, das blinkt -- und die Dokumentation, die Logdateien sowie die vorhandenen Sicherheitsfeatures zu benutzen.
Sven B. schrieb: > Peter II schrieb: >> Thread können nicht den Eigentümer wechseln. bräuchte man z.b. für den >> Apache. Dafür müsste man den Apache als root laufen lassen, das will >> aber auch niemand. >> Solche dinge gehen aber unter Windows, eventuell sollte Linux auch mal >> etwas von Windows abschauen. > > Meh, unter Windows kann ich nichtmal ein olles PDF überschreiben während > es im krautigen PDF-Betrachter offen ist. Das wäre mir als Benutzer > wichtiger als Threads die den Besitzer wechseln. SCNR Ich benutzte beide Systeme und möcht mich nicht zu viel einmischen, aber das ist Blödsinn. Schuld daran sind die gängigen PDF Reader. (Adobe, Foxit) Wenn ich LaTex schreibe habe ich immer den Sumatra-PDF offen, der lockt die offenen PDFs nicht und hat kein Problem die Dateien zu aktualisieren.
ich hatte früher (vor 10 Jahren) nur Windows, danach Dual-Boot Win+Linux, und nachdem ich die Vorteile von Linux erkannt hatte nur mehr Linux installiert. Da man für ein paar Anwendungen noch Windows braucht, läuft ein Win10 in einer VM. Dort ist es sehr gut aufgehoben. In der VM kann ich es leicht reparieren und ganz einfach Backups des kompletten Systems machen, sodass überladene Registry, kaputte Treiber usw. keinen Schaden mehr anrichten können. Inzwischen läuft Linux hier auf 6 PCs, private und für den Job, seit fast 8 Jahren, teilweise im 24/7 Dauerbetrieb und es gab kein einziges Mal irgendein Sicherheitsproblem. So Dinge wie OnlineBanking sind unter Windows eine Zitterpartie, aber kein Problem mit Linux. Aber, es gibt auch ein Linux dass potentiell unsicher ist, deutlich unsicherer als jede Windowsversion, und das heißt: Android. Wer mit Android OnlineBanking macht, kann seine Kontodaten gleich öffentlich zur Schau stellen.
> Momentan sehe ich Linux nur deshalb sicher, da die Verbreitung nich so > groß wie bei Win ist und es sich für Programmiere einfach nicht rechnet, > für eine so kleine Zielgruppe einen virus zu programmieren, oder? Hmm, weiss nicht. So klein ist die Zielgruppe keineswegs. Ich denke schon das sich das rechnen würde. Eigentlich halte ich die gerne propagierte Sicherheit von Linux-/Unix-Systemen auch eher für Augenwischerei. Die Sicherheit eines Systems hängt in allererster Linie vom User ab; davon wie sehr er sich um Sicherheit bemüht. Das ist unter Linux auch nicht anders als unter Windows (obgleich bei Windows möglicherweise weniger Klimmzüge nötig sind um das System zu kompromittieren). Gerne angebrachte Argumente sind dabei: - "Malware im Userspace kann das System selber nicht beeinflussen, da hierzu root-Rechte notwendig wären" Naja, was kümmert mich als Privatanwender das System? Das kann ich alle Tage neu aufsetzen. Die Daten im meinem Userspace sind dagegen kritisch! Wenn jemand meine Emails liest, meine Bankverbindung ausspäht oder meine Fotosammlungen der letzten 10 Jahre löscht, das wäre für mich ein ernsthaftes Problem. Das wird von Linux aber auch nicht verhindert wenn ich (als User) mir irgendwo Malware einfange. - "Software ist i.d.R. als Quellcode erhältlich, da würde Malware sofort auffallen" Ach so? Wer studiert denn die ganzen Quellcodes sorgfältig, Zeile für Zeile, ob da nicht Sicherheitslücken aller Art drin enthalten sind? Kennt man denjenigen persönlich und weiss ob dessen Vertrauenswürdigkeit (oder auch nur ob diese Person überhaupt existiert)? Und bürgt derjenige für irgendetwas? Nun, offenbar nimmt auch open-source-software kein Mensch auf der Welt hinreichen genau unter die Lupe, wie man ja z.B. bei Heardblead gesehen hat. Ganz ehrlich, wenn ich Malware unter Linux verbreiten wollte dann würde ich sie in irgendeinem "langweilen" Teil einer open-source-software verstecken, wohlwissend das sich das kein Mensch genauer anschaut. Dazu noch eine Webseite aufsetzen, auf der steht das sich ein Dutzend Programmierer (Peter P., Francois F., Chang C. u.a.) an dem Projekt beteiligen, und schon scheint jeder zu glauben das die Software 100%ig sicher sei. - "Da Linux-/Unix-Systeme heterogen sind kann sich Malware nicht aktivieren oder verbreiten; in jedem System wären die dazu notwendigen Mechanismen anders" Pfft. Es gibt mehr als genug plattformunabhängige Wege um Schaden anzurichten. GCC, Java, Flash, Perl, Bash etc. pp. dürften hinreichend weit verbreitet sein. Auch in Makefiles kann man Schindluder treiben. Und wer studiert schon jedes einzelne Makefile oder gar die dort verarbeiteten verbundenen Quellcodes, ob da nicht irgendetwas "seltsames" drinsteht? - "Linux/Unix wird nur von so wenigen Leuten genutzt, das es sich nicht lohnt dafür Malware zu entwickeln" Naja, selbst wenn der Markanteil von Linux nur bei 1% läge so entspräche das doch immer noch Millionen von Nutzern (von denen vermutlich 90% Privatanwender sind die glauben ihr System sei sicher und die deswegen kein besonderes Augenwerk auf Sicherheitsmaßnahmen legen). Deren Rechner zu infiltrieren könnte durchaus ein machbares und - je nach Zweck - auch lohnenswertes Unterfangen sein. Die Verbreitung von Malware geschieht hier vielleicht nicht über die gleichen Mechanismen, die sich unter Windows bewährt haben (modifizierte JPEGs, Schwachstellen von Outlook oder Fehler in der Oracle-JVM), aber andere Wege führen auch zum Ziel. Und hier garantieren einem weder Frau Suse noch Herr Debian das ein Linuxsystem 100%ig sicher ist. Aus gutem Grund. Das geht einfach nicht (mit menschenmöglichem Aufwand). Da bildet nach wie vor der Anwender selber die allererste Bastion. Und dazu ist ein gutes Maß an Fachwissen unumgänglich. Kurzum: Die oben genannten Argumente sind zwar durchaus plausibel, aber eben überhaupt nicht gesichert. Wenn du wegen der Sicherheit von Windows nach Linux wechseln möchtest, dann finde ich den Schritt zwar auf jeden Fall zweckdienlich; garantieren tut dir allerdings auch unter Linux niemand irgendetwas. Zumindest aber dürfte die reine Wahrscheinlichkeit Opfer einer Malware/eines Lauschangriffs von Microsoft o.a. zu werden absinken (was auch nur meine persönliche subjektive Einschätzung ist; auch ich werde da für nix garantieren). Beside: Abgesehen von der mutmaßlichen Sicherheit hat Linux aber auch noch andere erwähnenswerte Möglichkeiten zu bieten (ich will jetzt nicht von Vorteilen reden; ob es für einen selber Vorteile sind muss man halt selbst entscheiden). Das mal zu testen, und sei es auch nur mit einer Life-CD, lohnt sich glaube ich schon auf alle Fälle. :)
Sven B. schrieb: > Meh, unter Windows kann ich nichtmal ein olles PDF überschreiben während > es im krautigen PDF-Betrachter offen ist. Das wäre mir als Benutzer > wichtiger als Threads die den Besitzer wechseln. SCNR Und was hat das mit Windows/Linux zu tun? Wenn ich unter Linux eine Datei exklusiv öffnen, kann du auch nicht mehr reinschreiben. > Außerdem gibt es ja setuid(), ich würde mal vermuten damit kann man sich > basteln was man braucht wenn man wirklich will ... haben andere schon versucht. Geht bei Linux ohne Kernel Manipulation nicht. Bei BSD soll es funktionieren.
Sheeva P. schrieb: > In allen diesen Bereichen hat Linux Vorteile: Linux-User haben sich > bewußt für dieses System entschieden und dürften daher durchschnittlich > bessere Computer- und Sicherheitskenntnisse haben. das darf sehr stark bezweifelt werden, wenn man einige Thread hier liest. Da gibt es einige Nutzer die kennen nicht mal die Kommandozeile. > Linux-Distributionen > sind sehr heterogen: dasselbe Programm, das unter Distribution X mit > einem Exploit oder Trojaner A angegriffen werden kann, ist unter > Distribution Y anders übersetzt und daher gegen den Exploit oft immun. das täuscht. Bugs im openssl betreffen 99% aller Server. Erst in den letzten Jahren haben sich ein paar alternativen durchgesetzt. > Linux-Systeme tun sehr viel für die Sicherheit: angefangen bei einem > eingängigen, konsistenten Berechtigungskonzept für Benutzer, Dateien und > Prozesse bis hin zu eher technischen Lösungen wie der Address Space > Randomization. wo hat Linux ein sinnvolles Rechtekonzept? Sobald man mehr als 2 Gruppen oder 2 Usern rechte zuweisen will, muss man haufenweise pseudogruppen anlegen. Linux Rechtesystem geht auch nichts übers Filesystem hinaus, wo kann man einheitlich die Rechte fürs Starten von Diensten/Services festlegen? Schon das die Primitiven ID für User und Gruppen die schon beim entpacken von Daten ärger machen, weil die Daten auf einmal einer fremden Person gehören.
Sheeva P. schrieb: > Wenn die Verbreitung die Rolle spielen würde, die Windows-Apologeten oft > als eher hilflose Erklärung dafür anbieten, daß ihre Software so häufig > angegriffen wird, dann wäre der am verbreitetste Webserver Apache der am > häufigsten angegriffene. Tatsächlich war es aber der weniger verbreitete > IIS, der öfter, und viel öfter auch erfolgreich angegriffen wurde. Daß dein Wunschdenken an der Realität vorbei geht, ist nichts Neues: http://www.pro-linux.de/news/1/12467/apache-und-linux-webserver-am-haeufigsten-gecrackt.html Du darfst deine Behauptungen natürlich gern mit Quellen belegen.
Ich hab mehrfach versucht auf diverse Linux-Distris zu wechseln, am Ende bin ich aber immer wieder bei Windows gelandet und nutze jetzt Windows 10. Wenn man dort die "Neuerungen" zu Windows7 (Cortana, Edge...) abschaltet läuft das ganz anständig und bootet in 5 Sekunden. All meine Programme laufen gut, was will man mehr? Linux war bei mir bisher immer träger bei Mausklicks, hat lange zum Hochfahren gebraucht und ich hatte dort immer Angst vor Updated, da es mir zweimal passiert ist, dass das System nach dem Update überhaupt nicht mehr gelaufen ist. Komisch, ist mir bei Windows noch nie passiert. Also ich finde das hat schon seine Berechtigung warum Linux nur von Fanatikern <auf Dauer> benutzt wird ;)
Peter II schrieb: > achso, du bekommst also aktuellen Treiber für den CP2102 auf einem PC > ohne Kompilierern? Ja, unter Linux schon. Das Kernelmodul cp210x.ko ist seit vielen Jahren in jedem Standardkernel enthalten, auch unter Raspbian.
Sheeva P. schrieb: > Ja, unter Linux schon. Das Kernelmodul cp210x.ko ist seit vielen Jahren > in jedem Standardkernel enthalten, auch unter Raspbian. ja, das alte ohne IO-Port Unterstützung. Das hilft mir aber nicht weiter.
Peter II schrieb: > Sven B. schrieb: >> Meh, unter Windows kann ich nichtmal ein olles PDF überschreiben während >> es im krautigen PDF-Betrachter offen ist. Das wäre mir als Benutzer >> wichtiger als Threads die den Besitzer wechseln. SCNR > Und was hat das mit Windows/Linux zu tun? Wenn ich unter Linux eine > Datei exklusiv öffnen, kann du auch nicht mehr reinschreiben. In diesem Sinne dann ungefähr genauso viel wie jedes andere in diesem Thread genannte Argument, nämlich nix.
Michael H. schrieb: >> Momentan sehe ich Linux nur deshalb sicher, da die Verbreitung nich so >> groß wie bei Win ist und es sich für Programmiere einfach nicht rechnet, >> für eine so kleine Zielgruppe einen virus zu programmieren, oder? > > Hmm, weiss nicht. So klein ist die Zielgruppe keineswegs. Ich denke > schon das sich das rechnen würde. Eigentlich halte ich die gerne > propagierte Sicherheit von Linux-/Unix-Systemen auch eher für > Augenwischerei. Die Sicherheit eines Systems hängt in allererster Linie > vom User ab; davon wie sehr er sich um Sicherheit bemüht. Das ist unter > Linux auch nicht anders als unter Windows (obgleich bei Windows > möglicherweise weniger Klimmzüge nötig sind um das System zu > kompromittieren). Siehst Du, und genau das ist der Punkt: unter Windows sind nicht so viele Klimmzüge notwendig. Da Angreifer sich bevorzugt einfache Ziele suchen, reicht dieser kleine Unterschied bereits aus. > - "Software ist i.d.R. als Quellcode erhältlich, da würde Malware sofort > auffallen" > Ach so? Wer studiert denn die ganzen Quellcodes sorgfältig, Zeile für > Zeile, ob da nicht Sicherheitslücken aller Art drin enthalten sind? > [...] Nun, offenbar nimmt auch open-source-software kein > Mensch auf der Welt hinreichen genau unter die Lupe, wie man ja z.B. bei > Heardblead gesehen hat. OpenSource funktioniert und gerade Heartbleed und Shellshock beweisen das. Beide Fehler wurden nämlich durch unabhängige Code-Audits gefunden. ;-)
Peter II schrieb: > Sheeva P. schrieb: >> In allen diesen Bereichen hat Linux Vorteile: Linux-User haben sich >> bewußt für dieses System entschieden und dürften daher durchschnittlich >> bessere Computer- und Sicherheitskenntnisse haben. > das darf sehr stark bezweifelt werden, wenn man einige Thread hier > liest. Welchen Teil von "durchschnittlich" hast Du nicht verstanden? Im Übrigen solltest gerade Du Dich in diesem Punkt vielleicht etwas zurückhalten. > Da gibt es einige Nutzer die kennen nicht mal die Kommandozeile. Schon komisch: in anderen Kontexten beschweren sich die Windows-Fanboys, daß man unter Linux ja immer diese komische Kommandozeile braucht und die ein Relikt vergangener Zeiten sei. Und wenn man ihnen dann erklärt, daß man unter modernen Linuxen auch ohne Kommandozeile prima klicken kann, und daß die Kommandozeile ein Profiwerkzeug für Poweruser ist, dann erntet man zwischen ungläubigem Staunen, wirren Beispielen und wüsten Beschimpfungen so ziemlich alles. Stimm' Dich doch bitte mal mit Deinen Kollegen ab, ja? >> Linux-Distributionen >> sind sehr heterogen: dasselbe Programm, das unter Distribution X mit >> einem Exploit oder Trojaner A angegriffen werden kann, ist unter >> Distribution Y anders übersetzt und daher gegen den Exploit oft immun. > das täuscht. Bugs im openssl betreffen 99% aller Server. Heartbleed: 17%. >> Linux-Systeme tun sehr viel für die Sicherheit: angefangen bei einem >> eingängigen, konsistenten Berechtigungskonzept für Benutzer, Dateien und >> Prozesse bis hin zu eher technischen Lösungen wie der Address Space >> Randomization. > wo hat Linux ein sinnvolles Rechtekonzept? Sobald man mehr als 2 Gruppen > oder 2 Usern rechte zuweisen will, muss man haufenweise pseudogruppen > anlegen. Linux Rechtesystem geht auch nichts übers Filesystem hinaus, wo > kann man einheitlich die Rechte fürs Starten von Diensten/Services > festlegen? Primitive Rechte wie das Starten und Stoppen von Daemons kann man sehr einfach mittels sudo vergeben, vielleicht magst Du einfach mal dessen Dokumentation lesen. Und wer mehr braucht: ACLs, SELinux, AppArmor und RSBAC existieren schon sehr, sehr lange.
Icke ®. schrieb: > Sheeva P. schrieb: >> Wenn die Verbreitung die Rolle spielen würde, die Windows-Apologeten oft >> als eher hilflose Erklärung dafür anbieten, daß ihre Software so häufig >> angegriffen wird, dann wäre der am verbreitetste Webserver Apache der am >> häufigsten angegriffene. Tatsächlich war es aber der weniger verbreitete >> IIS, der öfter, und viel öfter auch erfolgreich angegriffen wurde. > > Daß dein Wunschdenken an der Realität vorbei geht, ist nichts Neues: > > http://www.pro-linux.de/news/1/12467/apache-und-linux-webserver-am-haeufigsten-gecrackt.html > > Du darfst deine Behauptungen natürlich gern mit Quellen belegen. Du solltest die Quellen, die Du angibst, vielleicht mal lesen. Oder hast Du den folgenden Satz (Quelle: ebd.) nicht verstanden?
1 | Lediglich 2.5 Prozent der Angriffe konnten durch einen direkten Angriff auf den Web-Server erfolgreich durchgeführt werden. |
Sheeva P. schrieb: > Primitive Rechte wie das Starten und Stoppen von Daemons kann man sehr > einfach mittels sudo vergeben, das ist ein andere weg zu Ziel. Damit werden keine wirklichen Rechte vergeben. Was ist wenn ich mit einen anderen Tool die dienste verwalten will? Dann muss ich dem Tool er beibringen alles über sudo zu machen.
Peter II schrieb: > Sheeva P. schrieb: >> Primitive Rechte wie das Starten und Stoppen von Daemons kann man sehr >> einfach mittels sudo vergeben, > Was ist wenn ich mit einen anderen Tool die dienste verwalten will? Dann > muss ich dem Tool er beibringen alles über sudo zu machen. du, user, sollst aber gar keine dienste verwalten - das ist die aufgabe vom admin, "root".
Peter II schrieb: > Sheeva P. schrieb: >> Ja, unter Linux schon. Das Kernelmodul cp210x.ko ist seit vielen Jahren >> in jedem Standardkernel enthalten, auch unter Raspbian. > > ja, das alte ohne IO-Port Unterstützung. Das hilft mir aber nicht > weiter. Der CP2101 ist ein USB-to-UART-Konverter. Schön, daß er einen IO-Port hat. Aber wenn es für Dich sooo unzumutbar ist, den zu benutzen: warum nutzt Du dann nicht einfach einen I2C- oder SPI-Portexpander oder, wenn das doch so gut klappen soll, einfach Windows10 auf Deinem RasPi?
c.m. schrieb: > du, user, sollst aber gar keine dienste verwalten - das ist die > aufgabe vom admin, "root". genau drin sehe ich das Problem. Was ist wenn man Aufgabe Delegieren will/muss? Warum sollte ein Entwickler auf seinem PC nicht z.b. mysql starten und stoppen dürfen aber kein Root sein - dafür sind andere zuständig. Wenn ich mich jetzt nicht irre, braucht man sogar root rechte, wenn man die Zeitzone unter Linux ändern will. Was ist mit Personen die kein root sein sollen und ihr Laptop ins Ausland mitnehmen? Selbst WLAN konnte man vor einige Zeit nicht mal ohne root einrichten, man will aber nicht jedem das root Passwort geben oder im beibringen wie er mit sodu umgeht.
Peter II schrieb: > Sheeva P. schrieb: >> Primitive Rechte wie das Starten und Stoppen von Daemons kann man sehr >> einfach mittels sudo vergeben, > > das ist ein andere weg zu Ziel. Damit werden keine wirklichen Rechte > vergeben. > > Was ist wenn ich mit einen anderen Tool die dienste verwalten will? Dann > muss ich dem Tool er beibringen alles über sudo zu machen. Ich habe Dir jetzt fünf Möglichkeiten genannt: sudo, ACLs, AppArmor, SELinux und RSBAC. Und jetzt noch eine sechste: Du kannst sowas natürlich auch über ein paar ganz einfache setuid-Wrapper machen. Langsam beschleicht mich der Eindruck, daß Du Dich ganz bewußt so anstellst, weil es Dir eigentlich nur darum geht, gegen Linux zu polemisieren.
Sheeva P. schrieb: > Der CP2101 ist ein USB-to-UART-Konverter. Schön, daß er einen IO-Port > hat. Aber wenn es für Dich sooo unzumutbar ist, den zu benutzen: warum > nutzt Du dann nicht einfach einen I2C- oder SPI-Portexpander Weil ich RS232 und die IO-Pins brauche. Außerdem bei Entwurf der Hardware nicht damit gerechnet haben, das Linux hier ein Problem darstellt. Unter Windows hatte alles ordentlich funktioniert. Hast du nicht geschrieben, das bei Linux alles sofort funktioniert? Jetzt soll ich die Hardware ändern weil Linux es nicht schafft nach Jahren eine neueren Treiber automatisch bereitzustellen? Ich habe nur ein Beispiel aus der Praxis gezeigt, das bei Linux auch nicht alles sofort funktioniert. Dann muss man sehr viel zeit auch in Linux investieren, wo es teilweise mit Windows einfacher und schneller geht.
Sheeva P. schrieb: > Ich habe Dir jetzt fünf Möglichkeiten genannt: sudo, ACLs, AppArmor, > SELinux und RSBAC. Und SELinux und AppArmor schränken rechte zusätzlich ein. Wie soll ich damit zusätzliche rechte bekommen? Ich kenne beides aber nur vom lesen, habe es nie eingesetzt.
Peter II schrieb: > c.m. schrieb: >> du, user, sollst aber gar keine dienste verwalten - das ist die >> aufgabe vom admin, "root". > > genau drin sehe ich das Problem. Was ist wenn man Aufgabe Delegieren > will/muss? ich verstehe nicht was du damit meinst. > Warum sollte ein Entwickler auf seinem PC nicht z.b. mysql starten und > stoppen dürfen aber kein Root sein - dafür sind andere zuständig. du kannst ein benutzerspezifisches mysql in deinem eigenen bin verzeichnis installieren - für entwickler die sich mit entwicklungswerkzeugen rumärgern müssen alltäglich. ansonsten kannst du, einen account vorausgesetzt, das im system installierte mysql benutzen, aber den dienst an sich nicht beeinflussen. außer: der benutzer darf "sudo -i" ausführen, dann kann er auch dienste steuern. > Wenn ich mich jetzt nicht irre, braucht man sogar root rechte, wenn man > die Zeitzone unter Linux ändern will. Was ist mit Personen die kein root > sein sollen und ihr Laptop ins Ausland mitnehmen? ne braucht man nicht > Selbst WLAN konnte man vor einige Zeit nicht mal ohne root einrichten, obsolet. geht seit jahren ohne rootzugriff. > man will aber nicht jedem das root Passwort geben oder im beibringen wie > er mit sodu umgeht. ob man einem benutzer (level DAU) nun beibringen muss wo er mit welcher maustaste hinklicken muss, oder ob man ihm beibringen muss "sudo" und konsorten zu tippen gibt sich nicht viel. die meißten wollen sich weder mit dem einen, noch mit dem anderen beschäftigen, sondern fordern "das es einfach geht" - und es so zu machen ist aufgabe vom admin.
c.m. schrieb: >> Wenn ich mich jetzt nicht irre, braucht man sogar root rechte, wenn man >> die Zeitzone unter Linux ändern will. Was ist mit Personen die kein root >> sein sollen und ihr Laptop ins Ausland mitnehmen? > > ne braucht man nicht auf den Bild ist doch zu sehen, das man ein Passwort braucht? Man will dem User aber das root Passwort nicht geben. Bei Windows kann ich den Nutzer einfach das Recht "Ändern der Zeitzone" zuweisen und gut ist.
Peter II schrieb: > auf den Bild ist doch zu sehen, das man ein Passwort braucht? Man will > dem User aber das root Passwort nicht geben. Bei Windows kann ich den > Nutzer einfach das Recht "Ändern der Zeitzone" zuweisen und gut ist. Und unter Linux änderst du einfach die Zeitzone für deinen Benutzer, und nicht für das ganze System. Die Idee dass die Systemzeit eine Zeitzone hat ist sowieso blöd.
Peter II schrieb: > auf den Bild ist doch zu sehen, das man ein Passwort braucht? Man will > dem User aber das root Passwort nicht geben. Bei Windows kann ich den > Nutzer einfach das Recht "Ändern der Zeitzone" zuweisen und gut ist.
1 | user localhost = (root) NOPASSWD: /usr/bin/tzselect |
Karl Käfer schrieb: > user localhost = (root) NOPASSWD: /usr/bin/tzselect und was hilft dieser Eintrag (vermutlich sudo) wenn ich es über die GUI machen will?
Peter II schrieb: > achso, du bekommst also aktuellen Treiber für den CP2102 auf einem PC > ohne Kompilierern? https://www.pololu.com/docs/0J7/all#4 Nichts zu danken.
vn nn schrieb: > Peter II schrieb: >> achso, du bekommst also aktuellen Treiber für den CP2102 auf einem PC >> ohne Kompilierern? > > https://www.pololu.com/docs/0J7/all#4 > > Nichts zu danken. wieder einer der nicht lesen kann, der Treiber unterstützt keine IO-Ports. Es gibt also nicht zu danken.
Peter II schrieb: > Karl Käfer schrieb: >> user localhost = (root) NOPASSWD: /usr/bin/tzselect > > und was hilft dieser Eintrag (vermutlich sudo) wenn ich es über die GUI > machen will? Think kdesudo, gksudo et al.:
1 | /usr/bin/kdesudo '/usr/bin/xterm -e /usr/bin/tzselect' |
Karl Käfer schrieb: > Think kdesudo, gksudo et al.: also darf man an vielen stellen etwas ändern, weil es keine Möglichkeit einer sinnvollen Rechtezuweisung gibt? Sudo ist nur der Linux Weg, weil es sie es nicht geschafft haben Systemfunktionen an rechte zu koppeln. Ja man kann vermutlich vielen/alles mit sudo machen - aber das hat sehr wenig mit einer Rechteverwaltung zu tun. Was ist wenn sich der Loginname ändert ( es gibt Personen die ändern ihren Namen) dann darf man wieder alle stellen suchen und ändern.
Ein solches Recht weißt man auch nicht einem einzelnen Benutzer zu, sondern man erteilt ein Recht einer Benutzergruppe. Den einzelnen Benutzern weißt man dann die entsprechenden Gruppen zu. Da unter Linux fast alles Dateien sind, reicht es dann der entsprechenden Gruppe Schreibrechte für diese Datei zu geben. Somit entfällt auch die Notwendigkeit von sudo. Eine der wenigen Ausnahmen wo Geräte nicht als Datei repräsentiert werden ist das Netzwerk, aber das geht mittlerweile ja auch für jeden Benutzer individuell.
Peter II schrieb: > Karl Käfer schrieb: >> Think kdesudo, gksudo et al.: > > also darf man an vielen stellen etwas ändern, weil es keine Möglichkeit > einer sinnvollen Rechtezuweisung gibt? > > Sudo ist nur der Linux Weg, weil es sie es nicht geschafft haben > Systemfunktionen an rechte zu koppeln. > > > Ja man kann vermutlich vielen/alles mit sudo machen - aber das hat sehr > wenig mit einer Rechteverwaltung zu tun. Was ist wenn sich der Loginname > ändert ( es gibt Personen die ändern ihren Namen) dann darf man wieder > alle stellen suchen und ändern. UNIX hat ein ausgesprochen durchdachtes, konsistentes, konsequentes, und dabei sehr gut verständliches und anwendbares Privilegiensystem, das für 95% aller Anwendungsfälle mehr als ausreicht und für weitere 4% aller Fälle immer noch gut genug ist. Dazu hinaus bietet UNIX mithilfe von sudo noch die Möglichkeit, dieses Privilegiensystem kontrolliert und feinst granuliert zu erweitern, und kann so weitere 0,99 Prozent aller Anwendungsfälle abdecken. Für den unwahrscheinlichen Fall, daß ausgerechnet Deine Anforderungen - also die im echten Leben, nicht den Bullshit, den Du Dir hier zusammen konstruierst, um Deine blöden Einlassungen zu rechtfertigen - in jenen winzigen 0,01%-Bereich liegen, der sich mit den klassischen Privilegien sowie sudo nicht abbilden läßt, gibt es zusätzlich noch Mandatory Access Control (MAC) Systeme wie AppArmor und SELinux. Es ist also alles vorhanden, was Du willst, und zweifellos noch viel mehr. Daß Du das nicht kennst, spricht nicht gegen Linux und seine Fähigkeiten, sondern gegen Deine Kompetenz und gegen Deine Fähigkeiten. Insofern hast Du jetzt genau drei Möglichkeiten: erstens, einfach mal anzuerkennen, daß Du von etwas keine Ahnung hast, zweitens, Dir die fehlenden Kompetenzen anzueignen, und drittens, es "besser" in Deinem ganz eigenen, persönlichen Sinne von "besser" zu machen und etwas zu entwickeln, das Deinen Wünschen und Vorstellungen entspricht. Hier weiter über Deine eigene Inkompetenz rumzuflennen, ist jedenfalls keine Option.
Peter II schrieb: > Sheeva P. schrieb: >> Ich habe Dir jetzt fünf Möglichkeiten genannt: sudo, ACLs, AppArmor, >> SELinux und RSBAC. Und > > SELinux und AppArmor schränken rechte zusätzlich ein. Wie soll ich damit > zusätzliche rechte bekommen? Indem Du sie vergibst. SELinux, AppArmor und RSBAC sind MAC-Systeme, die ganz anders funktionieren als das herkömmliche UNIX-DAC-Rechtesystem. Mit den MAC-Systemen kannst Du nicht nur Rechte einschränken, sondern auch sehr fein verteilt gewähren. Aber Dir ging es nur darum, ein paar Rechte bzw. Funktionen zu delegieren, und dafür ist ein MAC-System sicher deutlich überdimensioniert. Deswegen gibt es als Erweiterung des klassischen UNIX-Rechtesystems eben sudo, mit welchem sich sowas sehr elegant abbilden läßt.
Karl Käfer schrieb: > UNIX hat ein ausgesprochen durchdachtes, konsistentes, konsequentes, und > dabei sehr gut verständliches und anwendbares Privilegiensystem, das für > 95% aller Anwendungsfälle mehr als ausreicht und für weitere 4% aller > Fälle immer noch gut genug ist. > Deswegen gibt es als Erweiterung des klassischen > UNIX-Rechtesystems eben sudo, mit welchem sich sowas sehr elegant > abbilden läßt. Wo finde ich dazu eine verständliche Dokumentation um mehr darüber lernen zu können?
Wenn Linux im obigen Beispiel Bach dem Passwort fragt, dann weil es etwas machen soll/muß, was mehr Rechte braucht als der momentane User hat. Hat er kein "sudo"-Recht, dann darf man sich auch noch einen passenden User aussuchen. Und das Paaswort dient dazu, zu prüfen, ob der, der die "sudo"-Aktion ausführen soll auch Furor der Kiste sitzt. Windows fragt (bei einem "Sudoer") da nur "soll ich das machen?" und wer auch immer das liest darf "Jawoll" clicken. Nochmalige Identifizierung zur Sicherheit: "Fehlanzeige". Windows hat auch eine schöne Verkettung von Datei und Name. Ist eine Datei Memory-mapped, weil gerade ausgeführt, dann ist ein Austausch zwecks Update nicht möglich. Selbst wenn das dann so eine Popel-"App" wie Notepad ist, wird die neue Version als "beim nächste Reboot zu ersetzen" hinterlegt und dieser Reboot ist dann Pflicht. Wegen Notepad. Das geht auch anders: eine Unix-Datei ist ein eigenständiges Objekt auf das ein oder mehrere Namen verweisen können. Zum Update entfernt man dann den Named und falls die Datei nicht gerade memmapped ist verschwindet sie im Nirvane. Andernfalls bleibt sie existent. Aber unter selbem Namen kann jederzeit eine neue (Version) aufspielen. Das nächste mal startet dann einfach das neue Notepad. Oder eben ein Service. Bei Windows kann man natürlich das, was man updaten will vorher stoppen und danach wieder starten, aber bei der Vielzahl der DLL-Abhängigkeiten gibt's meist Reboot. Wobei das auch WinNT ganz tief drin könnte, nur bekommt man das immer nur ver-Windows'd zu sehen. Mir persönlich ist es eigentlich egal, wer was benutzt. Solange er mit den Konsequenzen selber lebt. Da mein Arbeitgeber mir Windows mit vollen Support vorsetzt, ist das OK. Daheim will ich aber so was nicht sehen.
Carl D. schrieb: > Windows fragt (bei einem "Sudoer") da nur "soll ich das machen?" und wer > auch immer das liest darf "Jawoll" clicken. Nochmalige Identifizierung > zur Sicherheit: "Fehlanzeige". nur wenn man Admin rechte hat. Wenn man keine Admin rechte hat braucht man das Passwort von einem Admin. Linux fragt überhaupt nicht mehr wenn man einmal root ist. Carl D. schrieb: > Oder eben ein Service hast du das schom mal auf einen aktuellen Linux mit systemd getestet? Wenn der Service läuft ist die Datei blockiert. > aber bei der Vielzahl der DLL-Abhängigkeiten gibt's meist Reboot. wenn man glibc updatet, muss auch so ziemlich alles neu starten, dann kann man auch gleich mal bootet.
Peter II schrieb: > Carl D. schrieb: >> Windows fragt (bei einem "Sudoer") da nur "soll ich das machen?" und wer >> auch immer das liest darf "Jawoll" clicken. Nochmalige Identifizierung >> zur Sicherheit: "Fehlanzeige". > > nur wenn man Admin rechte hat. Wenn man keine Admin rechte hat braucht > man das Passwort von einem Admin. Wenn du den Textausschnitt in seinem Kontext gelassen/gelesen hättest, Stände genau das drin. > > Linux fragt überhaupt nicht mehr wenn man einmal root ist. Niemand muß/soll dauerhaft root sein, dafür hat man sudo. > Carl D. schrieb: >> Oder eben ein Service > > hast du das schom mal auf einen aktuellen Linux mit systemd getestet? > Wenn der Service läuft ist die Datei blockiert. Ich rede vom Binary dieses Service. Der Service hat eine Version in Benutzung, aber ich kann jederzeit die Verknüpfung zum File-Namen entfernen. Das File lebt weiter, sollange der Service-Prozess es noch mapped. Da es aber den Namen nun nicht mehr gibt, kann ich jederzeit eine neue Datei mit diesem Namen anlegen. Und nach dem Restart (des Service und nicht der ganzen Maschine) findet dieser unter dem Namen seines Binaries die neue Version vor. Ich gebe zu, das glaubt man kaum, wenn man nur Windows kennt. Eine solide Ausbildung zum Thema Betriebsysteme kann auch helfen. > >> aber bei der Vielzahl der DLL-Abhängigkeiten gibt's meist Reboot. > wenn man glibc updatet, muss auch so ziemlich alles neu starten, dann > kann man auch gleich mal bootet. Echt? Wer hätte das gedacht. Nur daß auch in dem Fall in den Speicher gemapptes Binary und Disk-Inhalt, der über den Namen "glibc" nicht identisch sein müssen. Was mich wundert ist nur, daß das Linux auf meinem Entwicklungs-Notebook daheim täglich solche Updates bekommt, die meinen Arbeits-Windows-PC zum Reboot zwingen würden und der deswegen nur einmal im Monat oder bei Gefahr im Verzug gepatschtem wird. Und mein Linux ist immer nur hyperniert, läuft also quasi kontinuierlich durch. Außer wenn es einen neuen Kernel gibt. Zum Thema anmelden als root und Unix-Filesystem habe ich mal vor rund 20 Jahren folgendes erlebt: Kollege sitzt an HP9000-Unix-Kiste, als root, denn man muß ja alles unter Kontrolle haben und er ist irgendwann genervt, weil was nicht so klappen will, wie geplant. Hämmert auf der Tastatur rum und findet in der Command-History ein "rekursives Löschen". Er befindet sich gerade da: / Schupp waren alle Verzeichnisse samt Inhalt weg und es gab nur noch das nun namenlose Unix-Image (und natürlich andere Binaries, die von noch laufenden Prozessen benutzt wurden. Nach dem Runterfahren war die Platte clean. Also niemals als root und Unix-Filesysteme funktionieren (geprüft) genau so wie beschrieben.
Carl D. schrieb: > Ich gebe zu, das glaubt man kaum, > wenn man nur Windows kennt. Eine solide Ausbildung zum Thema > Betriebsysteme kann auch helfen. Seit wann gibt es kpatch, um mal einen Schritt weiter zu gehen? 2014... ksplice seit 2008 https://technet.microsoft.com/en-us/library/cc782258%28v=ws.10%29.aspx "When a hotpatch package is installed, it: - Replaces the old binary file on disk with the coldpatch binary file. - Injects the updated function (as a hotpatch binary file) into the loaded image of the defective binary file..." das gab mit Windows Server 2003 und wurde vor kurzem ausgenutzt: https://blogs.technet.microsoft.com/mmpc/2016/04/26/digging-deep-for-platinum/ Ansonsten sind Dynamic Software Updates immernoch Gegenstand der Forschung. Kitsune wäre bpsw. so etwas für C-Programme http://kitsune-dsu.com/ > Was mich wundert ist nur, daß das Linux auf meinem Entwicklungs-Notebook > daheim täglich solche Updates bekommt, die meinen Arbeits-Windows-PC zum > Reboot zwingen würden und der deswegen nur einmal im Monat oder bei > Gefahr im Verzug gepatschtem wird. Und mein Linux ist immer nur > hyperniert, läuft also quasi kontinuierlich durch. Das hieße also, dass die laufenden Programme bis zum nächsten Kernel-Update, der zum Neustart zwingt, ungepatcht bleiben, wenn man den Ausführungen folgt... Lasse meine Linux-Rechner zwar auch durchlaufen (Windows ebenso), starte in Abhängigkeit der Updates aber trotzdem zwischendurch neu. Auch um vor unliebsamen Überraschungen zu ungünstigen Gelegenheiten verschont zu bleiben. > Also niemals als root und Unix-Filesysteme funktionieren (geprüft) genau > so wie beschrieben. Das berühmte rm -rf / mittlerweile sollte da nichts mehr passieren, außer es folgt noch --no-preverve-root
Gerd schrieb: > Karl Käfer schrieb: >> UNIX hat ein ausgesprochen durchdachtes, konsistentes, konsequentes, und >> dabei sehr gut verständliches und anwendbares Privilegiensystem, das für >> 95% aller Anwendungsfälle mehr als ausreicht und für weitere 4% aller >> Fälle immer noch gut genug ist. > >> Deswegen gibt es als Erweiterung des klassischen >> UNIX-Rechtesystems eben sudo, mit welchem sich sowas sehr elegant >> abbilden läßt. > > Wo finde ich dazu eine verständliche Dokumentation um mehr darüber > lernen zu können? Zum Beispiel im Standardwerk "Linux" von Dr. Michael Kofler, aber was genau möchtest Du denn wissen?
Sheeva P. schrieb: > Siehst Du, und genau das ist der Punkt: unter Windows sind nicht so > viele Klimmzüge notwendig. Da Angreifer sich bevorzugt einfache Ziele > suchen, reicht dieser kleine Unterschied bereits aus. Och, das kannst du jetzt aber auch nicht sicher belegen, oder? Bzw. bedeutet "bevorzugt" ja nun auch net das Angriffe auf Systeme "mit mehr nötigen Klimmzügen" ausgeschlossen sind. Sorry, aber bislang fällt deine Hypothese in meinen Augen auch wieder nur in die Rubrik Augenwischerei. Sicherheit sieht anders aus. Sheeva P. schrieb: > OpenSource funktioniert und gerade Heartbleed und Shellshock beweisen > das. Beide Fehler wurden nämlich durch unabhängige Code-Audits gefunden. > ;-) Najaaaaa, da können allerdings - laut den Wikipedia-Einträgen die ich gerade überflogen habe - auch erst einmal Jahre vergehen bis solche Sicherheitslücken bemerkt und behoben werden. Das ist doch weiss Gott Zeit genug um Schaden anzurichten. OffTopic: In dem Zusammenhang stellt sich mir gerade die Frage: Wie funktionieren eigentlich "Virenscanner" unter Unix? Aufgrund der bereits beschworenen Heterogenität von Unix-Systemen dürften die doch einen ausgesprochen schweren Stand haben wenn sie Schadcode in Binaries erkennen möchten, oder?!
Carl D. schrieb: >> >> hast du das schom mal auf einen aktuellen Linux mit systemd getestet? >> Wenn der Service läuft ist die Datei blockiert. > > Ich rede vom Binary dieses Service. Der Service hat eine Version in > Benutzung, aber ich kann jederzeit die Verknüpfung zum File-Namen > entfernen. Das File lebt weiter, sollange der Service-Prozess es noch > mapped. Da es aber den Namen nun nicht mehr gibt, kann ich jederzeit > eine neue Datei mit diesem Namen anlegen. Und nach dem Restart (des > Service und nicht der ganzen Maschine) findet dieser unter dem Namen > seines Binaries die neue Version vor. Ich gebe zu, das glaubt man kaum, > wenn man nur Windows kennt. Eine solide Ausbildung zum Thema > Betriebsysteme kann auch helfen. nein genau das geht nicht mehr. Ich kann das binary vom Service nicht überschreiben, während er läuft.
Peter II schrieb: > nein genau das geht nicht mehr. > > Ich kann das binary vom Service nicht überschreiben, während er läuft.
1 | root@Daniels-Surface-Pro-3:~# systemctl status apache2 |
2 | ● apache2.service - LSB: Apache2 web server |
3 | Loaded: loaded (/etc/init.d/apache2; bad; vendor preset: enabled) |
4 | Drop-In: /lib/systemd/system/apache2.service.d |
5 | └─apache2-systemd.conf |
6 | Active: active (running) since Don 2016-06-02 07:59:06 CEST; 12min ago |
7 | Docs: man:systemd-sysv-generator(8) |
8 | Process: 1117 ExecStart=/etc/init.d/apache2 start (code=exited, status=0/SUCCESS) |
9 | CGroup: /system.slice/apache2.service |
10 | ├─1223 /usr/sbin/apache2 -k start |
11 | ├─1230 /usr/sbin/apache2 -k start |
12 | ├─1231 /usr/sbin/apache2 -k start |
13 | ├─1232 /usr/sbin/apache2 -k start |
14 | ├─1235 /usr/sbin/apache2 -k start |
15 | └─1236 /usr/sbin/apache2 -k start |
16 | |
17 | Jun 02 07:59:05 Daniels-Surface-Pro-3 systemd[1]: Starting LSB: Apache2 web server... |
18 | Jun 02 07:59:05 Daniels-Surface-Pro-3 apache2[1117]: * Starting Apache httpd web server apache2 |
19 | Jun 02 07:59:05 Daniels-Surface-Pro-3 apache2[1117]: AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/apache2/ports.conf:8 |
20 | Jun 02 07:59:05 Daniels-Surface-Pro-3 apache2[1117]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to sup |
21 | Jun 02 07:59:06 Daniels-Surface-Pro-3 apache2[1117]: * |
22 | Jun 02 07:59:06 Daniels-Surface-Pro-3 systemd[1]: Started LSB: Apache2 web server. |
23 | root@Daniels-Surface-Pro-3:~# which apache2 |
24 | /usr/sbin/apache2 |
25 | root@Daniels-Surface-Pro-3:~# cp /usr/sbin/apache2 /tmp |
26 | root@Daniels-Surface-Pro-3:~# echo test > /usr/sbin/apache2 |
27 | bash: /usr/sbin/apache2: Das Programm kann nicht ausgeführt oder verändert werden (busy) |
Holy shit!?! In letzter zeit scheinen mir die neuen populären Linux Programme in die falsche Richtung zu gehen, und die guten alten Grundsätze (Jedes Programm eine Aufgabe, keep it simple, das Rad nicht immer neu erfinden, etc.), zu vergessen. Langsam erwäge ich, systemd und Ubuntu links liegen zu lassen, und Debian mit einem anderen init system zu verwenden. Zugegeben, systemd ist echt gut, aber es tut zu viel. Man brauchte etwas wie systemd, bei dem initsystem und sonstiges wieder getrennt ist. Ubuntu mag ich nichtmehr so, seit ich Mir, upstart, ciborium und co. kenne. Ich will nicht sagen früher war alles besser, aber alle alten Konzepte waren verdammt gut, und dürfen nicht einfach vergessen werden, sonst werden wir linux bald nichtmehr wiedererkennen.
Daniel A. schrieb: > Holy shit!?! Danke für die Bestätigung, ich hatte mich auch gewundert wo ich das zum erst mal erlebt hatte. Vermutlich macht es irgend wann immer Ärger wenn das Binary weg ist und das Programm noch läuft.
Daniel A. schrieb: > Holy shit!?! In letzter zeit scheinen mir die neuen populären Linux > Programme in die falsche Richtung zu gehen, und die guten alten > Grundsätze (Jedes Programm eine Aufgabe, keep it simple, das Rad nicht > immer neu erfinden, etc.), zu vergessen. Langsam erwäge ich, systemd und > Ubuntu links liegen zu lassen, und Debian mit einem anderen init system > zu verwenden. Zugegeben, systemd ist echt gut, aber es tut zu viel. Man > brauchte etwas wie systemd, bei dem initsystem und sonstiges wieder > getrennt ist. U.a. aus dem Grund bin ich hier bei Void Linux gelandet 1): Kein systemd stattdessen runit, LibreSSL statt OpenSSL, bei Bedarf die schlankere musl-Lib statt der glibc und mit xbps ein Package System (Binär- und Quelltextpakete), dass imo ebenso wie Portage den anderen Systemen überlegen ist. 1) zum "basteln" gibt's noch eine Arch-Installation > Ubuntu mag ich nichtmehr so, seit ich Mir, upstart, > ciborium und co. kenne. Ich will nicht sagen früher war alles besser, > aber alle alten Konzepte waren verdammt gut, und dürfen nicht einfach > vergessen werden, sonst werden wir linux bald nichtmehr wiedererkennen. Zur Not bleiben noch einige BSDs...
Michael H. schrieb: > Sheeva P. schrieb: >> Siehst Du, und genau das ist der Punkt: unter Windows sind nicht so >> viele Klimmzüge notwendig. Da Angreifer sich bevorzugt einfache Ziele >> suchen, reicht dieser kleine Unterschied bereits aus. > > Och, das kannst du jetzt aber auch nicht sicher belegen, oder? Bzw. > bedeutet "bevorzugt" ja nun auch net das Angriffe auf Systeme "mit mehr > nötigen Klimmzügen" ausgeschlossen sind. Gut erkannt. Das hatte ich aber auch gar nicht gesagt, oder? :-) > Sheeva P. schrieb: >> OpenSource funktioniert und gerade Heartbleed und Shellshock beweisen >> das. Beide Fehler wurden nämlich durch unabhängige Code-Audits gefunden. >> ;-) > Najaaaaa, da können allerdings - laut den Wikipedia-Einträgen die ich > gerade überflogen habe - auch erst einmal Jahre vergehen bis solche > Sicherheitslücken bemerkt und behoben werden. Das stimmt. Es kommt vor, daß Fehler erst Jahre später bei unabhängigen Code-Audits gefunden werden. Aber wenigstens wird der Fehler gefunden, weil unabhängige Code-Audits möglich sind und auch gemacht werden. > OffTopic: In dem Zusammenhang stellt sich mir gerade die Frage: Wie > funktionieren eigentlich "Virenscanner" unter Unix? Aufgrund der bereits > beschworenen Heterogenität von Unix-Systemen dürften die doch einen > ausgesprochen schweren Stand haben wenn sie Schadcode in Binaries > erkennen möchten, oder?! Nö, wieso?
Arc N. schrieb: > [...] mit xbps ein Package System > (Binär- und Quelltextpakete), dass imo ebenso wie Portage den anderen > Systemen überlegen ist. Warum?
> Holy shit!?!
Wenn sich das auf "Text file busy" bezieht: Das war schon immer(!) so,
wenn das Binary lokal auf der Platte liegt. Wenn es über NFS kommt, kann
man es überschreiben, weil dann das überschriebene temporär umbenannt
wird (.nfs-xxx).
Es ist allerdings kein Problem, ein laufendes Binary (bzw. die Libs) zu
löschen oder umzubenennen und dann ein neues mit dem alten Namen zu
schreiben, egal ob NFS oder nicht. Die Shell-Umleitung mit > macht wohl
bei existierenden Files nur ein truncate, damit schlägt es mit ETXTBSY
an.
Was aber bei Linux im Gegensatz zu Windows immer geht, ist eine von
einem Programm offen gehaltene Datei (kein Exe) neu zu beschreiben.
Unter Windows muss man beim Öffnen Extra-Flags mitgeben, damit das
funktioniert.
Georg A. schrieb: > Wenn sich das auf "Text file busy" bezieht: Das war schon immer(!) so, > wenn das Binary lokal auf der Platte liegt. ... > Es ist allerdings kein Problem, ein laufendes Binary (bzw. die Libs) zu > löschen oder umzubenennen und dann ein neues mit dem alten Namen zu > schreiben, egal ob NFS oder nicht.
1 | daniel@Daniels-Surface-Pro-3:~$ echo 'int main(){while(1);}' | gcc -x c - -o out;./out& |
2 | [1] 6968 |
3 | daniel@Daniels-Surface-Pro-3:~$ echo test > out |
4 | bash: out: Das Programm kann nicht ausgeführt oder verändert werden (busy) |
5 | daniel@Daniels-Surface-Pro-3:~$ echo test > out2 |
6 | daniel@Daniels-Surface-Pro-3:~$ mv out2 out |
7 | daniel@Daniels-Surface-Pro-3:~$ cat out |
8 | test |
Tatsächlich... Man lernt nie aus :)
Daniel A. schrieb: >
1 | > [...] |
2 | > bash: /usr/sbin/apache2: Das Programm kann nicht ausgeführt oder |
3 | > verändert werden (busy) |
4 | > |
Du kannst das laufende Binary überschreiben, wenn Du das alte vorher löschst. Dann wird der Verzeichniseintrag des alten Executable gelöscht, aber Inode und Daten werden erst gelöscht, bis das Programm beendet ist. > Holy shit!?! In letzter zeit scheinen mir die neuen populären Linux > Programme in die falsche Richtung zu gehen, Du hälst es für die richtige Richtung, laufende Binaries zu überschreiben? > Ubuntu mag ich nichtmehr so, seit ich Mir, upstart, > ciborium und co. kenne. Versteh' ich nicht. Upstart ist dank systemd ohnehin schon vom Tisch, Mir wird sich IMHO auch nicht durchsetzen, denn kein anderer Distributor außer Canonical will es benutzen und Intel hat sogar schon den Mir-Support aus seinen Grafiktreibern entfernt. Und bei ciborium passiert auch schon seit langer Zeit nichts mehr... > Ich will nicht sagen früher war alles besser, > aber alle alten Konzepte waren verdammt gut, und dürfen nicht einfach > vergessen werden, sonst werden wir linux bald nichtmehr wiedererkennen. Also wenn ich zwischen SysV-Init, Upstart und systemd wählen darf, dann nehme ich immer systemd.
Sheeva P. schrieb: > Du hälst es für die richtige Richtung, laufende Binaries zu > überschreiben? Ich sehe zumindest kein Problem damit. Nach meinem momentanen Verständnis wird ein Programm beim Starten in den RAM geladen. Wieso sollten also Änderungen an der Programmdatei Auswirkungen am bestehenden Prozess haben? > Daniel A. schrieb: >> Ubuntu mag ich nichtmehr so, seit ich Mir, upstart, >> ciborium und co. kenne. > > Versteh' ich nicht. Upstart ist dank systemd ohnehin schon vom Tisch, > Mir wird sich IMHO auch nicht durchsetzen, denn kein anderer Distributor > außer Canonical will es benutzen und Intel hat sogar schon den > Mir-Support aus seinen Grafiktreibern entfernt. Und bei ciborium > passiert auch schon seit langer Zeit nichts mehr... Ubuntu Touch verwendet die Dinger, aber es ist beruhigend, dass das wenigstens auf anderen Plattformen nicht aufkommt. >> Ich will nicht sagen früher war alles besser, >> aber alle alten Konzepte waren verdammt gut, und dürfen nicht einfach >> vergessen werden, sonst werden wir linux bald nichtmehr wiedererkennen. > > Also wenn ich zwischen SysV-Init, Upstart und systemd wählen darf, dann > nehme ich immer systemd. Es stimmt schon, systemd ist momentan das beste, aber es tut trotzdem zu viel. Dennoch muss ich zugeben, das ich es immernoch benutze.
Georg A. schrieb: > Es ist allerdings kein Problem, ein laufendes Binary (bzw. die Libs) zu > löschen oder umzubenennen und dann ein neues mit dem alten Namen zu > schreiben, egal ob NFS oder nicht. Die Shell-Umleitung mit > macht wohl > bei existierenden Files nur ein truncate, damit schlägt es mit ETXTBSY > an. Da bin aber beruhigt, daß ich nicht der einzige bin, der von Unix-Filessystemen nichts versteht. Zumindest wenn man der Win-Only-Fraktion Glauben darf. ;-) Auf das truncate wäre ich nicht gekommen, aber da kann man mal wieder sehen, wie man Dinge völlig falsch verstehen kann, wenn nur glaubt zu wissen. Ich beziehe mich da auf die erwähnten WOF's. Trennung von Namen und Inhalt ist aber auch ein so abstruses Konzept, daß es sogar WinNT im Innern, da wo es ein VMS++ ist, hat. Nur wird es nicht an die Oberfläche gelassen.
@ Carl Drexler (jcw2) >Zum Thema anmelden als root und Unix-Filesystem habe ich mal vor rund 20 >Jahren folgendes erlebt: Kollege sitzt an HP9000-Unix-Kiste, als root, >denn man muß ja alles unter Kontrolle haben und er ist irgendwann >genervt, weil was nicht so klappen will, wie geplant. Hämmert auf der >Tastatur rum und findet in der Command-History ein "rekursives Löschen". >Er befindet sich gerade da: / >Schupp waren alle Verzeichnisse samt Inhalt weg und es gab nur noch das Ja, ist aber nicht nur ein Problem für Root, sondern auch für jeden User, der wegen dieses "Unix-Vorteils" ebenfalls seine Daten ruinieren kann. Offensichtlich fehlt (oder zumindest fehlte) dem Unix/Linux grundsätzlich ein ordentlicher Lockingmechanismus auf Filesystemebene, der zwar die Onlineupdates wunderhübsch ermöglicht, aber ein versehentliches löschen/moven gelockter Dateien ebenso. Peter II schrieb: >Daniel A. schrieb: >> Holy shit!?! >Danke für die Bestätigung, ich hatte mich auch gewundert wo ich das zum >erst mal erlebt hatte. >Vermutlich macht es irgend wann immer Ärger wenn das Binary weg ist und >das Programm noch läuft. Ja, ist ja auch ein Märchen, daß sowas grundsätzlich und immer problemlos laufen soll. Daß das Binary weg ist, ist für sich alleine sicherlich nicht unbedingt das Problem, denn solange das Ding noch im Zugriff ist (Filehandle offen), sieht der Prozess das ja noch, auch wenn es auf FS-Ebene schon nicht mehr sichtbar ist. Das Problem sehe ich eher woanders: Eine Software, die aus mehreren zusammenpassenden Komponenten/Libs besteht, kann da ins Straucheln kommen, wenn die noch mit alten bin's läuft, und dann mal andere Libs dieser SW nachladen will, die inzwischen geupdated wurden. Dann paßt zur Laufzeit dann halt irgendwas nicht richtig zuammen, und der Prozess schmiert dann irgendwann ab (dann hätte man damit gleich den Neustart erledigt ...) Bei monolithischen Programmen wird das sicherlich problemloser gehen ...
> Eine Software, die aus mehreren zusammenpassenden Komponenten/Libs > besteht, kann da ins Straucheln kommen, wenn die noch mit alten bin's > läuft, und dann mal andere Libs dieser SW nachladen will, die inzwischen > geupdated wurden. Dann paßt zur Laufzeit dann halt irgendwas nicht > richtig zuammen, und der Prozess schmiert dann irgendwann ab (dann hätte > man damit gleich den Neustart erledigt ...) Also ein Prozess, Binary a.out hat libc geladen, dazu kommt eine Shared Lib, die auch libc braucht und diese wird dann nochmal in den Adressraum gemapped, könnte nun aber eine neue Version sein. So blöd ist keines der OSe, deren Vor- und Bachteile wir hier diskutieren. Die finden eine SharedLib/DLL, sollte sie schon geladen sein, im Adressraum des Prozesses und lösen die "externals"/"Imports" auf dem kurzen Dienstweg auf. Falls es an einem Sprachproblem liegt, einfach mal "shared" im Eng->De-Wörterbuch suchen.
Nein. Nix shared Lib mit offiziell definierten Schnittstellen, im Sinne von "jeder kann die nutzen". Sondern ein einfach in eine Lib ausgelagerter Teil des Programms (oder Programmpakets), speziell für dieses Programm, welche zusammen mit diesem Programm geliefert wird. Wenn die neue Programmversion + Lib plötzlich anders definierte Schnittstellen hat, altes Programm noch läuft, hatte aber bisher die alte Lib noch nicht genutzt, geupdatete Lib wird aber dann geladen, machts bumm ...
Jens G. schrieb: > Nein. Nix shared Lib mit offiziell definierten Schnittstellen, im Sinne > von "jeder kann die nutzen". Sondern ein einfach in eine Lib > ausgelagerter Teil des Programms (oder Programmpakets), speziell für > dieses Programm, welche zusammen mit diesem Programm geliefert wird. > Wenn die neue Programmversion + Lib plötzlich anders definierte > Schnittstellen hat, altes Programm noch läuft, hatte aber bisher die > alte Lib noch nicht genutzt, geupdatete Lib wird aber dann geladen, > machts bumm ... Jaja, auch bekannt als "SharedLibraryHell". Gut daß die bei Windows "DLL" heißen.
>sollte sie schon geladen sein
Das wäre gerade der Knackpunkt? Wenn eine Lib eingebunden wird, die
zuvor noch nicht geladen wurde, könnte doch dann potentiell eine nicht
mehr zur ausführenden SW-Version passende Version der Lib geladen werden
oder nicht?
Die Anwendung und Libs müssten für solche Szenarien ggf. ja eigentlich
speziell präpariert sein?
bluppdidupp schrieb: >>sollte sie schon geladen sein > Das wäre gerade der Knackpunkt? Wenn eine Lib eingebunden wird, die > zuvor noch nicht geladen wurde, könnte doch dann potentiell eine nicht > mehr zur ausführenden SW-Version passende Version der Lib geladen werden > oder nicht? > Die Anwendung und Libs müssten für solche Szenarien ggf. ja eigentlich > speziell präpariert sein? Also ich starte den Prozess vorgestern, mache gestern ein Update einer von ihm noch nicht benutzten Lib, die er heute laden will. Bin dann mal weg Haare spalten.
> Offensichtlich fehlt (oder zumindest fehlte) dem Unix/Linux > grundsätzlich ein ordentlicher Lockingmechanismus auf Filesystemebene, > der zwar die Onlineupdates wunderhübsch ermöglicht, aber ein > versehentliches löschen/moven gelockter Dateien ebenso. Es gibt natürlich File-Locks, nur braucht die in Unix anscheinend keiner als Default (wie unter Windows). Damit scheinst du mit der Windows-Brille Probleme zu sehen, was offensichtlich in der Unix-Welt seit >40 Jahren nicht als schwerwiegend erkannt wurde... Effektiv muss Windows ja trotz (wegen) der tollen Locks (oder wegen sonstwas, irgendwas ist ja immer) quasi mit jedem Update rebooten, um vor dem Runterfahren und kurz danach irgendwas anscheinend sonst nicht durchführbares zu machen. Klingt für mich jetzt nicht so nach der Weisheit letzter Schluss...
Rebooten stellt zumindest sicher, dass auch tatsächlich alle betroffenen Software-Komponenten direkt den jeweils aktuellsten Stand verwenden und nicht erst irgendwann. Mich persönlich stören die gelegentlichen Windows-Update Reboots ehrlich gesagt relativ wenig...
Die Updates der Linux Paketmanager sind nahezu Perfekt: 1) Einerseits gibt es fast keine Programme, die einfach so spontan finden: /oh, laden wir mal library XY nach/. Die wenigen verbleibenden Programme haben entweder ein Konzept zur Abwärtskompatibel, oder bauen einfach eine Versionsnummer in die Lib ein, und laden nicht zusammenpassende nicht. 2) Die gängigen Paketmanager wie z.B. apt erlauben den Paketen vorher und nachher Skripte auszuführen. Der Package maintainer sorgt dafür, das es beim und nach dem Update keine Probleme gibt. 3) Die gängigen Paketmanager wie z.B. apt können Dienste neu starten, wenn eine dessen Abhängigkeiten Aktualisiert wurde, falls man dies nicht ablehnt. Somit kann das beschriebene Problem der nicht zusammenpassenden Libries gar nie auftreten. Die Idee es so wie Windows zu machen wäre bescheuert. Es brächte keine Vorteile, und würde das Neustart Problem bekommen. Es gibt viele Unternehmen, bei dehnen ein Serverneustart zu grossen Finanziellen Verlusten oder anderen Risiken führen könnte. Klar, die haben ein Redundantes System falls eines Ausfällt, aber das Risiko wäre trotzdem höher. Stellt euch nur mal vor, Atomkraftwerke oder Krankenhauser würden Windows bei Operationen verwenden, und es käme ein Update...
Naja, ganz so problemlos ist das alles nicht. Kernel-Updates zum Beispiel ersetzen gern mal die Liste verfügbarer Module und dann sind die alten halt weg. Wenn man dann einen USB-Stick reinsteckt und vorher noch keinen drinstecken hatte, ist der FAT-Treiber der zum aktuell laufenden Kernel passt halt weg und es passiert gar nichts. Dann muss man doch neu starten, ... falls man drauf kommt warum es nicht geht. Aber ja, gerade beim Überschreiben von Dateien nehme ich den gelegentlichen Quirk gerne in Kauf, wenn ich im Ausgleich dafür nicht ständig diese unglaublich nervigen "konnte xy nicht überschreiben weil ist in irgendeinem blöden Programm gerade offen"-Meldungen bekomme.
Carl D. schrieb: > Also ich starte den Prozess vorgestern, mache gestern ein Update einer > von ihm noch nicht benutzten Lib, die er heute laden will. Shared Libraries werden beim Start geladen. Lediglich Plugin-Mechanismen haben die Möglichkeit, Shared Objects später nachzuladen. Updates von Shared Objects sollten Schnittstellen-kompatibel sein. Neue Funktionalität gehört in neue, zusätzliche Schnittstellenfunktionen. Jens G. schrieb: > Nein. Nix shared Lib mit offiziell definierten Schnittstellen, im Sinne > von "jeder kann die nutzen". Sondern ein einfach in eine Lib > ausgelagerter Teil des Programms (oder Programmpakets), speziell für > dieses Programm, welche zusammen mit diesem Programm geliefert wird. > Wenn die neue Programmversion + Lib plötzlich anders definierte > Schnittstellen hat, altes Programm noch läuft, hatte aber bisher die > alte Lib noch nicht genutzt, geupdatete Lib wird aber dann geladen, > machts bumm ... Es kann nur dann "Bumm" machen, wenn das Executable bzw. das Shared Object bei laufendem Prozess überschrieben wird. Das liegt daran, dass das Programm nicht - wie angenommen - in den Speicher geladen wird, sondern es wird ge-mmap-t, d.h. ausgeführtes Programm und Dateiinhalt sind nicht nur gleich, sie sind das selbe. Ändert man die Datei, so ändert man gleichzeitig das laufende Programm und dann passt eben der Programcounter nicht mehr zum Programm und es crasht. Löscht man das laufende Programm oder benennt es um und legt man es neu an, so hat das keine Auswirkung auf das laufende Programm, weil es eine andere Datei (d.h. ein anderer I-Node) ist.
Konrad S. schrieb: > Es kann nur dann "Bumm" machen, wenn das Executable bzw. das Shared > Object bei laufendem Prozess überschrieben wird. Das liegt daran, dass > das Programm nicht - wie angenommen - in den Speicher geladen wird, > sondern es wird ge-mmap-t, d.h. ausgeführtes Programm und Dateiinhalt > sind nicht nur gleich, sie sind das selbe. Ändert man die Datei, so > ändert man gleichzeitig das laufende Programm und dann passt eben der > Programcounter nicht mehr zum Programm und es crasht. Löscht man das > laufende Programm oder benennt es um und legt man es neu an, so hat das > keine Auswirkung auf das laufende Programm, weil es eine andere Datei > (d.h. ein anderer I-Node) ist. Aber nur im Fall von XIP
foobar schrieb: > Aber nur im Fall von XIP Ich nehme an, du meinst damit "execute in place". Nun, da es in diesem Thread um Linux geht: Das ist der Normalfall.
Sven B. schrieb: > Naja, ganz so problemlos ist das alles nicht. Kernel-Updates zum > Beispiel ersetzen gern mal die Liste verfügbarer Module und dann sind > die alten halt weg. Wenn man dann einen USB-Stick reinsteckt und vorher > noch keinen drinstecken hatte, ist der FAT-Treiber der zum aktuell > laufenden Kernel passt halt weg und es passiert gar nichts. Dann muss > man doch neu starten, ... falls man drauf kommt warum es nicht geht. Da war was anderes schuld. So, wie du es beschreibst, ist technisch unmöglich. Die Module für eine Kernelversion sind in einem Ordner passend zur Versionsnummer (/lib/modules/<version>). Jedes Kernelupdate, selbst wenn es nur ein winziger Patch ist und kein echtes Update, verändert die Versionsnummer, damit landen die Module dazu in einem neuen Ordner. Der alte Ordner wird nicht entfernt, ausser man entfernt ihn manuell. Damit ist alles noch da, solange der alte Kernel läuft. Wenn man natürlich irgendwas abseits dieser offiziellen Wege macht (Module kann man von überall her laden), kann das passieren. Das machen aber normale Paketverwaltungstools nicht.
Georg A. schrieb: > Der alte Ordner wird nicht entfernt, ausser man entfernt > ihn manuell. Damit ist alles noch da, solange der alte Kernel läuft. [...] > Das machen > aber normale Paketverwaltungstools nicht. shrug pacman macht das. Sonst wären ja da nach den fünf Jahren Updates die ich hier für den Kernel schon mache ungefähr 300 Ordner mit Kernelmodulen ...
Dann wäre das aber ein Sch31ss Paketmanager, wenn er nicht mal die aktuell laufende Kernelversion aufbewahrt, damit man bei Problemen mit der neuen die alte wieder starten kann. Daher glaube ich das nicht und tippe auf eine Fehlkonfiguration.
@ Konrad S. (maybee) >foobar schrieb: >> Aber nur im Fall von XIP >Ich nehme an, du meinst damit "execute in place". >Nun, da es in diesem Thread um Linux geht: Das ist der Normalfall. Wirklich? Das mag vielleicht auf embedded Systemen, oder anderer speziellen Linuxungebungen mit entsprechender HW der Fall sein, aber wenn ich danach in Bezug auf normale Linux-PCs suche, finde ich herzlich wenig. Nach meinem Verständnis würde XIP bedeuten, daß sich die CPU jedes Byte einzeln von der Platte holen darf, und nicht erst in den Arbeitsspeicher lädt. Das stelle ich mir auf normalen und üblichen Architekturen als schwer inperformant vor.
Konrad S. schrieb: > Carl D. schrieb: >> Also ich starte den Prozess vorgestern, mache gestern ein Update einer >> von ihm noch nicht benutzten Lib, die er heute laden will. > > Shared Libraries werden beim Start geladen. Lediglich Plugin-Mechanismen > haben die Möglichkeit, Shared Objects später nachzuladen. Updates von > Shared Objects sollten Schnittstellen-kompatibel sein. Neue > Funktionalität gehört in neue, zusätzliche Schnittstellenfunktionen. Falls das nicht richtig rübergekommen sein sollte: Ich habe nur mit meinen Worten beschrieben, was der WinOnly-Kollege zuvor als typisches Unix-Problem erkannt zu haben glaubte. Und das ich das etwas extrem gezeichnet habe, soll eigentlich nur die absurdität dieser Vorstellung zeigen. In der Sache haben wir das gleich Verständnis der Vorgänge und unser Verständnis wurde auch genau so implementiert ;-)
Zur Verbreitung: Ich bin mir sicher, dass Linux deutlich weiter verbreitet ist. Denkt man mal an alle Server, Smartphones, Switches, Router (auch die privaten wie FritzBox), Netzwerkfestplatten, Internetradios, etc. Zur Sicherheit: Ich habe bei Windows nach jeder Neuinstallation Angst, wenn ich mir Treiber und Software aus dubiosen (und teilweise http) Quellen herunterlade. Und das soll ich dann meistens auch noch unter Administratorenrechten ausführen... Außerdem nerven die ganzen Einzelprogramme unter Windows fürchterlich. Jedes Programm möchte beim Öffnen Updates herunterladen oder tut es ohnne, dass ich es weiß (und gerade per UMTS drin bin). Außerdem muss ich bei einer Neuinstallation erstmal 15 Webseiten aufrufen, Programme herunterladen, mich durch 15 verschiedenen Installationsprogramme durchklicken und danach wieder alles aufräumen. Die Kommandozeile ist unter Windows auch nicht wirklich zu gebrauchen.
Hallo Na, jetzt übertreibst du aber kräftig. Wenn man sich nur ein wenig informiert, mitdenkt und in den Einstellungen der Programme bzw. von Windows selbst umsieht ist es bei weiten nicht so schlimm wie du das darstellst. Natürlich muss man sich dann auch mit Windows, ähnlich wie bei einer Linuxdistribution auseinandersetzen. Wenn man natürlich nur den einfachsten Weg geht und alles "Blind" abhakt bzw. die Konfiguration von Windows und den Programmen so lässt wie sie "geliefert" werden dann ist dein beschriebenes Verhalten nicht weit von der Realität entfernt. Das ist aber bei den "Massen Linuxdistributionen" (z.B. Ubuntu) auch nicht so viel besser. Mit beiden (allen) Betriebssystemen muss man sich halt auseinandersetzen wenn man wenigsten zu einen gewissen Grad Wert auf seine Daten legt, zügig Arbeiten möchtet und auf das Online Datenvolumen achten muss. Und was man besser findet: -Einzelprogramme die von Überall Problemlos heruntergeladen werden können halt mit entsprechenden Gefahren die aber mit Einsatz von "Gehirn 1.0" doch überschaubar sind. oder -Das Paketkonzept das zwar sehr sicher und einfach ist wenn die gewünschte Software im Paket vorhanden ist, es aber doch recht umständlich wird Software die nicht direkt aus den Paketquellen stammen zum laufen zu bringen ist halt Ansichtssache und weder die eine noch die andere Seite hat das Recht darüber her zu ziehen. Win Nutzer
Georg A. schrieb: > Dann wäre das aber ein Sch31ss Paketmanager, wenn er nicht mal die > aktuell laufende Kernelversion aufbewahrt, damit man bei Problemen mit > der neuen die alte wieder starten kann. Daher glaube ich das nicht und > tippe auf eine Fehlkonfiguration. Joa, glauben und Tippen war ja schon immer die richtige Variante an Informationen zu gelangen wenn man das betreffende Programm noch nie gesehen hat.
Peter II schrieb: > Weil ich RS232 und die IO-Pins brauche. Einfache Lösung: Installiere Windows auf Deinem Pi. Dann klappt das bestimmt auch mit dem IO-Pin.
Marc H. schrieb: > Ich finde es interessant wie die Linux-User generell den Windows-User > erklären wie dumm sie sind! Schon mal daran gedacht das auch Windows > seine Berechtigung hat? Klarhat es das, aber richtige Linuxuser halten Winuser nicht für Idioten, das machen nur möchtegernXbuntuKlickAdmins. Ich hab es meistens so mitbekommen, daß die Linuxuser, ab und zu auch *BSDuser, den Winusern wirklich geholfen hatten bei Problemen statt wie die Windowsexperten mit Tipps wie: "installier erstmal Registrycleaner und diverse Software (laesst sich in der Computerbild zu hauf finden :P) und dann noch in Registryeintrag und datei xyz019 rumpfuschen.'. Linux ist noch sicherer als Windows. Aber das wird sich noch ändern. Mehr User vergrössern das Interesse der Kriminellen, und je mehr Nutzer Linux nutzen, desto mehr legen auch keinen Wert mehr auf Sicherheit, sondern auf Einfachheit, und werden als root arbeiten, oder ähnliches. Das gösste problem ist immernoch PEBCAC. MS hat zwar leichtsinnigen Umgang mit dem PC hervorgerufen, aber die Leute werden nicht klüger.
Ein Student schrieb: > Ich habe bei Windows nach jeder Neuinstallation Angst, > wenn ich mir Treiber und Software aus dubiosen (und teilweise http) > Quellen herunterlade. Aber sowas macht man doch sowieso nicht. Was sollen das für 'dubiose Quellen' sein, von denen man sich Treiber lädt? Damit kann man jedes System komprommitieren - völlig egal ob Mac OS, Linux, Windows oder ein beliebiges anderes.
I. Ich stelle hier mal eine These auf, die ich bisher so nicht gefunden habe: Linux ist sicherer, da eine Grundinstallation weniger Programmcode benötigt. Begründung: https://de.wikipedia.org/wiki/Fehlerquotient Linux(Mint) benötigt für Office (Libre), Email(TB) und Browser(FF) ca. 5GB. Win7_64 fängt da bei ca. 30GB an. Mit vergleichbaren Fehlerquotienten pro Zeile ist Linux daher mindestens 6 mal sicherer(stabiler...). Mir ist schon klar, dass ich hier Quellcode mit Binaries vergleiche und auch unterschiedliche Compiler/libs etc. in eine Topf werfe. Da im Endergebnis aber die 6-Fache Menge an Bins anscheinend benötigt wird, sollte sich das aber dennoch bemerkbar machen. worstcase: http://www.damnsmalllinux.org/index_de.html mit 50MB wird hier optimal sein. Ich suche allerdings einen guten Kompromiss zwischen Komfort und Sicherheit. Die Möglichkeit von Codereviews (von Vielen) an offenen Quellen, erhöht für mit zudem die Güte einer Software. II. Marktverbreitung /Linux: Im übrigen erkenne ich keinen Grund, den angenommenen Sicherheitsvorteil aufgrund des geringen Linux-Anteils auf Desktopsystemen, nicht jetzt zu nutzen. Sollten sich die aktiven Bedrohungen für Linux tatsächlich merklich erhöhen, wird in ein paar Jahren halt ein anderes -sicheres- OS genommen. Besonders für MS/Windowsanwender sehe ich generell eine Umstellung auf ein anderes OS als problemlos an. Sie werden ohnehin alle 2-3 Jahre gezwungen, sich an eine neue Oberfläche anzupassen (Lebenslanges Lernen);-)
Hab jetzt nicht jeden Kommentar gelesen aber ich finde auch, dass Linux viel sicher ist als Win. Ich benutze seit XP Linux Suse und ich bin völlig zufrieden. Mir ist noch kein Trojaner, Virus, etc untergekommen. Und was die Performance angeht, kann ich sagen, dass meine Susi ( Linux Suse ) die Nase ganz weit vorne hat. Natürlich gilt das auch für die anderen Distris. Vor Allem bei Multimediaanwendungen wie HD Videos, CAD Verarbeitung, o.ä. Alles lauft viel fluessiger... :-) Wer bei Windows UND bei Linux einmal den Fortschrittsbalken eines HD Videos mit der Maus gepackt hat und nach belieben schnell die Maus nach rechts und links bewegt hat, der weiss, was Performance ist. :-) Natürlich bei gleicher Hardware... Windows ist halt auch fuer Hans Mustermann und die ganzen Dorftrotteln, die ueberhaupt keine Ahnung haben. Die sollen sich auch schoen aussaugen lassen. :-) Die checkens eh nicht wenn sie Mitglied eines tollen Botnets sind. Das technische Niveau eines Linux Users ist im Schnitt sicher höher als bei Windows Usern.
Sven B. schrieb: > Georg A. schrieb: >> Dann wäre das aber ein Sch31ss Paketmanager, wenn er nicht mal die >> aktuell laufende Kernelversion aufbewahrt, damit man bei Problemen mit >> der neuen die alte wieder starten kann. Daher glaube ich das nicht und >> tippe auf eine Fehlkonfiguration. > > Joa, glauben und Tippen war ja schon immer die richtige Variante an > Informationen zu gelangen wenn man das betreffende Programm noch nie > gesehen hat. Richtig, habe ich in meinen 22 Jahren Linux-Bastelei noch nie gesehen. Aber wenn dieser Paketmanager beim Kernelupdate ohne Not die aktuell laufende Version löscht, dann ist er einfach Dreck und damit schlimmer als alles, was Windows so macht. Punkt.
Peter II schrieb: > Udo N. schrieb: >> Ach... Und das Einfallstor Outlook (Word als Editor/Viewer, Vorschau mit >> IE) gibt es auch für Linux? Ich kenne kaum ein Mailprogramm, dass so >> unsicher konfiguriert geliefert wird wie Outlook. > du redest über 15Jahre alte Software, schon mal ein aktuelles Windows > und Outlook gesehen? Wenn du hier weiter gelesen hättest, dann hättest du bereits die Antwort gehabt. Und ja, ich habe Win 10 getestet und auch schon neuere Outlook-Versionen gesehen. > Udo N. schrieb: >> Schon ist dein Beispiel widerlegt: CONFIG_USB_SERIAL_CP210X=m im Kernel >> 4.6 (aktuell hier im Einsatz). Eine kurze Recherche ergab sogar schon >> für Kernel 3.13 einen Treffer. > > leider ist das eine veraltete Version vom Treiber, dieser unterstützt > die IO-Pins nicht. Beim Hersteller gibt es dafür einen neuen Treiber. Soviel ich gesehen habe, war das nicht Gegenstand deines Posts. Es ging nur um einen Treiber, nicht um eine Funktion in einem Treiber.
Sven B. schrieb: > Naja, ganz so problemlos ist das alles nicht. Kernel-Updates zum > Beispiel ersetzen gern mal die Liste verfügbarer Module und dann sind > die alten halt weg. Nein. Nie erlebt. Zumindest bei Debian-basierten Systemen wird einfach ein neuer Kernel samt Modulen installiert, die alten bleiben unangetastet und funktionieren weiterhin.
Sheeva P. schrieb: > ntel hat sogar schon den > Mir-Support aus seinen Grafiktreibern entfernt. Richtig so. Der hat da auch null und nichts zu suchen. Der Treiber soll die Hardware abstrahieren, sonst nichts. Und ob der Brocken Software der ihn benutzen will nun zufällig "Mir" heißt oder "xorg" oder "Mesa" oder "Wayland" geht ihn nicht die Bohne was an.
Georg A. schrieb: > Sven B. schrieb: >> Georg A. schrieb: >>> Dann wäre das aber ein Sch31ss Paketmanager, wenn er nicht mal die >>> aktuell laufende Kernelversion aufbewahrt, damit man bei Problemen mit >>> der neuen die alte wieder starten kann. Daher glaube ich das nicht und >>> tippe auf eine Fehlkonfiguration. >> >> Joa, glauben und Tippen war ja schon immer die richtige Variante an >> Informationen zu gelangen wenn man das betreffende Programm noch nie >> gesehen hat. > > Richtig, habe ich in meinen 22 Jahren Linux-Bastelei noch nie gesehen. > Aber wenn dieser Paketmanager beim Kernelupdate ohne Not die aktuell > laufende Version löscht, dann ist er einfach Dreck und damit schlimmer > als alles, was Windows so macht. Punkt. Wenn du das sagst, wird das wohl so sein.
Daniel A. schrieb: > Sheeva P. schrieb: >> Du hälst es für die richtige Richtung, laufende Binaries zu >> überschreiben? > > Ich sehe zumindest kein Problem damit. Nach meinem momentanen > Verständnis wird ein Programm beim Starten in den RAM geladen. Wieso > sollten also Änderungen an der Programmdatei Auswirkungen am bestehenden > Prozess haben? Es ist natürlich grundsätzlich korrekt, daß ein Executable beim Start in den Speicher geladen wird. Der Punkt ist jedoch, wie das gemacht wird, nämlich aus Effizienzgründen mit mmap(2) und einer Technik namens "demand paging". Das bedeutet: es werden immer nur die Speicherseiten des Executable in den Speicher gemappt, die auch angefordert, also: benutzt werden... Siehst Du das Problem?
:
Bearbeitet durch User
Sheeva P. schrieb: > as bedeutet: es werden immer nur die Speicherseiten > des Executable in den Speicher gemappt, die auch angefordert, also: > benutzt werden... Siehst Du das Problem? Kein Problem. Die Blöcke der überschriebenen Datei könnten auf dem Datenträger bleiben und das bestehende Mapping unverändert aufrechterhalten werden solange bis es freigegeben wurde. Der Kernel könnte das transparent im Hintergrund erledigen.
Bernd K. schrieb: > Sheeva P. schrieb: >> as bedeutet: es werden immer nur die Speicherseiten >> des Executable in den Speicher gemappt, die auch angefordert, also: >> benutzt werden... Siehst Du das Problem? > > Kein Problem. Die Blöcke der überschriebenen Datei könnten auf dem > Datenträger bleiben und das bestehende Mapping unverändert > aufrechterhalten werden solange bis es freigegeben wurde. Der Kernel > könnte das transparent im Hintergrund erledigen. Gemapped wird bei Unix der Filecontent hinter der inode. Ein Name ist nur ein Alias auf diese. Wird der Name gelöscht, bezeichnenderweise mit dem Systemcall "unlink", existiert die inode weiter, solange bis sie niemand mehr benutzt. Und "Jemand" wäre ein anderer "Alias"/Name oder ein Filemapping, das einem Prozess den Inhalt dieser Datei bereitstellen soll oder jede andere Art geöffneter Datei. "unlink" geht immer. Nur den Kontent ändern, wie oben schon mal per "Echo >DateiDieNunAufLängeNullGesetztWird" versucht, geht nicht. Wer glaubt "unlink" und "truncate" wäre das gleiche, der irrt.
Bernd schrieb im Beit > 4. Bei Linux wird so ziemlich alle Software von der Distribution > angeboten, ist mit wenigen Klicks (oder über Kommandozeile) installiert > und wird automatisch aktuell gehalten. Ich mach mal weiter ... 5. Super Update Management. Bei Debian mit apt-get update && apt-get upgrade ist alles erledigt. Ganz anders als bei Windoofs. 6. Closed Source wie Microsoft oder Apple kann man grundsätzlich nicht trauen. Open Source Software kann von jedem der dazu in der Lage ist auditiert werden (Bsp. True Crypt). Reproduzierbare Builds (Debian) bieten (bald) Sicherheit das das binary aus vertrauenswürdigem Quelltext kommt. 7. Es gibt kaum cripple ware o. ä. bei Linux. Damit meine ich in der Funktion beschränkte Software. Die einzige Einschränkung die mich noch nervt ist das es kein wirklich gutes, freies 3d CAD gibt. Freecad finde ich noch am besten. Mit den passenden Add-Ons gepimpt ist es nicht schlecht aber noch sehr weit von professionellen Systemen entfernt.
Walter Lehmann schrieb: > 6. Closed Source wie Microsoft oder Apple kann man grundsätzlich nicht > trauen. Open Source Software kann von jedem der dazu in der Lage ist > auditiert werden (Bsp. True Crypt). Reproduzierbare Builds (Debian) > bieten (bald) Sicherheit das das binary aus vertrauenswürdigem Quelltext > kommt. Nein. Und mal wieder der Hinweis auf einen Klassiker: Ken Thompson, Reflections on Trusting Trust "No amount of source-level verification or scrutiny will protect you from using untrusted code...". https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf Das gilt heute umso mehr für alle Systeme von größeren ARMs mit TrustZone bis zu CPUs mit Intels "Trusted" Execution Technology/SMM/AMT oder AMDs Platform Security Processor etc. usw. usf. > 7. Es gibt kaum cripple ware o. ä. bei Linux. Damit meine ich in der > Funktion beschränkte Software. Nach der üblichen Definition nicht, nach der wörtlichen könnte man anderer Ansicht sein...
Arc N. schrieb: > Walter Lehmann schrieb: >> 6. Closed Source wie Microsoft oder Apple kann man grundsätzlich nicht >> trauen. Open Source Software kann von jedem der dazu in der Lage ist >> auditiert werden (Bsp. True Crypt). Reproduzierbare Builds (Debian) >> bieten (bald) Sicherheit das das binary aus vertrauenswürdigem Quelltext >> kommt. > > Nein. Und mal wieder der Hinweis auf einen Klassiker: Ken Thompson, > Reflections on Trusting Trust > "No amount of source-level verification or scrutiny will protect you > from using untrusted code...". > https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf > Das gilt heute umso mehr für alle Systeme von größeren ARMs mit > TrustZone bis zu CPUs mit Intels "Trusted" Execution Technology/SMM/AMT > oder AMDs Platform Security Processor etc. usw. usf. Wie schon in anderen Threads hier zu ähnlichen Themen bis zum umfallen diskutiert, gewiss ist nur der Tod. Es könnte immer sein, dass schon die CPU eine Backdoor hat und du das nicht merkst. Den Gewinn an Wissen darüber, was dein Computer tatsächlich tut, der durch offen liegenden Quellcode entsteht, mit solch einem Argument komplett vom Tisch zu wischen ist aber einfach lächerlich. Es ist eine "hundert Prozent sicher wird es sowieso nicht, also können wir uns die ersten 99 Prozent auch sparen"-Argumentation, die einfach nicht schlüssig ist.
:
Bearbeitet durch User
Hin und wieder wird ja angeführt, dass bei Open Source der Compiler unbemerkt Backdoors etc. in das Binary compilieren könnte: http://www.heise.de/newsticker/meldung/Visual-Studio-2015-stopft-ungefragt-Tracing-Code-in-C-Programme-3235676.html Manchmal überholt die Realität halt die kühnsten Phantasien, wundert mich bei MS aber nicht wirklich... Jörg
Sven B. schrieb: > Wie schon in anderen Threads hier zu ähnlichen Themen bis zum umfallen > diskutiert, gewiss ist nur der Tod. Es könnte immer sein, dass schon die > CPU eine Backdoor hat und du das nicht merkst. Worauf die FSF vor ein paar Tagen noch einmal hingewiesen hat... "Intel & ME, and why we should get rid of ME" http://www.fsf.org/blogs/licensing/intel-me-and-why-we-should-get-rid-of-me oder auch die Anstrengungen einen komplett offenen PowerPC-basierten Desktop auf den Markt zu bringen: https://www.raptorengineering.com/TALOS/prerelease.php > Den Gewinn an Wissen > darüber, was dein Computer tatsächlich tut, der durch offen liegenden > Quellcode entsteht, mit solch einem Argument komplett vom Tisch zu > wischen ist aber einfach lächerlich. Die Behauptung war allerdings, dass man "Closed Source ... grundsätzlich nicht trauen" kann und dies gilt ebenso grundsätzlich auch für Open Source. Nicht mehr und nicht weniger. Daraus zu konstruieren, dass damit auch gleich Open Source oder der Ansatz abgelehnt wird, ist etwas sehr weit hergeholt... > Es ist eine "hundert Prozent sicher > wird es sowieso nicht, also können wir uns die ersten 99 Prozent auch > sparen"-Argumentation, die einfach nicht schlüssig ist. Es hilft nur nichts, wenn diese 99% sicher sind und die 1% im bspw. Prozessor, in der GPU, im BIOS usw. usf. es nicht sind bzw. diesen nicht vertraut werden kann (siehe u.a. FSF-Post) und nur als Binärblobs vorliegen...
Arc N. schrieb: > Es hilft nur nichts, wenn diese 99% sicher sind und die 1% im bspw. > Prozessor, in der GPU, im BIOS usw. usf. es nicht sind bzw. diesen nicht > vertraut werden kann (siehe u.a. FSF-Post) und nur als Binärblobs > vorliegen... Na doch, es reduziert die Anzahl der Leute denen du vertrauen musst.
Manchmal glaube ich es gibt da dieses Missverständnis, dass alle Benutzer von Linux andere davon überzeugen wollen es auch zu benutzen. Das ist falsch. Den meisten die ich kenne, und mir selber ist das völlig egal was andere sich jeden Tag mit Windows antun. Wenn jemand dafür bezahlt und sich das freiwillig installiert, soll er das doch benutzen.
>Wenn jemand dafür bezahlt und sich das freiwillig installiert, soll er >das doch benutzen. Naja, die meisten Leute haben Windows auf ihrem Rechner, weil es eben von Anfang an drauf war. Wenn sie es selbst installieren müssten (incl. aller Treiber) würden die meisten wohl daran scheitern. Und viele davon werden meiner Meinung nach auch nie begeifen, dass "Kennt sich mit Computern aus" eben nicht das Gleiche wie "Kennt sich mit der Windows-Version auf meinem Computer aus" ist. Genauso wie für manche zu gelten scheint: Internet=Facebook+Youtube Das liegt aber nicht daran, dass sie nun für alles Andere "zu doof" sind, sondern dass ihnen von den großen IT-Konzernen das selbstständige Denken langsam abtrainiert wird. So langsam, dass sie selbst es gar nicht merken, aber als "Außenstehender" merkt man das. Leute, die sich unter XP in den meisten Fällen selbst zu helfen wussten, sind bei Win10 ohne Hilfestellung praktisch nicht mehr in der Lage, allein die "Problembehebung" zu finden. Sie würden das wahrscheinlich auch alleine finden, aber sie wollen es gar nicht mehr. Und ich kenne Leute, für die ist (partieller) Datenverlust gegenüber regelmäßigem Backup das kleinere Übel. Weil Backup Aufwand bedeutet. Vor allen Dingen den Aufwand, zu überlegen, wo sich eigentlich die Bilder, Briefe, Adressbücher und Videos liegen, die man ungern verlieren möchte auf dem Rechner befinden. Aber zurück zum Thema. Wer sich Linux installiert, tut dies meist bewusst, entscheidet oft, welche Dienste/Server er mit installiert. Und hat zumindest eine ungefähre Vorstellung davon, was eigentlich so ein Computer macht. Das ist meiner Meinung nach der größte Sicherheitsvorteil von Linux, dass man sich damit auseinandersetzen muß. Gut, es gibt auch viele, die sich mit Windows beschäftigen und ihre Rechner entsprechend absichern, aber unter den Milliarden? Windows-Nutzern sind sie wohl eher eine kleine Minderheit. Auch wenn das in technischen Foren wie hier anders auszusehen scheint. Jörg
Joerg W. schrieb: > Wer sich Linux installiert, tut dies meist bewusst, entscheidet oft, > welche Dienste/Server er mit installiert. Und hat zumindest eine > ungefähre Vorstellung davon, was eigentlich so ein Computer macht. Das bringt es ziemlich auf den Punkt.
Windows hat genau wie Facebook oder Whatsapp den Vorteil das sie Marktführer sind und Alternativen wegen mangelnder Kompatibilität überhaupt keinen Boden fassen können. Wenn sie beispielsweise ihr Office Packet nicht inkompatibel zu allem anderen machen würden, würden sich vielleicht viel mehr menschen Fragen warum sie Geld für etwas ausgeben sollen was wo anders umsonst ist... Ich hab gehört, dass Microsoft in letzter Zeit immer mehr mit Canonical (Die Macher von Ubuntu) machen. Hauptsächlich weil die alles was mit Cloud zu tun hat einfach besser drauf haben. Meint ihr das sich da so langsam was tun? Ich meine Microsoft wird sich hüten ihr Office für Libre kompatibel zu machen aber da könnte was entstehen.
David G. schrieb: > Windows hat genau wie Facebook oder Whatsapp den Vorteil das sie > Marktführer sind und Alternativen wegen mangelnder Kompatibilität > überhaupt keinen Boden fassen können. Wenn sie beispielsweise ihr Office > Packet nicht inkompatibel zu allem anderen machen würden, würden sich > vielleicht viel mehr menschen Fragen warum sie Geld für etwas ausgeben > sollen was wo anders umsonst ist... > > Ich hab gehört, dass Microsoft in letzter Zeit immer mehr mit Canonical > (Die Macher von Ubuntu) machen. Hauptsächlich weil die alles was mit > Cloud zu tun hat einfach besser drauf haben. Meint ihr das sich da so > langsam was tun? Ich meine Microsoft wird sich hüten ihr Office für > Libre kompatibel zu machen aber da könnte was entstehen. Wegen des Mißbrauchs seiner Marktposition ist Microsoft bereits mehrmals rechtskräftig verurteilt worden, unter anderem zur Offenlegung der Office-Dateiformate. Deswegen hat Microsoft schon früher mit Novell (SuSE Linux) kooperiert, um die Import- und Export-Plugins für OpenOffice zu verbessern. Unter dem neuen CEO Satya Nadella scheint sich Microsoft zudem noch weiter zu öffnen. So soll Windows zukünftig auch ELF-Binaries ausführen und aus Apt-Repositories installieren zu können, wie Microsoft auf seiner letzten Entwicklerkonferenz gezeigt hat. Ich ganz persönlich nehme an, daß das tatsächlich daran liegt, daß MS mit Ausnahme des Desktops langsam die Felle wegschwimmen. Das Markt ändert sich, nicht schnell, aber stetig, und auf den neuen Geschäftsfeldern von Social Media über Mobile und Embedded-Devices bis Cloud- und Distributed Computing tut sich MS sehr schwer, Fuß zu fassen. Wenn MS da den Anschluß behalten und wenigstens seine angestammte Desktop-Marktführerschaft halten will, muß es für mehr Interoperabilität sorgen. Insofern ist die neue MS-Strategie sicherlich kein Ergebnis neu gewonnener Menschen- oder Wettbewerbsfreudigkeit, sondern eine aus der Not geborene und sicherlich nicht eben geliebte strategische Businessentscheidung. Aber wenn das zu mehr Offenheit, Interoperabilität und Wettbewerb führt, ist das für die Nutzer sicherlich erfreulich.
maladroid schrieb: > Manchmal glaube ich es gibt da dieses Missverständnis, dass alle > Benutzer von Linux andere davon überzeugen wollen es auch zu benutzen. > Das ist falsch. Sicher nicht alle. Und ganz sicher nicht wirkliche Linux-Profis ohne Scheuklappendenken, weil sie genau wissen, daß auch Linux nicht zum Stein der Weisen führt. Trotzdem ist es symptomatisch, daß mit tödlicher Sicherheit in fast jedem Thread mit Fragen zu Windows alsbald ein Tux-Fanboy auftaucht, der zur Problemlösung null beizutragen hat aber sich verpflichtet fühlt, Linux wie sauer Bier anzupreisen. Man stelle sich vor, in Linux-Foren würden regelmäßig Windows-User auftauchen und den Spieß umdrehen...
Walter Lehmann schrieb: > Open Source Software kann von jedem der dazu in der Lage ist > auditiert werden (Bsp. True Crypt). Theoretisch stimmt das. Aber realistisch betrachtet existieren nur sehr wenige Leute, die das nötige Wissen besitzen. Aufgrund der schieren Größe des Quelltextes aktueller Software, der vom Linux-Kernel hat bspw. schon über 15 Millionen Zeilen, ist es einem einzelnen Programmierer außerdem gar nicht möglich, mal eben schnell einen Audit durchzuführen. Das braucht erheblich viel Zeit und ein gut zusammenarbeitendes Experten-Team und daher werden Audits i.d.R. nicht pauschal, sondern nur auf besonderen Anlaß gestartet. Nicht ohne Grund blieben die eklatanten Sicherheitslecks in SSL und Bash sehr lange Zeit unentdeckt. Die Quelloffenheit als solche ist ergo überhaupt kein Argument für Sicherheit.
:
Bearbeitet durch User
Sehr gutes Argument, weil ein Mechanismus manchmal versagt, der bei einem anderen Modell nichtmal existiert, braucht man ihn nicht. Oder: weil Sicherheitsgurte und Airbags schon mal Todesfälle nicht verhindert haben, sind sie überflüssig. Noch schlimmer Bremsen. Ich hatte schon mal einen Totalausfall eines Hauotbresmezylinders. Zum Glück gleich beim vom Hof fahren. Eindeutiger Fall: Bremsen braucht man nicht. Und wie schon Walter Lehmann schrieb: > Open Source Software kann von jedem der dazu in der Lage ist > auditiert werden (Bsp. True Crypt). Wenn es also Leute gibt, die mit einem Quelltext des Linux-Kernels nichts anfangen können, dann braucht man ihn auch keinem anderen geben. Wenn ich jetzt mit dem Quelltext von Windows was anfangen kònnte, bekomm ich ihn dann? Es handelt sich da um simple Logik, die offenbar zu den komplexesten Problemen zählt, die die Mathematik zu bieten hat. [Satire] Trotzdem ist es symptomatisch, daß mit tödlicher Sicherheit in fast jedem Thread mit Fragen zu Linux alsbald ein Windows-Fanboy auftaucht, der zur Problemlösung null beizutragen hat aber sich verpflichtet fühlt, Windows wie sauer Bier anzupreisen. Man stelle sich vor, in Windows-Foren würden regelmäßig Linux-User auftauchen und den Spieß umdrehen... [/Satire] Der Title dieses Threads: "Sicherheitsvorteil durch Linux" Warum entwickelt sich das dann zur Real-Version obiger Satire? Anderes Beispiel: "Rootpasswort für Raspberry3" Häufigste Aussage: "warum macht Linux dies und das anders als Windows" Mehr braucht man dazu nicht sagen.
Icke ®. schrieb: > Die Quelloffenheit als solche ist ergo überhaupt kein Argument für > Sicherheit. Doch, ist sie. Sie ist vielleicht kein Garant für Sicherheit, aber sie ist in meinen Augen Voraussetzung dafür. Also notwendig, aber nicht hinreichend.
Rolf M. schrieb: > Icke ®. schrieb: >> Die Quelloffenheit als solche ist ergo überhaupt kein Argument für >> Sicherheit. > > Doch, ist sie. Sie ist vielleicht kein Garant für Sicherheit, aber sie > ist in meinen Augen Voraussetzung dafür. Also notwendig, aber nicht > hinreichend. Intel hat längst eine Hintertür in die Prozessoren eingebaut, natürlich closed source und OS Unabhängig: https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Security Vielleicht sollte ich mir das mal vorknöpfen...
Daniel A. schrieb: > Rolf M. schrieb: >> Icke ®. schrieb: >>> Die Quelloffenheit als solche ist ergo überhaupt kein Argument für >>> Sicherheit. >> >> Doch, ist sie. Sie ist vielleicht kein Garant für Sicherheit, aber sie >> ist in meinen Augen Voraussetzung dafür. Also notwendig, aber nicht >> hinreichend. > > Intel hat längst eine Hintertür in die Prozessoren eingebaut, natürlich > closed source und OS Unabhängig: > https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Security > > Vielleicht sollte ich mir das mal vorknöpfen... Gut daß manches OS nicht nur auf Intel läuft.
Carl D. schrieb: > Wenn es also Leute gibt, die mit einem Quelltext des Linux-Kernels > nichts anfangen können, dann braucht man ihn auch keinem anderen geben. Rolf M. schrieb: > Icke ®. schrieb: >> Die Quelloffenheit als solche ist ergo überhaupt kein Argument für >> Sicherheit. > > Doch, ist sie. Sie ist vielleicht kein Garant für Sicherheit, aber sie > ist in meinen Augen Voraussetzung dafür. Also notwendig, aber nicht > hinreichend. Es nützt nunmal nichts, wenn die Quellen zwar offen liegen, deren Überprüfung jedoch daran scheitert, daß nur wenige Leute dazu überhaupt in der Lage sind und obendrein ein immenser manueller und zeitlicher Aufwand nötig ist. "Kann doch jeder die Quelltexte prüfen" stimmt eben nur in der Theorie. Die Praxis sieht leider anders aus, wie man an den schon genannten, lange nicht entdeckten Lücken in Bash und SSL unzweifelhaft erkennen konnte. Und manche Bugs werden nichtmal bei Audits bemerkt, siehe Truecrypt: http://www.golem.de/news/truecrypt-sicherheitsluecken-in-open-source-verschluesselung-1509-116596.html Wenn schon hochprofessionelle, bezahlte Codespezialisten versagen, wer soll es dann packen? Weiterhin ist nicht von der Hand zu weisen, daß Open Source den Crackern auch Vorteile verschafft, denn frei zugängliche Quelltexte ersparen mühsames Reverse Engineering. Carl D. schrieb: > Der Title dieses Threads: "Sicherheitsvorteil durch Linux" > Warum entwickelt sich das dann zur Real-Version obiger Satire? Das tut es nur, weil du mich aus dem Kontext gerissen zitierst und vorsätzlich mißinterpretierst.
Quelltextoffenheit sorgt tatsächlich nicht dafür, daß jeder nun Kernel-Sourcen verstehen würde. Aber Quelltextverschlossenheit verhindert dies zu 100%. Das ist der Unterschied zwischen einer logischen Und-Verknüpfung und einer Oder-Verknüpfung. Oft ein zu großes mathematisches Problem. @Icke: besser zitiere ich dich nicht mehr, dann kann ich auch nichts falsch machen, gell.
Icke ®. schrieb: > Trotzdem ist es symptomatisch, daß mit tödlicher > Sicherheit in fast jedem Thread mit Fragen zu Windows alsbald ein > Tux-Fanboy auftaucht, der zur Problemlösung null beizutragen hat aber > sich verpflichtet fühlt, Linux wie sauer Bier anzupreisen. Ja, diese Leute sind wirklich ärgerlich -- und sie leisten Linux einen Bärendienst. > Man stelle > sich vor, in Linux-Foren würden regelmäßig Windows-User auftauchen und > den Spieß umdrehen... In diesem Thread hier ist es ja genau andersrum gewesen: der TO hat eine Frage zu Linux gestellt, und dann sind die Windows-Fänbois gekommen und haben ihn gekapert.
Rolf M. schrieb: > Doch, ist sie. Sie ist vielleicht kein Garant für Sicherheit, aber sie > ist in meinen Augen Voraussetzung dafür. Also notwendig, aber nicht > hinreichend. Sehe ich genauso. Und damit sind wir nicht alleine, Bruce Schneier als einer der größten Kryptographie-Gurus tönt hier ins selbe Horn. Open Source ist wenn immer möglich Closed Source vorzuziehen.
Icke ®. schrieb: > Theoretisch stimmt das. Aber realistisch betrachtet existieren nur sehr > wenige Leute, die das nötige Wissen besitzen. Aufgrund der schieren > Größe des Quelltextes aktueller Software, der vom Linux-Kernel hat bspw. > schon über 15 Millionen Zeilen, ist es einem einzelnen Programmierer > außerdem gar nicht möglich, mal eben schnell einen Audit durchzuführen. > Das braucht erheblich viel Zeit und ein gut zusammenarbeitendes > Experten-Team und daher werden Audits i.d.R. nicht pauschal, sondern nur > auf besonderen Anlaß gestartet. Nicht ohne Grund blieben die eklatanten > Sicherheitslecks in SSL und Bash sehr lange Zeit unentdeckt. Die > Quelloffenheit als solche ist ergo überhaupt kein Argument für > Sicherheit. Da die Sicherheitslecks in SSL und Bash aber ausgerechnet bei genau solchen anlaßlosen Sicherheitsaudits entdeckt worden sind, zählt das Argument der Quelloffenheit sehr wohl. Wer weiß, wieviele solche und ähnliche Fehler in ClosedSource-Software enthalten sind und nicht von Auditoren, sondern von deren Gegenspielern entdeckt werden.
Icke ®. schrieb: > Es nützt nunmal nichts, wenn die Quellen zwar offen liegen, deren > Überprüfung jedoch daran scheitert, daß nur wenige Leute dazu überhaupt > in der Lage sind und obendrein ein immenser manueller und zeitlicher > Aufwand nötig ist. Icke ®. schrieb: > Wenn schon hochprofessionelle, bezahlte Codespezialisten versagen, wer > soll es dann packen? Deine Argumentation kann man gegen jede Form der Software einsetzen. Offensichtlich sind auch closed source und hochbezahlte Codespezialisten nicht in der Lage eine sichere Software herzustellen, wie MS täglich beweist. Das Geheimdienste noch dazu alle Möglichkeiten nutzen um sich Hintertüren einzubauen macht die Situation auch nicht besser. Fakt ist dass solche Hintertüren wie Heartbleed mit hoher Wahrscheinlichkeit auch in Windows und OSx enthalten sind. Dies wird aber nie an die Öffentlichkeit gelangen, weil halt keiner den Code kennt. Als Endanwender kann man eigentlich nur dem Faktischen "glauben". Und da ist ein Linux oder OSx in Grundkonfiguration halt besser als ein Windows in Grundkonfiguration.
Icke ®. schrieb: > Es nützt nunmal nichts, wenn die Quellen zwar offen liegen,.. Du hast im Grunde Recht. Eigentlich hat niemand eine wirkliche Sicherheit vor Bösartigkeiten in der Software, egal ob quelloffen oder nicht und egal welches konkrete Betriebssystem und welche konkreten Anwendungen darauf. Die viel praktischere Frage ist dabei eigentlich: Was nun tun? - manche neigen zum Exotensystem, in der Hoffnung, daß genau dieses nicht in der Ziellinie der vermuteten Widersacher liegt - andere glauben, per Abwehrmaßnahmen (Firewall, Virenscanner, Emailstripper etc.) oder sonstigen Ausgeklügeltheiten (TOR) auf der sicheren Seite zu sein. Da sind die Geschmäcker eben verschieden und jede Sorte von Maßnahmen trägt wohl auch ein Körnchen zur eigenen Sicherheit bei. Aber 100% gibt's nie. Nicht mal die Gewißheit darüber, was andere von einem wollen, ob es nun fiese Schädiger sind oder Ausspionierer oder Mißbraucher. Was man aber tun kann, ist die eigene Sicherheits-Struktur. Schon das simple Beispiel von den 2 völlig getrennten PC's (einer zum Daddeln, der andere zum Arbeiten) zeigt, daß man durch simple Abschottung dessen, was einem eher wichtig ist, etwas durchaus Wirkunsvolles und dabei selbst Überschaubares tun kann. Genau darum geht es ja im Grunde - um das, was man selber noch überschauen kann. Mir ist dabei durchaus klar, daß genau dieses von diversen Softwareherstellern am wenigsten gemocht wird und selbige deshalb bemüht sind, ihre Programme so zu gestalten, daß eine Internetverbindung vonnöten ist zum Benutzen. Ich hatte neulich sowas sogar bei dem aktuellen Softmaker-Freeoffice. Ne Dreistigkeit in meinen Augen. In solche Fällen muß man dann eben abwägen, was für Software man sich zulegt - leider. W.S.
Die Meldung ist zwar nicht mehr taufrisch (der Artikel ist vom 17.11.2016), aber ich glaube es passt ganz gut in diesen Thread: Heise Online: "Webseite aufgerufen, Linux gehackt" http://www.heise.de/newsticker/meldung/Webseite-aufgerufen-Linux-gehackt-3489774.html
Michael H. schrieb: > Die Meldung ist zwar nicht mehr taufrisch (der Artikel ist vom > 17.11.2016), aber ich glaube es passt ganz gut in diesen Thread: > Heise Online: "Webseite aufgerufen, Linux gehackt" > http://www.heise.de/newsticker/meldung/Webseite-au... Ja, Ereignisse diesen Kalibers muss man rot im Kalender anstreichen und den Kalender dann gut einlagern damit man so ein seltenes Ereignis auch in 10 Jahren noch pünktlich an dessen Jahrestag feiern kann. Die Windows-Leute hingegen feiern mittlerweile fast jeden Tag den Jahrestag der Drive-by-Infektion, die müssen sich das nicht mehr aufschreiben, ist eh schon die rote Farbe ausgegangen.
Michael H. schrieb: > Die Meldung ist zwar nicht mehr taufrisch (der Artikel ist vom > 17.11.2016), Macht ja nix. Im Vergleich zu dem gut 5 Monate alten Posting, auf das du hier geantwortet hast, ist sie ja noch richtig neu.
War eigentlich hauptsächlich dazu gedacht auch hier noch Leute, die möglicherweise empfindlich für diese Schwachstelle sind, darauf hinzuweisen. Und damit habe ich glaube ich schon mehr Nützliches zu diesem Thread beigetragen als die meisten anderen. ;-)
> Ja, Ereignisse diesen Kalibers muss man rot im Kalender anstreichen und > den Kalender dann gut einlagern damit man so ein seltenes Ereignis auch > in 10 Jahren noch pünktlich an dessen Jahrestag feiern kann. Interessant auch der "Finder" des Problems: "Chris Evans, Founder of Google Chrome Security Team" findet daß Chrome einen Anschlag auf Linux ermöglichen könnte, sagt aber gleichzeitig wie trickreich sich Linux dagegen wehrt. Eigentlich würde man erwartet, daß das "Chrome Security Team" seine Hausaufgaben macht. Chrome ist doch Google oder vielleicht doch MS? Who knows.
wobei ich fast der Meinung bin, dass die meisten Linuxanwender nicht googles Chrome als favorisierten webbrowser ansehen. die meisten werden mit Firefox unterwegs sein, und da interessiert diese (eher theoretische) Lücke nicht. Kann man eigentlich irgendwo sehen, wie die Verteilung/Verwendung der einzelnen Browser oder Distibutionen (oder beides zusammen) ist!?
also die Entscheidung auf GNU/Linux umzustellen ist sicher gold richtig. Ich habe bei all meinen Verwandten bei denen ich Win7 installiert hatte oder die Windows benutzten auf Debian 8 umgestellt nachdem alle ihre PCs immer langsamer und unbenutzbar wurden. Am Besten ist es unter win7 keinen Viren Scanner zu installieren weil alle die frei sind den PC stark verlangsamen und bei mir auch nie einen Virus gefunden haben. Zusätzlich muss unter Win oft defragmentiert werden. Möglicherweise sind es auch Programme die installiert wurden, jedenfalls überall das gleiche Problem, der PC wurde unter Win7 unbrauchbar und das Problem ist mit Linux gelöst und alle sind sehr zufrieden damit. Debian ist viel sicherer als Windows: 1) Packetverwaltung es müssen keine Programme aus unbekannten Quellen heruntergeladen. 2) superuser, user und sudo, alles was nicht unter superuser läuft kann das System nicht ändern. 3) es gibt kaum Viren und es wird auch nicht so leicht sein Viren für Linux zu entwickeln. 4) laufende Sicherheitsupdates die einem aber nicht aufgezwungen werden. Windows 10 kann dir jederzeit eine komplett andere Software unterschieben ohne das du etwas dagegen machen kannst. 5) bei Windows 10 bist du mal 1 Tag lang beschäftigt alle Spionagesoftware zu deaktivieren. 6) keine Weitergabe deiner Daten an die NSA so wie bei Windows Ein weiterer Vorteil ist das es schon sehr viele Anwendungsprogramme gibt die nichts kosten, fast jeder private Windows Benutzer verwendet Raubkopien und macht sich dadurch strafbar. Wer glaubt das Softwareentwickler auch etwas verdienen sollen darf auch sehr gerne die Projekte finanziell unterstützen es ist nicht verboten.
sorry, aber darum geht es doch schon garnicht mehr. Hast Du Dir mal die letzten fünf oder sechs postings durchgelesen!?
Ist der Browserexploit eine Variation von dem hier: http://scarybeastsecurity.blogspot.ch/2016/11/0day-exploit-compromising-linux-desktop.html In dem fall wurde das in Debian und Ubuntu doch schon längst gefixt, oder?
Jeffrey L. schrieb: > Kann man eigentlich irgendwo sehen, wie die Verteilung/Verwendung der > einzelnen Browser oder Distibutionen (oder beides zusammen) ist!? http://www.w3schools.com/browsers/
Jeffrey L. schrieb: > wobei ich fast der Meinung bin, dass die meisten Linuxanwender nicht > googles Chrome als favorisierten webbrowser ansehen. Linux oder nicht - Wenn der Rechner zur eher langsamen Truppe gehört, etwa den Bay Trail Atoms, dann ist Chrome auffällig schneller und flüssiger als jede Alternative.
A. K. schrieb: > Wenn der Rechner zur eher langsamen Truppe gehört, > etwa den Bay Trail Atoms, dann ist Chrome auffällig schneller und > flüssiger als jede Alternative. Absolut, da hast Du recht. Aber ich glaube eben dass sich Linuxanwender gezielt für oder gegen bestimmte Programme entscheiden. Jemand mit "erhöhtem" technischem Hintergrund, der sich auch dafür interessiert, was der Hersteller des Browsers mit dessen Metadaten anstellt, denk sicher anders als jemand, der einen Komplett-PC kauf und Werbebannern glaubt... ohne jetzt gemein klingen zu wollen - ich schätze bei einem guten drittel der Chromeuser heißt die Verknüpfung zur chrome.exe einfach nur "Internet"...
Wir sind ja in der Mehrzahl nur Anwender und keine Spezialisten. Bei einer Beurteilung der Sicherheitsvorteile von Linux reicht unsere Sicht kaum über den eigenen Tellerrand hinaus. Betrachten wir doch mal die Großen der Branche. Benutzen Großkonzerne wie Telekom oder ähnliche zumindest in den Serverfarmen mehr Win- als Lin-Server? Ich weiß es nicht. Aber das wäre doch mal eine fundierte Aussage zur Sicherheit.
wb schrieb: > Aber das wäre doch mal eine fundierte Aussage zur Sicherheit. Sicherheit ist nur ein Kriterium von vielen, und ein sehr subjektives dazu. Lizenz- und Supportkosten spielen ebenso eine Rolle wie Vorgaben der einzusetzenden Anwendungen - die ja oft nicht aus dem eigenen Haus kommen.
Ein Verwandter betreibt einen Server für seine Firma (bei einen Provider natürlich) und drauf läuft Windows. Ich bekomme jetzt von seinen Scanner, Drucker, Fax und von der halben Verwandtschaft Spam Mails, also sein Server ist ganz sicher gehackt worden. Ich habe selbst einen Debian Rechner mittels DynDNS an meinen Telekom Router gehängt und kann mitverfolgen wie da probiert wird an einen SSH Port einzubrechen. Alle möglichen Usernamen(vorallem root) und Passwörter werden ausprobiert. Also SSH Zugang nur mit public Key erlauben. Auch am Apache Log ist zu erkennen das immer wieder probiert wird einzubrechen. Aber bis jetzt hat es noch keiner geschafft durchzukommen oder ich habe nichts davon gemerkt, ich gehe aber davon aus wenn nur ein SSH und HTTP Port offen sind das es dann noch keiner geschafft hat.
SuperPC schrieb: > Ich habe selbst einen Debian Rechner mittels DynDNS an meinen Telekom > Router gehängt und kann mitverfolgen wie da probiert wird an einen SSH > Port einzubrechen. Alle möglichen Usernamen(vorallem root) und > Passwörter werden ausprobiert. In der Tat, falls jemand eine Liste will (braucht ne weile zum laden): https://preview.danielabrecht.ch/loginfails/
Daniel A. schrieb: > In der Tat, falls jemand eine Liste will (braucht ne weile zum laden): > https://preview.danielabrecht.ch/loginfails/ OjeOje. Verständlich dass da unter den Passwörtern die klassiker wie "123456" oder "qwerty" dabei sind, aber da scheinen auch volle klarnamen mit Vor- und Zunamen (MeiyouMima) und eher wahllose Zahlenkombinationen dabei zu sein. Ich frage mich wie solche Passwörter auf Schlüssellisten kommen, die werden doch nicht einfach so erfunden!? "2164823977" aber nicht 2164823976 oder 2164823978...
SuperPC schrieb: > Ich habe selbst einen Debian Rechner mittels DynDNS an meinen Telekom > Router gehängt und kann mitverfolgen wie da probiert wird an einen SSH > Port einzubrechen. Es wird alles durchprobiert, was auch nur irgendwie Erfolg versprechen könnte. SSH-Passwörter, SSH/SSL-Löcher, FTP-Passwörter, diverse Löcher in Webservern, alles was Wordpress und Joomla bereit halten, DNS Bugs, IP-Scans auf alle Ports die nur irgendwie interessant sein könnten, uvam. Das meiste davon siehst du erst, wenn du Services offen hast und eine bessere Firewall dabei mitlauscht. Wobei die Bugs, auf die sie dabei hoffen, meist schon etwas betagt sind - die aus 2015 sind grad brandaktuell.
:
Bearbeitet durch User
Was ist eine bessere Firewall auf Debian ? UFW ? Wie kann man feststellen wo und wie und ob eingebrochen wurde oder versucht wurde einzubrechen ausser die logs zu durchforsten? Habe nur zwei services laufen ssh und apache, die svn repo läuft über ssh. Am Router werden nur die ssh und http Ports an den Rechner(Telekom) weitergeleitet (bei eingehenden Verbindungen).
Bitte 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.