Anwendungen
Portal
Forum
Wiki
Ikhaya
Planet
Mehr
Private Nachrichten
Abonnements
Abmelden

Artikel "Sicherheitskonzepte"

Folgenden Satz habe ich als letztes eingefügt: Jedesmal nehme ich mir vor, möglichst kurz zu antworten, um die Diskussion zu vereinfachen. Es ist mir wieder nicht gelungen, ich bitte um Verzeihung. ;-)

user unknown schrieb:

Aber wären nur die besser geschützt, die sich besser auskennen, oder profitieren die weniger informierten mit? Eine Grippe breitet sich langsamer aus, wenn große Teile der Bevölkerung geimpft sind, und bei einer gewissen Impfdichte kommt sie zum Stillstand[...]

Genau so sehe ich das - wenn das Verhältnis günstig ist, wirkt es der Gefahr entgegen. Das Verbreitungsargument ist davon unabhängig. Aber die letzliche Gefärdung resultiert natürlich aus der "Summe" der Faktoren.

Aber Du sagst es kommt noch gar nicht zum Zuge, weil es die Viren gar nicht gibt

Richtig.

und es gäbe die Viren auch gar nicht wenn es nur Hallodries unter Linux gäbe, weil einfach das Ziel sich nicht lohnt.

Richtig.

10% Hallodries unter Windows sind immer noch mehr als alle Linuxuser zusammen.

Richtig. Von daher vermute ich, dass wir noch längere Zeit sicher sein werden.

Gerade mit Cross-Plattform-Software wie Firefox, OpenOffice, VLC könnte sich doch ein Fehler, der sich unter Windwos ausnutzen läßt, auch unter Linux ausnutzen - wenn auch anders. Wieso sollte das nicht mal jemand ausprobieren?

Unbedingt! Vielleicht probieren es auch welche aus. Da bin ich mir auch relativ sicher. Das ist auch gar nicht schlimm, wenn es aus Interesse geschieht. Ok, du meinst wahrscheinlich, dass diejenigen, die echte Angriffe für Windows starten, dies tun würden. Das kann ich nicht von der Hand weisen. Das bei den "Killerapps" - Du hast gerade eine Menge erwähnt - natürlich der Repository-Effekt in Spiel kommt, ist klar: Diese Programme werden - aufgrund ihrer starken Beliebtheit - im Distributions-Repository angeboten. Das ist ein echter Vorteil gegenüber der Windowslage.

Die Leute sind ja nicht alle gleich gepolt - wenn sich 100 sagen, dass sie damit keine Zeit verschwenden wird einer vielleicht sagen, er probiert es mal.

Gut möglich. Solange aber solche Versuche nicht aufgedeckt werden, sind sie so selten, dass man nicht von einer Epidemie und Bedrohung sprechen kann. Es könnte sie ja auch gar nicht geben. Wir können uns vielleicht darauf einigen: Es gibt eine gewisse Grauzone. Vielleicht werden bereits Exploits unter Linux von Virenschreibern getestet. Es ist aber dennoch derzeit keine echte Bedrohung. Wenn in nächster Zeit eine nennenswerte Zahl von Linux-Anwendern von einem einzelnen Angriff heimgesucht wird, dann haben wir ein Problem - ein "Programmierer" hat es richtig gut gemacht - und ich ein Argument weniger.
Zusammenfassend: Exploit-Angriffe sind unter Linux genauso möglich wie unter Windows. Dennoch gibt es derzeit keine Bedrohung. Mögliche Gründe (unvollständig?):

  • Bei Standardsoftware: Distributions-Repository. Lücken werden schneller und zuverlässiger auf den Nutzersystemen geschlossen, da der Vorgang zentral, einheitlich und automatisiert ist.

  • Heterogenität. konkrete Angriffsimplementierungen sind nicht universell einsetzbar

  • Verbreitung. Nutzergruppe ist wirtschaftlich uninteressant.

Die Gesamtgefärdnung ergibt sich aus der "Summe" dieser Gründe. Über die Wichtigkeit/generelle Gültigkeit sind wir wohl nicht ganz einig. Was die Wichtigkeit anbelangt wäre das kein Problem. Der Artikel müßte ja keine Wertung vornehmen.

Die vielen Softwarekram-Anbieter könnten sogar auf Open-Source-Modelle umsteigen. Das würde dennoch nichts an der schier endlosen Zahl ändern, weshalb weiterhin Binärpakete direkt von diversen Orten heruntergeladen werden würden. Das kann man nicht über ein vertrauenswürdiges Repository verwalten.

Aha - scheint ein weiterer Widerspruch zw. uns zu sein. Das Repository ist m.E. nicht vertrauenswürdig, weil es eine halbwegs große Zentrale ist, sondern weil klar ist wer dahinter steckt, und derjenige einen Ruf zu verteidigen hat.

Und weil er einen Ruf zu verteidigen hat, wird er nicht jedwede Kramssoftware aufnehmen. Selbst wenn es OpenSource ist. Das ist ja auch heute schon so.

Wenn ich Closed-Source-Software von Fall zu Fall von Adobe, Siemens, Symantec oder wem herunterlade ist das ähnlich vertrauenswürdig, was deren Sorge um Malwarefreiheit angeht - Grenzfälle wie das Sonyrootkit mal außen vor.

Natürlich kann man bei den "Großen" davon ausgehen, dass ihre Repositories vertrauenswürdig sind. Ist doch klar, dass es in dem Mircosoft-Repository kein MalwareKrimsKrams geben wird. Aber das ist doch heute in der Windowswelt genauso?
Ich spreche von dem restlichen Durcheinander. Die unzählig kleinen Lösungen, die es in kein vertrauenswürdiges Repository schaffen. Die werden eigene Pakete direkt anbieten müssen. Und der Nutzer muss dann entscheiden/erkennen, ob er ein Programm tatsächlich von der Entwicklerseite herunterläd oder von einer gutgemachten Seite, die dann das Programm+Malware enthält.

