|
|
|
|
|
|
|
|
Klar, schade gelaufen, dass man sowas verkannt hat. Wird jetzt immerhin ein Fix entwickelt, der bei gängigen Distributionen (auch für amd64) verteilt wird?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Drepperchen ~= http://www.akkadia.org/drepper/no_static_linking.html ?
Statisches Linken hat doch offensichtliche Vorteile, gerade wenn der Kram eh nie geupdatet wird (was meistens nicht gut ist, aber manchmal weiß man halt schon vorher, dass das einfach nicht passieren wird).
/e: Der USB-Schutz wird da ja angesprochen: http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Deny_new_USB_connections_after_toggle
Klingt für mich eher unbrauchbar für alles was kein Server ist.
Meine Idee ist natürlich unfassbar aufwändig in der Implementierung (man bräuchte dafür letzlich ein Interface mit dem der Kernel sicherheitsrelevante Abfragen in den Userspace delegieren kann(!))
| | USB-Whitelisting
Erstmal denke ich, dass das durchaus funktionieren kann. Man kann zwar
das Gerät nicht eindeutig identifzieren, hat aber in jedem Fall den
Hardwarepfad zum Gerät, der eindeutig ist, sofern man dem Roothub(s)
traut.
Die Nervigkeit davon kann drastisch reduziert werden, ohne die
Sicherheit großartig zu reduzieren (es wäre auch so kein vollständiger
Schutz, sondern nur ein Schutz im laufenden Betrieb), wenn man z.B.
den Hardwarepfad samt USB-Deskriptor und Nutzerzustimmung speichert
und entsprechend nicht mehr nachfragt. Das bräche nur dann, wenn ein
Angreifer ein Gerät mit identischen Deskriptor (und damit identischen
Fähigkeiten, weil eine Re-Enumeration mit anderem Deskriptor ja wieder
die Abfrage triggern würde) in den gleichen Port gesteckt würde, wie
ein vorhandenes Gerät. Ich muss da spontan an die klassischen
Keylogger denken, die in die PS/2-Leitung eingeschleift wurden... bei
einem USB-äquivalent mit dieser Angriffsmethode wäre der Upstream-Port
für die Tastatur (bspw.) vom Host aus allerdings unsichtbar.
Umstecken und die alte Tasta woanders reinstöpseln ist ja eher keine
Option (würde die Abfrage wieder triggern), aber natürlich auch möglich. | |
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 26.08.2014 15:31]
|
|
|
|
|
|
|
|
|
Genau der. Den anderen (Blogeintrag) habe ich gerade nicht zur Hand.
Heute war wieder $BERATER zur Installation im Haus.
Er klickt auf den Java-Installer für 6u27
Ich: ist schon installiert. In der aktuellesten Version
Er: Die interessiert mich nicht.
Er klickt trotzdem
Ich ab.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das ist mir bewusst, das ist aber trotzdem keine effektive Abwehr.
- Ich kann nur sagen "okay, jetzt sind USB-Geräte ok"
- Dann stöpsel ich nen USB-Stick rein
- Und erst dann kann ich nachträglich (im kernellog) sehen, was der Stick kann bzw. macht
- Da kann es aber schon zu spät sein
Effektive Abwehr geht m.E. nur, wenn man für jedes Gerät nach der Enumeration den Deskriptor "pinnt" und nachfragt. Gut, das wird in jedem Fall eine Menge USB-Timeouts überschreiten, deswegen würde der Algorithmus ca. so aussehen:
- USB Device-Add-Event
- Deskriptor einlesen, USB-Port in den Talk-to-the-Hand-Modus schalten
- Nachfrage abwarten
- Re-enumerieren, Deskriptor mit gepinnten Deskriptor gegenprüfen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Im Ernst? Qt sieht schon $ewig wie nativ aus ; ob das UI-Design auch den Paradigmen des jeweiligen Systems folgt, hängt außerhalb von Dialogen allerdings vom Programmierer ab. Man merkt das oft auch gar nicht, z.B. benutzen Elster und VLC Qt.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von teK
Heute war wieder $BERATER zur Installation im Haus.
Er klickt auf den Java-Installer für 6u27
Ich: ist schon installiert. In der aktuellesten Version
Er: Die interessiert mich nicht.
Er klickt trotzdem
Ich ab. | |
 Kann man jemanden damit eigentlich für Einbrüche wegen alter Versionen haftbar machen? Oder müsst ihr das dann später fixen entgegen deren Beratung, weil's ja immer noch eure Systeme sind?