Wie gesagt - Quellen gibt es im anderen Sinne auch für binaries, und man kann als Programmierer (die Quelle des Programms) auch Binärcode (zusätzlich zum Quellcode) anbieten - und das wird auch gemacht.

Genau davon spreche ich: Direkter Download - ohne Nutzung eines (oder einiger) zentralen Repositories. Das Paket kann vom Programmierer direkt angeboten werden. Genauso aber auch von zig Malwareschleudern. Der Anwender muss nun erkennen, was genau der gute Download ist. Ist das nicht unter Windows ein Teil des Problems?

Außer freie Software wäre überhaupt der Grund, das sich der Useranteil zugunsten von Linux verschiebt. Da ich das als Hauptvorteil von Linux sehe kann ich mir keinen anderen guten Grund für eine Verschiebung denken.

Das wäre in der Tat toll!

Malwareschreiber sind ja keine allwissenden Superhirne die alles richtig und immer das - für ihre Belange - beste machen. Die haben unterschiedliches Wissen, Fähigkeiten, Ziele, Annahmen, ... . Der eine verbirgt seinen Kram gar nicht, der nächste schlecht, der dritte gut und der vierte sehr gut. Das gibt es alles parallel, und daher sollte man nicht ein Szenario herauspicken, und sich dagegen wappnen.

Deine Argumentation beruht doch zunächst auf der Tatsache, dass ein Angriff ohne der Existenz einer Rootzone direkt perfekt zu verschleiern wäre. Damit wäre er erfolgreicher als ohne. Der Umkehrschluss ist, dass die Existenz der Rootzone also zu weniger unbemerkten Angriffen führt, da er auf einigen,wenigen Systemen entdeckt wird.

Primär hätte das erstmal nur die Auswirkung, dass der Angriff eben nur etwas uneffektiver wäre. Es gibt allerdings einen sekundären, nachgelagerten Effekt, der mir erst durch die Diskussion aufgegangen ist: Vielen Dank! ;-) Ich kann mir sogar vorstellen, das dies ein Grund ist, weshalb ein erfolgreicher Angriff sogar zwingend Root-Rechte benötigt. War Dir dieser Umstand bewußt? Hättest Du mich nicht früher drauf bringen können? ;-) Sekundär: Je schneller der Angriff nun aber entdeckt wird (egal, ob der Entdecker schaden genommen hat oder nicht), desto schneller wird er gefixt. Falls es sich nun noch um ein Repository-Programm handelt, könnten viele weitere Anwender geschützt werden, da auch der Bugfix effektiv verbreitet wird.
Ein Vorteil der Rootzone um die Ecke. ;-)

Merken was? Du scheinst ja einige, sehr speziellen Angriff im Auge zu haben, die der User nicht bemerkt. Wieso merken denn User unter Windows, dass ihr Rechner befallen ist?

Angriffe tragen immer das Risiko, dass sie auf bestimmten Systemen zu seltsamen Nebeneffekten führen. Im Endeffekt zählt aber nur, dass der Code auf möglichst vielen Systemen unauffällig läuft. Je nach Art des Angriffs reicht es auch, wenn er nur eine Zeit lang unauffällig ist. "Virenschreiber" sind auch nur Programmierer. Es gibt gute, mittelmäßige und schlechte Angriffe.

Wieso gibt es da Prozesse die Rootrechte zu erlangen trachten? Viele versuchen es nicht - mag sein - aber wieso soll man denen, die es versuchen, die Sache leicht machen?

(Nachtrag: Der sekundäre Effekt wurde mir erst später klar..., nachfolgendes ist aber trotzdem gültig. Es ist sozusagen der automatisierte Entdecker: AV-Lösung) Unter Windows gibt es etablierte AV-Software, die im Rootkontext läuft. Ich habe gehört, dass zunächst unbekannte Angriffe versuchen, die AV-Lösung auszuschalten bzw. zu manipulieren, um auch nach Bereitstellung von Signaturupdates weiterexistieren zu können. Das dürfte in der Regel für BotNets interessant sein. Auch Angriffe nach Art des "BKA-Viruses" brauchen das, um sich einigermaßen gut festsetzen zu können. Ich halte fest: Rootrechte sind auch interessant, wenn AV-Lösungen eingesetzt werden bzw. der Angriff gerade eben nicht unentdeckt bleiben soll (wenn er auch nicht als solcher erkannt werden will).

AV-Lösungen führen aber auch zu einem Dilema: Sie verhindern, dass immer die gleiche Generation von Angriffen verwendet wird, da sie diese erkennen. Damit fördern sie aber indirekt auch die Entstehung neuer Varianten. Aus einer statischen Situation wird halt ein Katz- und Maus Spiel. An dem übrigens gut verdient wird... (gewagte Theorie?)

Somit ziehe ich meine Aussage "Root-kontext hat keinen Sicherheitsgewinn" zurück. Begrenzt auf ein einzelnes System hat das meiner Meinung nach zwar nach wie vor Gültigkeit, nicht aber im Zusammenhang mit der Gemeinschaft. Einen Hauptgrund für die geringere Bedrohung unter Linux mag ich daraus aber noch nicht ableiten.

Haus mit Haustür und Safe

Ein Vergleich, der etwas hinkt. Du beschreibst hier unterschiedlich stark gesichtere Zonen. Ok, auf einem Computer gibt es die Userzone und die Rootzone. Die Userzone ist geschützt, da es ja immerhin einiges an Aufwand kostet, nur diese zu erreichen (z.B. Exploit). Das war die Haustüre, oder? Ist es aber nicht so, dass alle interessanten Daten auschließlich in dieser Zone liegen? Der Safe (Rootzone) ist sozusagen immer leer. In Ausnahmefällen mag das nicht zutreffen.

Ordentlich mit sudo umgehen verhindert viele denkbare Angriffe nicht, aber gegen manche Angriffe ist es hilfreich. Wichtiger ist eine verschlossene Haustüre, also hier: Software aus vertrauenswürdigen Quellen beziehen, Misstrauen bei Mailanhängen und bei verlockenden Angeboten von Fremden.

Mein Credo! (btw: wenn wir schon beim Thema "ordentlich" sind: Du meinst /usr/bin/sudo, oder? ;-) )

Wenn der Artikel auch auf gezielte, exakt geplante Angriffe auf individuelle Systeme eingehen soll,

Was hat das damit zu tun?

Gegen gezielte Angriffe kann man sich kaum schützen, selbst wenn man gesundes Verständnis im Bereich Sicherheit hat. Hier ist das Ziel ja nicht, ein statistisches Mindestmaß zu erfüllen, sondern auf Teufel komm raus auf ein bestimmtes System zu kommen. Da muss also ein bestimmter Antrieb vorhanden sein. Spionage zum Beispiel. Einhaltung von "Sicherheitsregeln" mag hier eine zeitlang schützen, wird den Angreifer aber nicht aufhalten. Zugegeben: Unsere Zielgruppe ist davon eher nicht betroffen. Im Umkehrschluss ist aber unsere Zielguppe dann nur der Massenbedrohung ausgesetzt. Einzelfälle bestätigen die Regel. Vielleicht diesen Aspekt in einem Nebensatz anreißen.

Wenn Du von mir Software beziehst dann kann das ebenso vertrauenswürdig sein, wie wenn Du sie von Canonical beziehst. ;)

Gegen Dich kann Canonical einpacken. Du bist ein geschätztes Urgestein hier auf ubuntuusers und genießt mittlerweile mein volles Vertrauen!

Deine Gliederung finde ich eigentlich ganz gut. Ich glaube nur, dass es sich nicht gut in einen Artikel formulieren läßt. Aber als "Verhaltenskodex" finde ich es perfekt. Oder man nimmt die grobe Gliederung für einen Artikel, und schließt diesen dann mit der ausführlichen Beispielsammlung ab?

Auch von mir eine Entschuldigung für die verspätete Reaktion, aber bei den Postlängen - gegen die ich in dem Fall gar nichts einzuwenden habe - kann man nicht mal eben so antworten.

user unknown schrieb:

Gliederungsvorschlage:

An sich ist das eine gute Gliederung - ohne jetzt im Detail darauf einzugehen-, die aber IMO mehr in die Richtung des Artikels Sicherheits 1x1 geht. Das sind ja alles Verhaltensregeln für den Nutzer und dass der Nutzer in die Sicherheit seines Systems mit einzubinden ist, sehe ich auch als wesentlichen Punkt eines Sicherheitskonzeptes an. Dass ihm hier insofern konkrete Verhaltensmaßnahmen an die Hand gelegt werden ist immer gut.

Ob man das jetzt so ausführlich in diesem Artikel "Sicherheitskonzepte" darstellen muss, weiß ich noch nicht so genau. Ich denke, da könnte man dann auch nach "Sicherheits 1x1" verweisen und gegebenenfalls dort noch das ein oder andere nachlegen.

Ansonsten will ich vorläufig mich nicht in Einzelheiten verrennen, um es übersichtlich zu halten. Ich versuche anhand einer weiteren Gliederung erst noch mal deutlich zu machen, wohin für mich die Reise gehen sollte. Bisher waren meine "Gliederungen" dazu wohl zu kurz:

Wenn es um ein Sicherheitskonzept geht bzw. Sicherheitskonzepte, dann stelle ich mir das in etwa so vor:

  1. Bestandsaufnahme

  • Analyse der Bedrohungslage

    • Welche Bedrohung gibt es aktuell?

    • Welche Bedrohungen sind für das eingesetzte System denkbar?

  • Analyse des Systems

    • Welche Sicherheits-relevanten Mechanismen bietet das System (Stärken)?

      • Rechtetrennung

      • sudo

      • Zentrale Updates über Paketverwaltung

      • Quelloffene Software

      • ...

    • Welche Angriffsflächen bietet das System?

      • Problem der Sicherung der Daten im aktiven Benutzerkonto --> Widerstreit von Sicherheit und Komfort.

      • ...

  • Analyse des Schutzgegenstandes?

    • Auseinandersetzung mit dem eigenen Sicherheitsbedürfnis.

    • Analyse des Datenbestandes

      • Welche Art von Daten hat man?

      • Ist man nur für eigene Daten verantwortlich oder auch für Daten dritter?

  • Analyse der eigenen Nutzungsgewohnheiten (EDIT)

  • Analyse des eigenen Sicherheits-relevanten Wissens

2. Ein auf die Antworten von 1. abgestimmter Maßnahmen-Katalog

  • Allgemeine Verhaltensgrundsätze

  • Gegebenenfalls darüber hinausgehende an den Antworten von 1. orientierte weitere Maßnahmen

    • Erweiterte Konfiguration von sudo

    • Gezielter Einsatz von Tools wie Apparmor.

3. Regelmäßige Überprüfung von 1. und 2 durch den Nutzer.

Gruß, Martin

EDIT:

Noch einen Gliederungspunkt nachträglich eingefügt.

Newubunti schrieb:

  • Analyse der Bedrohungslage