|
|
|
|
|
|
|
|
|
|
|
|
Mit Qt Quick/QML kann man inzwischen auch seit ein paar Qt Versionen etwas äh "freiere" Oberflächen basteln. Bin ich, zumindest aufm Desktop, aber kein großer Freund von. Aber schnell mal sowas wie Graphen und Diagramme basteln soll damit ganz angenehm sein.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von ShinyDoofy
| | Zitat von teK
Heute war wieder $BERATER zur Installation im Haus.
Er klickt auf den Java-Installer für 6u27
Ich: ist schon installiert. In der aktuellesten Version
Er: Die interessiert mich nicht.
Er klickt trotzdem
Ich ab. | |
Kann man jemanden damit eigentlich für Einbrüche wegen alter Versionen haftbar machen? Oder müsst ihr das dann später fixen entgegen deren Beratung, weil's ja immer noch eure Systeme sind?
| |
Die haften normalerweise nur in Höhe des Auftragswertes.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von YT
| | Zitat von ShinyDoofy
| | Zitat von teK
Heute war wieder $BERATER zur Installation im Haus.
Er klickt auf den Java-Installer für 6u27
Ich: ist schon installiert. In der aktuellesten Version
Er: Die interessiert mich nicht.
Er klickt trotzdem
Ich ab. | |
Kann man jemanden damit eigentlich für Einbrüche wegen alter Versionen haftbar machen? Oder müsst ihr das dann später fixen entgegen deren Beratung, weil's ja immer noch eure Systeme sind?
| |
Die haften normalerweise nur in Höhe des Auftragswertes.
| |
oder halt nach dem, was im vertrag steht.
mit einer ausnahme, wenn es grob fahrlässig gemacht wird, dann im masse des entstandenen schadens. wie immer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von FreeHawk*
Gibts denn noch taugende Distros die vollkommen auf systemd verzichten können?
(Und wo man nicht zwangsweise nur n src basierten Packetmanager hat)
| |
klar, debian stable zum beispiel, rhel 6 (man munkelt, dass sich das 7er nicht so wirklich gut bei grossen firmen auf servern macht*) und vermutlich eine menge andere.
so wirklich richtig wissen, wie gut die sachen im profi umfeld ankommen wird man wohl erst so gegen 2018-2020 wissen, da da der support für die SLES und RHEL sachen ohne systemd auslaufen wird.
ich weiss es von einer grösseren firma, dass die es nicht so ohne weiteres einsetzten werden, da die ansonsten ne ganze latte an etablierten und stabil laufenden tools umbiegen müssten.
|
|
|
|
|
|
|
|
|
|
|
Ja okay gut, dass die Serversysteme eh noch was Zeit dafür brauchen ist klar, aber ich meinte auch mehr so Richtung Desktop / Rollingrelease.
Auf Servern bin ich mit den BSDs momentan gut bedient 
|
|
|
|
|
|
|
|
|
|
|
|
Wenn Debian stable darauf umschwenkt geh ich davon aus, dass das auch zuverlässig läuft. Aber vor dem Upgrade hätte ich echt Schiss.
|
|
|
|
|
|
|
|
|
|
|
wie gesagt, momentan dürften das noch einige sein.
wie das ganze in zukunft aussehen wird, wird sich zeigen.
der punkt mit den servern ist halt nach wie vor, dass linux da seine macht ausspielt und von der seite her mehr einfluss kommen kann und wird, als es von der eher nicht existierenden desktop seite kommen wird.
die gnome leute haben sich ja in den letzten paar jahren erstmal ihr ecosystem genüsslich zerlegt. von den kde leuten hab ich zumindest nichts sonderlich innovatives mehr gehört und der rest ist halt eh unter selten zu sehen.
die x sache ist immer noch einer der grössten bremsklötze für den desktop und wayland war mal ein toller ansatz, den man so richtig verkackt hat, so vom design her. das ist momentan nen x light.
das ganze darf man als kleines oder auch grosses fiasko bezeichnen. es tut sich zwar was, aber an den falschen stellen. es gibt tolle infrastruktur sachen für desktop systeme, allerdings absolut keine desktops die diese sachen auch nur in ansätzen nutzen oder gar nutzen könnten.
--
nebenbei, dieser teil könnte etwas mehr rant sein, systemd ist halt ein windows ansatz, den die leute gerade toll finden, weil es verspricht den desktop voran zu bringen, dabei bleibt allerdings der fast 90% marktanteil im server bereich einfach mal komplett auf der strecke.
im desktop bereich hätte es theoretisch ein paar features die interessant sind, allerdings nicht in der art, wie sie dort momentan eingebaut sind.
das grosse von den systemd leuten angepriesene killer feature namens "schnelles booten" ist seit dem SSDs mehr oder weniger standard sind und die CPUs so effizient laufen wie seit intels Core 2 architektur einfach irrelevant geworden. selbst meine nicht SSD linux rechner mit zig services brauchen vom POST bis zum login < 10 sekunden. das teil mit SSD... ihr könnts euch denken. das läuft übrigens alles mit debians sysv init.
das was hier inzwischen limitiert ist einfach, dass die services zeit zum starten brauchen und die kann systemd einfach nicht beschleunigen.
das problem, was ich letztens schonmal etwas sarkastisch angepöbelt hatte ist die inklusion von netzwerkservices die auf ports lauschen. das sind effektiv die besten backdoors für systeme, die man nur haben kann. du findest darin einen exploit und et voila hast du root access auf PID 1 level und kannst tatsächlich einfach restlos alles machen ohne bemerkt zu werden.
ihr erinnert euch sicherlich noch an die ganzen sachen die windows auf grund dieser svchost.exe sache erwischt hatten. das ist exakt das gleiche, was systemd macht. selbst microsoft hat inzwischen eingesehen, dass das eine verflicht miserable idee war und hat bzw. ist dabei das zu ändern und "wir" im linux land freuen uns gerade die eier ab, weil wir jetzt einen master service haben, der offene ports im netzwerk hat über den man dinge tun kann und der ja grundsätzlich nicht hackbar oder sonst irgendwie sicherheitskritisch werden kann...
nebenbei, wie war das noch? linux vermarktet sich nach wie vor als unix ähnliches system, welches stolz auf den KISS ansatz ist und es so hoch flexibel ist, weil es eben viele kleine austauschbare teile hat? jetzt nicht mehr, jetzt haben wir einen monolitischen master prozess, für den man alles neustarten muss, wenn man diesen patchen will / muss. ist auch sehr schön, man kann den kernel demnächst im laufenden zustand patchen bzw. austauschen, leider muss ich dann aber für bug-/security fixes des init prozesses alles neustarten. das hier ist das einzige, was mir dazu einfällt: m(
aus meiner sicht entwickelt da eine gruppe von leuten, die unix nie verstanden hat, gerade an einem komplett überflüssigen system, was vieles was linux gross gemacht hat eliminiert und zwingt es allen auf, ohne überhaupt zu verstehen, dass sie sich damit ihr eigenes grab schaufeln. im schlimmsten fall auch das grab von linux wie wir es bisher kennen.
irrwitzig an der stelle ist, selbst apple ist nicht so dämlich sich so eine software als init proc ins system zu setzten. nebenbei, OSX ist nach dem schritt mehr unix (KISS und modular) als es linux ist, selbst auf XNU seite.
irritierend kann man da dann noch die beiden BSDs anführen (FreeBSD und DragonFly BSD), die dadurch einen lustigen zulauf von profis bekommen werden und sehr wahrscheinlich auch von grösseren firmen, wenn letztere nicht die grosse wende in richtung oracle oder *huh* microsoft antreten.
|
|
|
|
|
|
|
|
|
|
Wieder so Pseudo-Argumente "Unix" "KISS" "einfach" "Austauschbar" "sicher". So wird systemd/GNU/Linux nie ein konkurrenzfähiges Mainstream OS.
|
|
|
|
|
|
|
|
|
|
|
|
100% Zustimmung, ich hab mich bisher nur am Rande damit beschäftigt aber das wäre auch genau mein Verständnis der Problematik. Der o.g. Artikel fasst das ja schön "punchy" zusammen: systemd is the answer to a question nobody asked.
|
|
|
|
|
|
|
|
|
|
|
Hö, KDE hat doch erst in den letzten Jahren seinen PIM und Desktop Search Kram komplett neu gemacht. Seit 2012-2013 dann die ganzen Arbeiten Richtung Wayland, Frameworks 5 und natürlich KDE 5. Vor einigen Wochen wurde ja erst Plasma 5 vorgestellt.
/e: Ansonsten kann ich das gut nachvollziehen und stimme dir zu.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 26.08.2014 19:40]
|
|
|
|
|
|
|
|
|
|
Vielleicht kriegt man das ja noch hin, wenn ein neuer Maintainer systemd kleiner macht. Oder zerteilt.
|
|
|
|
|
|
|
|
|
|
|
i3pystatus:
533 commits
30 contributors
|
|
|
|
|
|
|
|
|
|
|
|
Egal, führt eh zu nichts.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 26.08.2014 22:26]
|
|
|
|
|
|
|
|
|
Tu ich nicht.
Aber ich fresse tatsächlich gerne Weisheit mit Löffeln. Damit bin ich aber noch nicht fertig!
|
|
|
|
|
|
|
|
|
|
|
Bei dir weiß ich ja, dass du insgeheim auf die Lücke zwischen LPs Schneidezähnen stehst. <3
Übrigens voll doof mit i3pystatus, das will nur alles vereinen, obwohl es für alle Features vorher auch schon Lösungen gab. Hast wohl Unix nicht verstanden, wa? 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 26.08.2014 21:45]
|
|
|
|
|
|
|
|
|
|
Und ständig patchen die Leute da noch mehr rein! Furchtbar!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Egal, führt eh zu nichts.
| |
Joa. Anstatt den xten Beitrag über die Argumente gegen die Argumente über die Art der Argumente für und gegen systemd zu lesen, möchte ich wirklich nur mal einen qualifizierten Blogpost über Traxers Punkte haben.
Namentlich:
(1) systemd ist nicht in bestehende Infrastrukturen integrierbar. Wenn die eingesetzte Distro zwangsweise systemd einschleppt, wird das im professionellen industriellen Umfeld Upgrades auf breiter Fläche verhindern oder ganz zur Abkehr von Linux führen. Dass das keine Paniktheorie ist, hat Solaris 9->10 gezeigt, als die mit ihren SMFs ähnlichen Quatsch zwangsweise eingeführt haben und damit Solaris im Nicht-Datenbankumfeld effektiv begraben haben. Solaris 9 wurde dann noch solange getreten wie es ging, aber anstelle des Upgrades auf 10 folgten Migrationen auf Linux. Das könnte 1:1 die Situation zwischen RHEL6 und 7 werden, wie Traxer bereits sagte.
Aber da (1) immernoch genug Potential zur endlosen Debatte bietet, lieber gleich weiter:
(2) Eierlegende Wollmichsau mit bisher wenig etablierten Komponenten als PID 1.
Dieser Punkt sollte eigentlich keinen Diskussionsspielraum bieten, das geht einfach nicht.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 26.08.2014 22:52]
|
|
|
|
|
|
|
|
|
| | Zitat von Rufus
| | Zitat von Oli
Egal, führt eh zu nichts.
| |
Joa. Anstatt den xten Beitrag über die Argumente gegen die Argumente über die Art der Argumente für und gegen systemd zu lesen, möchte ich wirklich nur mal einen qualifizierten Blogpost über Traxers Punkte haben.
Namentlich:
(1) systemd ist nicht in bestehende Infrastrukturen integrierbar. Wenn die eingesetzte Distro zwangsweise systemd einschleppt, wird das im professionellen industriellen Umfeld Upgrades auf breiter Fläche verhindern oder ganz zur Abkehr von Linux führen. Dass das keine Paniktheorie ist, hat Solaris 9->10 (afaik) gezeigt, als die ähnlichen Quatsch eingeführt haben und damit Solaris im Nicht-Datenbankumfeld effektiv begraben haben. Solaris 9 wurde dann noch solange getreten wie es ging, aber anstelle des Upgrades auf 10 folgten Migrationen auf Linux. Das könnte 1:1 die Situation zwischen RHEL6 und 7 werden, wie Traxer bereits sagte.
Aber da (1) immernoch genug Potential zur endlosen Debatte bietet, lieber gleich weiter:
(2) Eierlegende Wollmichsau mit bisher wenig etablierten Komponenten als PID 1.
Dieser Punkt sollte eigentlich keinen Diskussionsspielraum bieten, das geht einfach nicht.
| |
Bei (1) hast du natürlich absolut recht. Selbst ein Debian Stable upzudaten ist schon nervig. Da gibt's auch kein Argument gegen; Never change a running system halt.
Zu (2), da suche ich dir jetzt nicht die vielen, vielen Antworten in den Debian, Ubuntu, Systemd Mailing Listen raus, wo Monate- oder Jahrelang über genau die Thematik diskutiert wurde. Da findest du auf jeden Fall Leute die kompetenter als wir alle sind, und zwar sowohl Gegner als auch Fans von systemd.
Es wird sich zeigen, wie sicher systemd ist. Vielleicht habt ihr recht und es stellt sich als Risiko raus. Vielleicht auch nicht.
|
|
|
|
|
|
|
|
|
|
|
|
Ich persönlich finde, dass PID 1 einfach so klein sein sollte, wie möglich und sinnvoll ist. Und dass PID 1 eher nix am Netzwerk verloren hat.
|
|
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( v0.30 gute Gründe für systemd ) |