Neben der "indirekten" Bedrohung - von der wir bisher immer gesprochen haben und auch der aktuelle Artikel handelt - gibt es ja auch Bedrohungen, die mit physikalischem Zugang verbunden sind. Über die Namenswahl bin ich nicht glücklich, mir fällt grad nichts besseres ein. Jedenfalls bin ich der Meinung, dass man weiterhin nur beim Thema "indirekt" bleiben sollte, da es eh schon kompliziert genug ist. Lieber einen zusätzlichen Artikel, der sich unabhängig entwickeln kann. Hier sollte man nur einen Hinweis geben, dass diese Bedrohungsart bewusst ausgeklammert wurde.

  • Welche Bedrohung gibt es aktuell?

Bedrohungsarten (z.B. Exploits, "Screensaver") oder Bedrohnungsziele (Rechenleistung, Bankingdaten, ...)?

  • Welche Bedrohungen sind für das eingesetzte System denkbar?

Wieso nicht alle?

  • Welche Angriffsflächen bietet das System?

Abgrenzung zu "welche Bedrohungen gibt es aktuell"?

  • Problem der Sicherung der Daten im aktiven Benutzerkonto --> Widerstreit von Sicherheit und Komfort.

Verstehe ich nicht ganz: Meinst Du unterschiedliche Benutzer für z.B. "Internet" und "Office"? Für ein Konzept müßte man das aber noch sehr stark ausarbeiten. So plaktativ würde es zu Snake Oil führen (unzureichende Abschottung durch Rechte, Gefahr der Übertragung bei Kontextwechsel).

  • ...

  • Interaktion mit der "Aussenwelt". Alle indirekten Formen leiten sich meiner Meinung davon ab.

  • Analyse des Schutzgegenstandes?

    • Auseinandersetzung mit dem eigenen Sicherheitsbedürfnis.

    • Analyse des Datenbestandes

      • Welche Art von Daten hat man?

      • Ist man nur für eigene Daten verantwortlich oder auch für Daten dritter?

  • Angriffe haben es nicht nur auf Daten abgesehen, sondern auch auf Kapazität, z.B. Rechenleistung, Netztraffic

  • Analyse der eigenen Nutzungsgewohnheiten (EDIT)

Beispiel?

  • Analyse des eigenen Sicherheits-relevanten Wissens

Wie soll das gehen?

  • Erweiterte Konfiguration von sudo

Hat das wirklich etwas mit der Art von Sicherheit zu tun, um die es hier geht?

Hallo,

Erweiterte Konfiguration von sudo

Hat das wirklich etwas mit der Art von Sicherheit zu tun, um die es hier geht?

Nein, nicht direkt. Das gehört wenn in der Tat in den Artikel zu sudo (der, BTW, auch zu Überarbeitung ansteht :-) ) und dann wenn hier im Artikel verlinkt.

BTW: Wenn ihr eine Baustelle braucht, bitte _kurz_ hier den Wunsch hier posten - und nicht in einem der langen Postings verstecken. ;-) THX!

Gruß, noisefloor

DrScott schrieb:

Newubunti schrieb:

  • Analyse der Bedrohungslage

...

Stop!

Die Gliederung sollte nur dazu dienen aufzuzeigen, in welche Richtung ich mir den Inhalt eines Artikels vorstelle, der "Sicherheitskonzepte" oder "Sicherheitskonzept" heißt. Dass an der Gliederung selbst oder an einzelnen Punkten noch gefeilt werden muss, ist gar keine Frage.

Mir geht es erst mal nur darum, dass Ihr versteht, worum es mir im Groben geht und ob Ihr dass dann, als für den Artikel passend seht oder schon vom Ansatz her nicht.

Wie gesagt, dass wir alle mit dem jetzigen Artikel nicht einverstanden sind heißt ja nicht, dass wir uns alle das gleiche für einen verbesserten Artikel vorstellen.

Man könnte z.B. auch die Auffassung vertreten, dass nur dieser Teil Sinn macht:

  • Welche Sicherheits-relevanten Mechanismen bietet das System (Stärken)?

    • Rechtetrennung

    • sudo

    • Zentrale Updates über Paketverwaltung

    • Quelloffene Software

    • ...

  • Welche Angriffsflächen bietet das System?

    • Problem der Sicherung der Daten im aktiven Benutzerkonto --> Widerstreit von Sicherheit und Komfort.

    • ...

Oder eben nur die Gliederung von user unknown oder ganz etwas anderes.

Gruß, Martin

Newubunti schrieb:

Mir geht es erst mal nur darum, dass Ihr versteht, worum es mir im Groben geht und ob Ihr dass dann, als für den Artikel passend seht oder schon vom Ansatz her nicht.

Ich bin mit der Gliederung im Groben einverstanden. Daher habe ich in meinem letzten Posting auch schon gleich Fragen und Vorschläge angebracht. Die Fragen zeigen in etwa, weshalb "im Groben". Ich verstehe eben noch nicht alles.

DrScott schrieb:

Ich bin mit der Gliederung im Groben einverstanden. Daher habe ich in meinem letzten Posting auch schon gleich Fragen und Vorschläge angebracht.

Ah gut, ich wollte das nicht einfach so interpretieren.

DrScott schrieb:

Newubunti schrieb:

  • Analyse der Bedrohungslage

Neben der "indirekten" Bedrohung - von der wir bisher immer gesprochen haben und auch der aktuelle Artikel handelt - gibt es ja auch Bedrohungen, die mit physikalischem Zugang verbunden sind. Über die Namenswahl bin ich nicht glücklich, mir fällt grad nichts besseres ein. Jedenfalls bin ich der Meinung, dass man weiterhin nur beim Thema "indirekt" bleiben sollte, da es eh schon kompliziert genug ist. Lieber einen zusätzlichen Artikel, der sich unabhängig entwickeln kann. Hier sollte man nur einen Hinweis geben, dass diese Bedrohungsart bewusst ausgeklammert wurde.

Guter Hinweis, wobei ich es so sehen würde, dass man es hier schon aufführt. Falls das dann zu viel Stoff gibt, erwähnt man es nur an sich, packt es in einen eigenen Artikel und verlinkt dann von hier nach dort.

  • Welche Bedrohung gibt es aktuell?

Bedrohungsarten (z.B. Exploits, "Screensaver") oder Bedrohnungsziele (Rechenleistung, Bankingdaten, ...)?

Ich dachte da jetzt mal zunächst an Bedrohungsarten. Bedrohungsziele ist nach meiner jetzigen Gliederung dann eher unter "Schutzgegenstand" anzusiedeln - zumindest ergeben sich da Überschneidungen.

Ich hänge dabei im übrigen jetzt an keiner der von mir gewählten Begriffe. Geschmeidigere Begriffe sind da immer willkommen.

  • Welche Bedrohungen sind für das eingesetzte System denkbar?

Wieso nicht alle?

Ich denke das wird eine Frage des Artikel-Umfangs. Wichtiger ist IMO in erster Linie mal zu verdeutlichen, dass Bedrohungen nicht gleich Bedrohung ist. Und dass man hier so zwei bis drei positiv und negativ Beispiele aufführt. Grundsätzlich hätte ich auch nichts dagegen, hier alles aufzulisten. Dass wird aber erstens sehr umfangreich und bringt zweitens das Problem mit sich, dass es dann aktuell gehalten werden müsste.

  • Welche Angriffsflächen bietet das System?

Abgrenzung zu "welche Bedrohungen gibt es aktuell"?

Zumindest theoretisch sind das für mich erst mal schon zwei verschiedene Dinge - Überschneidungen im Einzelnen möchte ich dabei nicht von vornherein ausschließen.

Bedrohungen sind für mich Viren, Trojaner und Co., individulle Angriffe von außen etc..

Angriffsziele sind für mich Daten, Rechenleistung usw..

Angriffsflächen ist dann so etwas wie z.B. der Account des angemeldeten Benutzers, der sich grundsätzlich nicht so ohne weiteres schützen lässt, oder der Einsatz unsicherer oder veralteter Software oder auch Sicherheitslücken in Software im allgemeinen.

  • Problem der Sicherung der Daten im aktiven Benutzerkonto --> Widerstreit von Sicherheit und Komfort.

Verstehe ich nicht ganz: Meinst Du unterschiedliche Benutzer für z.B. "Internet" und "Office"? Für ein Konzept müßte man das aber noch sehr stark ausarbeiten. So plaktativ würde es zu Snake Oil führen (unzureichende Abschottung durch Rechte, Gefahr der Übertragung bei Kontextwechsel).

Ich meine damit, dass es grundsätzlich ein Problem ist, die Daten des gerade aktiven Benutzers zu schützen. Dass Schadsoftware zumindest nur mit Benutzerrechten auf einem System aktiv wird, ist ja ein grundstäzlich realistisches Szenario. Damit hätte ein solches Programm auch leicht Durchgriff auf die dort liegenden Daten. Möchte man sich dagegen schützen, dann hieße das ja, dass dem Account oder den darunter laufenden Programmen nicht per se Zugriff auf alle Bereiche des Nutzer-Accounts gewährt wird, was nach meinem Verständnis grundsätzlich z.B. mit Apparmor möglich wäre.

Oder man hält Daten gar nicht permanet unter dem betreffenden Account verfügbar.

Beides kann aber dann wiederum weniger komfortabel für die Nutzung des Systems sein.

  • ...

  • Interaktion mit der "Aussenwelt". Alle indirekten Formen leiten sich meiner Meinung davon ab.

Könnte vieleicht das sein, was ich mit "Analyse der eigenen Nutzungsgewohnheiten" meine.

  • Analyse des Schutzgegenstandes?

    • Auseinandersetzung mit dem eigenen Sicherheitsbedürfnis.

    • Analyse des Datenbestandes

      • Welche Art von Daten hat man?

      • Ist man nur für eigene Daten verantwortlich oder auch für Daten dritter?

  • Angriffe haben es nicht nur auf Daten abgesehen, sondern auch auf Kapazität, z.B. Rechenleistung, Netztraffic

Ja, wichtiger Punkt.

  • Analyse der eigenen Nutzungsgewohnheiten (EDIT)

Beispiel?

Naja, es ist ja bezüglich der Betrachtung der Sicherungsmaßnahmen schon wichtig, wie der Computer benutzt wird:

  • Computer wird nur als erweiterte Schreibmaschine genutzt, praktisch keine Online-Aktivität, außer das Systemupdates eingespielt werden, oder vielleicht auch noch nicht ein mal das.

  • Computer wird sehr experimentell genutzt. Es wird gerne auch mal neue oder ungewöhnliche Software ausprobiert usw..

  • etc.

Es nutzen ja nicht alle den Computer genau gleich. Ein Sicherheitskonzept ist ja aber IMO nicht unwesentlich von eben diesen Nutzungsgewohnheiten abhängig. Sicherheit ist ja IMO kein absoluter Wert sondern relativ. Hier kann man dann auch noch auch auf das Aufwand-Nutzen-Verhältnis eingehen.

  • Analyse des eigenen Sicherheits-relevanten Wissens

Wie soll das gehen?

Ich gehe jetzt mal davon aus, dass ein erwachsener Mensch - zumindest vor sich selbst - dazu in der Lage ist zu beurteilen, ob er von so Dingen wie Paketfiltern, Rechtetrennung, Ports usw. eine grobe Ahnung hat, gar keine Ahnung hat oder sich gut damit auskennt und ob er willens und zeitlich in der Lage ist z.B. Security Newsletter zu verfolgen.

  • Erweiterte Konfiguration von sudo

Hat das wirklich etwas mit der Art von Sicherheit zu tun, um die es hier geht?

Wenn man sudo oben als Sicherheitsmerkmal von Ubuntu aufführt, dann hat das IMO schon etwas mit der Art Sicherheit zu tun, um die es hier geht. An eine ausführliche Darstellung habe ich dabe jetzt gar nicht zwangsläufig gedacht. Es ginge dann mehr nach dem Schema hier erwähnen - also 1-2 Sätze - mit Verlinkung nach sudo.

Newubunti schrieb:

lokaler Zugriff

Guter Hinweis, wobei ich es so sehen würde, dass man es hier schon aufführt. Falls das dann zu viel Stoff gibt, erwähnt man es nur an sich, packt es in einen eigenen Artikel und verlinkt dann von hier nach dort.

Also "lokaler Zugriff" mit als aktuelle Bedrohung auflisten, vielleicht auch etwas erläutern, aber im Folgenden nicht mehr darauf eingehen, statt dessen kurz auf anderen Artikel verweisen? Einverstanden.

Ich dachte da jetzt mal zunächst an Bedrohungsarten. Bedrohungsziele ist nach meiner jetzigen Gliederung dann eher unter "Schutzgegenstand" anzusiedeln - zumindest ergeben sich da Überschneidungen.

Ok, aber unter einer Bedrohungsart verstehst Du soetwas wie "Exploit", "Phishing"? Und unter Ziel soetwas wie "Daten", "Leistung"?

  • Welche Bedrohungen sind für das eingesetzte System denkbar?

Wieso nicht alle?

Ich denke das wird eine Frage des Artikel-Umfangs. Wichtiger ist IMO in erster Linie mal zu verdeutlichen, dass Bedrohungen nicht gleich Bedrohung ist. Und dass man hier so zwei bis drei positiv und negativ Beispiele aufführt. Grundsätzlich hätte ich auch nichts dagegen, hier alles aufzulisten. Dass wird aber erstens sehr umfangreich und bringt zweitens das Problem mit sich, dass es dann aktuell gehalten werden müsste.

Ich kapiers noch nicht: War wäre den ein Beispiel für eine undenkbare Bedrohung? Z.b. das Industriespionage auf meinem Heim-PC relativ unwahrscheinlich ist?

Ich meine damit, dass es grundsätzlich ein Problem ist, die Daten des gerade aktiven Benutzers zu schützen.

ok

Möchte man sich dagegen schützen, dann hieße das ja, dass dem Account oder den darunter laufenden Programmen nicht per se Zugriff auf alle Bereiche des Nutzer-Accounts gewährt wird, was nach meinem Verständnis grundsätzlich z.B. mit Apparmor möglich wäre.

Sehe ich auch so.

  • Analyse der eigenen Nutzungsgewohnheiten (EDIT)

  • Computer wird nur als erweiterte Schreibmaschine genutzt, praktisch keine Online-Aktivität, außer das Systemupdates eingespielt werden, oder vielleicht auch noch nicht ein mal das.

  • Computer wird sehr experimentell genutzt. Es wird gerne auch mal neue oder ungewöhnliche Software ausprobiert usw..

ok. verstanden.

  • Analyse des eigenen Sicherheits-relevanten Wissens

Wie soll das gehen?

Ich gehe jetzt mal davon aus, dass ein erwachsener Mensch - zumindest vor sich selbst - dazu in der Lage ist zu beurteilen, ob er von so Dingen wie Paketfiltern, Rechtetrennung, Ports usw. eine grobe Ahnung hat, gar keine Ahnung hat oder sich gut damit auskennt und ob er willens und zeitlich in der Lage ist z.B. Security Newsletter zu verfolgen.

Dazu muss er aber davon wissen. Ok, dieser Artikel soll da ja helfen ;-) Aber ich denke, es ist dennoch sehr schwer, sich selbst korrekt einzuschätzen. Allzuleicht begibt man sich mit einer Annahme auf den Holzweg - ich spreche da aus eigener Erfahrung. ;-) Klar ist, dass es besser ist, je mehr man sich auskennt und je länger man sich mit dem Thema beschäftigt. Ist es das, was Du in diesem Abschnitt vermitteln möchtest?

  • Erweiterte Konfiguration von sudo

Hat das wirklich etwas mit der Art von Sicherheit zu tun, um die es hier geht?

Wenn man sudo oben als Sicherheitsmerkmal von Ubuntu aufführt, dann hat das IMO schon etwas mit der Art Sicherheit zu tun, um die es hier geht. An eine ausführliche Darstellung habe ich dabe jetzt gar nicht zwangsläufig gedacht. Es ginge dann mehr nach dem Schema hier erwähnen - also 1-2 Sätze - mit Verlinkung nach sudo.

Die Rechtetrennung hat einen Einfluss. Klar ist aber auch, dass sie kein Allheilmittel ist. Der Abschnitt könnte z.B. erläutern, dass bei erfolgreichem Angriff auf die Benutzerzone das Benutzerpasswort relativ leicht ausspioniert werden kann. Dann kann sudo vom Angreifer selbst verwendet werden, um die Rootzone zu erreichen. Ich bin jedenfalls der Meinung, dass man die Rechtetrennung nicht überbewerten darf.

DrScott schrieb:

Also "lokaler Zugriff" mit als aktuelle Bedrohung auflisten, vielleicht auch etwas erläutern, aber im Folgenden nicht mehr darauf eingehen, statt dessen kurz auf anderen Artikel verweisen? Einverstanden.

Ja, so in dieser Art.

Ok, aber unter einer Bedrohungsart verstehst Du soetwas wie "Exploit", "Phishing"? Und unter Ziel soetwas wie "Daten", "Leistung"?

Ja.

Ich kapiers noch nicht: War wäre den ein Beispiel für eine undenkbare Bedrohung?

Vielleicht hängst Du Dich da ja gerade zu sehr an dem Begriff "denkbar" auf. "Denkbar" ist in diesem Sinne natürlich erst immer mal alles.

Grundsätzlich hatte ich jetzt erst mal vor meinem geistigen Auge, dass es wohl etwas mühselig ist, jede Bedrohung aufzulisten aufzulisten, zumal ja auch immer die Gefahr besteht, dass man eine Bedrohung vergisst.

"Denkbar" sollte in meiner Gliederung als insofern auf eine gewisse Grenzziehung hindeuten. Ich weiß, dass das praktisch eine schwierige Geschichte ist oder im Einzelfall sein kann. Darüber kann man dann gerne diskutieren, da bin ich guten Argumenten mal grundsätzlich zugeneigt.

Z.b. das Industriespionage auf meinem Heim-PC relativ unwahrscheinlich ist?

Ja, so in gewisser Weise in die Richtung. Ich würde mich aber z.B. auch soweit aus dem Fenster lehnen, dass ich z.B. den klassischen Virus - also das sich selbst von Rechner zu Rechner verbreitende Schadprogramm für Ubuntu für eine sehr geringe, wenn nicht fast unmögliche Variante ist.

Während ein Trojaner ein absolut realistische Bedrohung darstellt.

Du musst ja auch mal sehen, dass ich mich im Gliederungspunkt davor ja mit mehr oder weniger allen Bedrohungen grundsätzlich auseinandersetze. In einem Konzept geht es für mich dann schon auch darum, dass man wahrscheinliches von unwahrscheinlichem sondiert. Da kann man dann natürlich in der Bewertung auch mal falsch liegen.

Aber mein Ziel für den Artikel insgesamt ist in erster Linie auch dem Leser zu vermitteln, wie er das Thema strategisch angeht und was es bedeutet. Dass es mehr ist, als einfach nur Software X zu aktivieren und dass er in diesen Prozess eingebunden ist.

Und es soll - weil es sich um Ubuntu dreht - natürlich auch deutlich werden, was Ubuntu dem Nutzer zu seiner Unterstützung bezüglich seiner Sicherheitsbemühungen technisch bietet und eben auch wo es etwaige Schwächen gibt.

Es geht mir weniger darum, dass alles in voller Gänze aufgezählt wird.

Und mal umgekehrt gefragt, wie würdest Du das an dieser Stelle aufbauen wollen?

  • Analyse des eigenen Sicherheits-relevanten Wissens

Wie soll das gehen?

Ich gehe jetzt mal davon aus, dass ein erwachsener Mensch - zumindest vor sich selbst - dazu in der Lage ist zu beurteilen, ob er von so Dingen wie Paketfiltern, Rechtetrennung, Ports usw. eine grobe Ahnung hat, gar keine Ahnung hat oder sich gut damit auskennt und ob er willens und zeitlich in der Lage ist z.B. Security Newsletter zu verfolgen.

Dazu muss er aber davon wissen. Ok, dieser Artikel soll da ja helfen ;-) Aber ich denke, es ist dennoch sehr schwer, sich selbst korrekt einzuschätzen. Allzuleicht begibt man sich mit einer Annahme auf den Holzweg - ich spreche da aus eigener Erfahrung. ;-) Klar ist, dass es besser ist, je mehr man sich auskennt und je länger man sich mit dem Thema beschäftigt. Ist es das, was Du in diesem Abschnitt vermitteln möchtest?

Naja, IMO kommt es nicht auf die perfekte Selbsteinschätzung an.

Ich möchte hier den Leuten - wie auch mit dem Artikel insgesamt - den Zahn ziehen, bei denen eine große Angst und ein daraus resultierendes großes abstraktes Sicherheitsbedürfnis einem sehr überschaubaren Wissen gegenübersteht und die nach der Devise "viel hilft viel" mit einer Menge Dinge auf eine große Blackbox schießen.

Es geht nicht um Unfehlbarkeit oder Perfektionismus, es geht mir hier darum aufzuzeigen, dass die Sinnhaftigkeit einer Maßnahme - vielleicht nicht in jedem Fall aber in vielen Fällen - mit dem Wissen des Anwenders steht und fällt, der ja auf einem Heimsystem in die Rolle des Administrator gezwängt wird.

Eine grobe Devise wäre für mich an dieser Stelle auf eine über den Ubuntu-Standard hinausgehende Maßnahme zu verzichten, wenn sie nicht durch ein entsprechendes Wissen beherrscht werden kann. Beispiel "Firewall".

Es geht aber auch darum, dass man aufgrund der Tatsache, dass Linux einen eher "sicheren Ruf" hat, mal eben einen Server ans Internet hängt, weil ja Linux per se so sicher ist, ohne dass man Ahnung hat, was man da eigentlich tut.

Das ist ja zuweilen auch ein Nachteil von Linux. Einen Server hat man relativ leicht am laufen. Nur Laufen ist von beherrschen noch die ein oder andere Ecke weit entfernt.

Kurz: In diesem Abschnitt soll dem Leser vor Augen geführt werden, dass er sich mit seinem eigenen Wissen über Sicherheit auseinandersetzen muss, wenn er sein System besonders sicher betreiben will.

Es muss quasi einfach mal gesagt werden. :)

Die Rechtetrennung hat einen Einfluss. Klar ist aber auch, dass sie kein Allheilmittel ist.

Da bin ich voll bei Dir. Das sehe ich genauso.

Der Abschnitt könnte z.B. erläutern, dass bei erfolgreichem Angriff auf die Benutzerzone das Benutzerpasswort relativ leicht ausspioniert werden kann. Dann kann sudo vom Angreifer selbst verwendet werden, um die Rootzone zu erreichen. Ich bin jedenfalls der Meinung, dass man die Rechtetrennung nicht überbewerten darf.

Die Frage wäre für mich hier eigentlich eher, ob so Befehle wie su oder sudo Sicherheitsmechanismen sind oder ob sie nicht eher Komfortmechanismen sind, die dann indirekt den eigentlichen Sicherheitsmechanismus "Rechtetrennung" unterstützen.

Gruß, Martin

Newubunti schrieb:

Und mal umgekehrt gefragt, wie würdest Du das an dieser Stelle aufbauen wollen?

Ich denke, wir sind da schon nahe beianander. Ich würde Bedrohungen aufzählen, vielleicht anhand Beispielen. Erstmal möglichst "untechnisch". Danach würde ich darauf eingehen, wie die entsprechenden Angriffsarten unter Ubuntu "verwirklicht" werden (könnten). In deiner Gliederung wäre dass wohl zunächst "Bedrohungslage" und dann "Angriffsflächen". Erst danach würde ich Maßnahmen darstellen, die die Bedrohungen minimieren - bei Dir wären das die "Mechanismen". Ich halte aber die getauschte Reihenfolge für besser. Bedrohungen - Manifestierungen - Gegenmaßnahmen

Naja, IMO kommt es nicht auf die perfekte Selbsteinschätzung an.

Ich stimme da voll zu. Es muss aber deutlich werden, dass falsche Selbsteinschätzungen auch sehr gefährlich sind. Ich teile daher deine Meinung: Im Zweifel auf ein Feature verzichten und lieber dem Default vertrauen.

Die Frage wäre für mich hier eigentlich eher, ob so Befehle wie su oder sudo Sicherheitsmechanismen sind oder ob sie nicht eher Komfortmechanismen sind, die dann indirekt den eigentlichen Sicherheitsmechanismus "Rechtetrennung" unterstützen.

Ja, das sind Komfortmechanismen. In diesem Sinn ünterstützen sie die Rechtetrennung: Was einfach ist, wird auch akzeptiert. In diesem Komfort liegt aber auch wieder eine Gefahr - und darum ging es mir eigentlich: Es ist so einfach, "sudo", "gksudo" unter Ubuntu zu verwenden. Dass darin bereits wieder eine "Angriffsfläche" liegt, ist auf den ersten Blick nicht erkennbar. Von daher habe ich Bedenken, "sudo" unkritisch als Sicherheitsvorteil zu verkaufen. Zumindest sollte man die Risiken beleuchten.

Falls ihr noch Anregungen sucht: http://www.psychocats.net/ubuntu/security ;-)

DrScott schrieb:

Ich halte aber die getauschte Reihenfolge für besser. Bedrohungen - Manifestierungen - Gegenmaßnahmen

Grundsätzlich hänge ich nicht zwanghaft an irgendeiner Reihenfolge. Wichtig ist für mich erst mal nur, dass Einigkeit über die aufgeführten Punkte besteht.

Die Reihenfolge ordne ich im Zweifel so an, dass sich der Text am Ende gut lesen lässt. Es ist ja zuweilen so, dass man eine Gliederung sehr logisch daherkommt, sich dann aber beim Ausformulieren Probleme ergeben, die sich nur durch eine Umstellung der Gliederungspunkte ausräumen lassen.

Da bin ich dann letztlich am besten Endergebnis orientiert.

Von daher habe ich Bedenken, "sudo" unkritisch als Sicherheitsvorteil zu verkaufen. Zumindest sollte man die Risiken beleuchten.

Also unkritisch erwähnen möchte ich sowieso nichts. Deswegen ja auch meine Haltung, dem Anwender Schwächen bewusst zu machen. Das muss natürlich auf eine Art geschehen, die den Leser nicht in Panik versetzt, also so sachlich wie möglich.

Gruß, Martin

Wie vielleicht einige mitbekommen haben, liefert Ubuntu seit 12.10 spyware mit aus. Das sollten wir in den Artikel mit rein nehmen, vielleicht eine Achtung!-Box:

Ab Ubuntu 12.10 wird Standardmäßig in Unity das Amazon-Suchplugin installiert, welches alle Suchanfragen zu Canonical schickt, die von dort (anonymisiert) an Amazon weitergeleitet werden.

stfischr schrieb:

Wie vielleicht einige mitbekommen haben, liefert Ubuntu seit 12.10 spyware mit aus. Das sollten wir in den Artikel mit rein nehmen, vielleicht eine Achtung!-Box:

Ich habe jetzt folgenden Abschnitt ergaenzt:

Enthält Ubuntu Spyware?

"Warum übermittelt Canonical meine Suchanfragen in der Dash an Amazon?"

Die Aufnahme einer integrierten Amazon-Suche {de} in die Dash von Unity (ab Ubuntu 12.10) wurde kontrovers diskutiert. Während die einen die erweiterten Suchergebnisse willkommen heißen, stellt dieses Vorgehen für die anderen die Wahrung der persönlichen Privatsphäre in Frage. Falls die Amazon-Suche nicht akzeptabel ist, deinstalliert man das Paket unity-lens-shopping. Nutzer anderer Ubuntu-Varianten wie Kubuntu, Lubuntu, Xubuntu usw. sind (bisher) nicht betroffen.

Sollte doch ausreichen, oder?

Ja danke finde ich ok so, ist auch etwas neutraler geschrieben, als ich das wohl gemacht hätte. :D