DSM 7.0 DSM 7.0 (41890) Final - Erfahrungen, Probleme, Bugs

[mamema]

Man nennt das Fortschritt.

hmm, ich bin da nicht so sicher ob ich das Fortschritt nennen will. Wer höhere Sicherheit will, der bringt seinen veralteten Kernel auf einen aktuellen Stand. Das tut Synology aber nicht.
Aus dem Blickwinkel von Security ist das eher "wir fahren ein Auto ohne Sicherheitsgurte, aber wir haben jetzt neue Schlösser montiert."
Mein Eindruck ist mit DSM 7 ein anderer. Es passt Synology nicht, dass so fitte Leute wie Du aus DSM mehr (als der Hersteller) rausholen und evtl. haben die im Support die Nase voll von Benutzern die motzen über Probleme die nicht direkt DSM angekreidet werden können.
Also versucht man, bisher offene Türen zu schliessen. Das sind aber keine Security Löcher sondern Usability Themen

 

[mamema]

Hatte das Problem vielleicht schon jemand, bzw. habt ihr Vorschläge, welche Parameter in der user.js dafür verantwortlich sein könnten?

Entwicklermode des Firefox sagt was?

 

[Chris122]

2 Fehler, die in der originalen FF-Installation nicht auftreten:

Uncaught (in promise) Error: Both wasm and asm failed to loadTypeError: t.asm.sodium_init is undefined
    e https://192.168.0.10:5050/scripts/noise/sodium.js?v=1621235040:1
    promise callback*t https://192.168.0.10:5050/scripts/noise/sodium.js?v=1621235040:1
    <anonymous> https://192.168.0.10:5050/scripts/noise/sodium.js?v=1621235040:1
    <anonymous> https://192.168.0.10:5050/scripts/noise/sodium.js?v=1621235040:1

TypeError: this.cred is undefined
    GetLoginParams https://192.168.0.10:5050/webman/sds-common.js?v=1623045722:12
    VueJS 87
    (...)

 

[Tommes]

@mamema
Mit Sicherheit passt es Synology nicht, das so Leute wie ich versuchen, das System so zu verbiegen, wie wir es gerne hätten… ohne Rücksicht auf Verluste. Wenn ich das mal mit Ultimate Backup vergleiche, so wollten die Leute stets alle möglichen Funktionen eingebaut haben um noch mehr Freiheiten zu genießen. Aber wehe dem, es wäre dabei mal was schief gegangen und wir hätten durch einen dummen Fehler bei einem Großteil der Benutzer einen Datenverlust verursacht… dann hätten wir uns ganz schön warm anziehen können. Und da hätte es auch niemanden Interessiert, ob das Paket unter GPL3 läuft oder nicht. Daher haben auch wir oftmals zähneknirschend Dinge freigeschaltet, aber auch wieder bewusst zurückgenommen… eben weil uns das zu heikel wurde. Und jetzt überleg mal, welche Verantwortung Synology seinen Nutzern gegenüber hat.

Sicherlich ist Synology was Kernel oder sonstige Dinge angeht, nicht immer up to date… aber wir reden hier auch immer noch von einem NAS. Und manchmal ist die gute alte Technik halt besser oder zumindest ausreichend um sicher agieren zu können. Ein altes Auto mit Sicherheitsgurten ist immer noch besser als ein altes Auto ohne Sicherheitsgurte. Aber selbst wenn ich ein flammneues Auto habe und den Sicherheitsgurt trotzdem nicht anlege, dann bringt mir das am Ende auch nichts. Daher… root grundlegend zu sperren ist sicherer als root nicht zu sperren, egal ob man dabei einen alten oder einen neuen Kernel verwendet.

Also versucht man, bisher offene Türen zu schliessen. Das sind aber keine Security Löcher sondern Usability Themen

Das sehe ich wiederum anders. Aber gut… unsere Gedanken sind ja glücklicherweise frei und so darf jeder denken, was er will. Für mich ist eine geschlossene Tür erstmal besser als eine offene. Für viele Türen gibt es Schlüssel, manche sollte man aber einfach nicht aufmachen können und manche Türen sollten für immer geschlossen bleiben. Würden wir jetzt von geöffneten Ports reden, wären wieder alle am bellen, wie schlimm doch ein offener Port … oder eine offene Tür ist.

Tommes

 

[mamema]

@Chris122 HTTP Komprimierung an oder aus?

 

[AndiHeitzer]

Sicherlich ist Synology was Kernel oder sonstige Dinge angeht, nicht immer up to date…

Ich hab grade mal auf der VMM mit DSM7 geschaut:
Kernel 4.4 ist da verbaut ...
-> Linux DISKSTATION 4.4.180+ #41890 SMP Fri Jun 25 02:42:33 CST 2021 x86_64 GNU/Linux synology_kvmx64_virtualdsm
Warum setzt man eigentlich auf ein fast schon totes Pferd?

https://de.wikipedia.org/wiki/Linux_(Kernel)

 

[Tommes]

Warum setzt man eigentlich auf ein fast schon totes Pferd?

Was fragst du mich? Frag Synology!

 

[mamema]

weil so Hochsicherheitsmeldungen wie "Deaktiviere den Admin" viel einfacher zu implementieren sind, statt ein Betriebssystem schlicht von Grund auf neu bauen zu müssen.

 

[AndiHeitzer]

@Tommes ... da musst Du Dich nicht rechtfertigen.
Ich versuche nur zu verstehen, was Syno da treibt ...

 

[Tommes]

Um dieses Streitthema nicht weiter ausufern zu lassen, da wir hier eh nie auf einen Nenner kommen werden. Ich war und bin mit Synology stets zufrieden gewesen. Auch halte ich die Aktionen, die Synology bezüglich Sicherheit ergreift, als richtig und sinnvoll. Sollte sich meine Meinung eines Tages ändern, werde ich mich wohl nach etwas anderem umsehen. Und genau das steht euch ja auch frei…

 

[mamema]

@Tommes ... da musst Du Dich nicht rechtfertigen.
Ich versuche nur zu verstehen, was Syno da treibt ...

Gewinnmaximierung! Die Dinger verkaufen sich auch mit altem Kernel und alten CPU. Die Löcher welche der alte Kernel hat, flickt man dann kreativ indem man das Betriebssystem masakriert und root Zugang sperrt. Analogie Auto: Airbags sind uns zu teuer, drum lass uns Rasenmähermotoren verbauen, der ist langsam, da ist der Aufprall nicht tödlich.

 

[Kurt-oe1kyw]

Airbags sind uns zu teuer, drum lass uns Rasenmähermotoren verbauen,

Rasenmäher sind aber ein ganz schlechter Vergleich ?
https://www.sueddeutsche.de/gesundheit/garten-gefahr-im-gras-1.4166138

 

[FricklerAtHome]

So ein bischen tut sich da doch zwischen den Versionen:
DSM 6.1 hat Kernel 3.10.102 und Samba Version 4.4.16
DSM 6.2 hat Kernel 4.4.59+ und Samba Version 4.4.16 ( Kernel noch bis 2022 LTS Support)
DSM 7.0 hat Kernel 4.4.180+ und Samba Version 4.10.18 (Kernel auch hier bis 2022 LTS Support)

Der Kerndienst SMB macht für ein NAS hier einen deutlichen Funktions- und Sicherheitsgewinn.
Und wie man bei den Kernelversionen sieht machte auch das DSM 6 mit den Subversionen immer eine Entwicklung. Nicht immer das letzte und aktuellste Release aber immer mit noch aktuellen Security - Support!
Das ist ein bekanntes Phänomen. Es gibt bereits Debian 10 (und bald auch Debian 11), einige auf Debian laufende Serveranwendungen empfehlen aber weiter den Einsatz von Debian 9 (hat auch noch LTS Support). Dies hält die Entwicklungszyklen stabil und die Sicherheit aktuell.

Ich tippe mal in 2022 wird DSM 7.1 erscheinen mit mindestens Kernel 4.9, zumindest hat das Synology bisher immer so abgebildet.

glAuunimeiLibedeNA
Der Frickler@Home

 

[Jim_OS]

Ihr seit doch eigentlich alle schon lange genug dabei um zu wissen wie es bei Synology läuft. Es hatte doch wohl wirklich niemand ernsthaft geglaubt das Synology mit DSM7 z.B. auf einen aktuelle Linux Kernel wechselt, oder diesen einsetzt. Das Prinzip ist das bestehende und veraltete System so lange irgendwie am Leben zu erhalten bis nichts mehr geht. Bei evtl. Lücken oder Inkompatibilitäten wird versucht diese irgendwie zu schließen oder zu umschiffen. Solange das funktioniert muss jeder von uns damit leben. Wer ein aktuelles System, oder gar Innovationen erwartet, der ist bei Synology falsch. Wobei mir pers. so ein System immer noch lieber ist, als ein neues innovatives, bei dem sich dann fortlaufend Bugs auftun. Oder anders gesagt: Welcher Hersteller in diesem Bereich wäre dann eine Alternative? Mir ist da keiner bekannt.

JM2C

VG Jim

 

[luddi]

Welcher Hersteller in diesem Bereich wäre dann eine Alternative? Mir ist da keiner bekannt.

Vielleicht dieser hier: TrueNAS Open Storage
Ich kann aber nichts detailliertes darüber sagen wie hier mit Kernel Angelegenheiten umgegangen wird....

 

[Iarn]

Sicherlich ist Synology was Kernel oder sonstige Dinge angeht, nicht immer up to date… aber wir reden hier auch immer noch von einem NAS. Und manchmal ist die gute alte Technik halt besser oder zumindest ausreichend um sicher agieren zu können. Ein altes Auto mit Sicherheitsgurten ist immer noch besser als ein altes Auto ohne Sicherheitsgurte. Aber selbst wenn ich ein flammneues Auto habe und den Sicherheitsgurt trotzdem nicht anlege, dann bringt mir das am Ende auch nichts. Daher… root grundlegend zu sperren ist sicherer als root nicht zu sperren, egal ob man dabei einen alten oder einen neuen Kernel verwendet.

Wenn wir schon die Auto Analogie nehmen, dann hat der Hersteller des Motors, in diesem Fall des Kernels bei etlichen Modellen gesagt, er stellt den Support ein, dieser ist unsicher und sollte bei nächster Gelegenheit ausgetauscht werden.
Im Bezug auf Synology sind das alle Modelle, die noch keinen Kernel 4.4 haben (und der ist auch gut abgehangen) und das sind gar nicht so wenige.
Und ja ich habe hier im Forum sehr häufig das Argument mit Kernel Backports gelesen. Die meisten Kernel Backports werden allerdings eher auf Geräten verwendet, die nicht im Internet hängen. Prominente Ausnahme ist Google aber die dürften mehr Mitarbeiter haben, die sich mit Kernel Patches beschäftigen, als Synology insgesamt Mitarbeiter hat.
Was Synology hier macht, ist in meinen Augen grob fahrlässig und zumindest in meinem Netzwerk werden alle Modelle mit 3.10 Kernel extra abgesichtert und haben keine Zugang zum Internet.

 

[mamema]

vielleicht ist es genau der fehlende Konkurrenzdruck der DSM 7 zu dem macht was es ist, das "Meh..." Release mit den abegrundeten Icon Ecken.

 

[Iarn]

@Tommes ... da musst Du Dich nicht rechtfertigen.
Ich versuche nur zu verstehen, was Syno da treibt ...

Ein Punkt dürfte sicherlich das Behindern von xpenology sein. Da man selbst in Bezug auf Lizenzen (GPL, hust) nicht so sauber arbeitet, ist der Rechtsweg ausgeschlossen. Man behauptet zwar immer wieder xpenology wäre nicht legal, aber scheut den Gang vor den Kadi (vermutlich weil der Schuss nach hinten losgehen könnte).
Je mehr sich Synology von den Mainline Kerneln wegbewegt, desto schwieriger wird es für xpenology.

 

[FricklerAtHome]

@ LARN zu Xpenology: Das Katz und Maus Spiel zwischen Synology und Xpenology steht aktuell bei beiden auf Kernel 4.4.59. Zumindest mit in der Hardware Synology-nahen Selbstbau NAS Kisten lässt sich Xpenology unter DSM 6.2 nutzen. Mit DSM 7.0 wird wohl wieder eine Zeit X vergehen bis der Boot-Loader von Xpenology angepasst ist. --- Unsere Diskussion mit dem DSM Update auf 7.0 ist aber nicht neu. Eigendlich wurde mit jeder DSM Version ein entsprechender Pro und Kontra vergleich geführt.
Ich habe für mich dazu eine sehr private Entscheidung getroffen: Das User-Interface von Synology ist für meine täglichen Arbeiten mehr als ausreichend. Für die wichtigsten Dienste in meinem Netzwerk bietet DSM native APP's und Dienste an. Systemausfälle der Synology-Hardware sind extrem selten (es sterben Platten, aber selbst mein DS215j zeigt noch keine Verschleißerscheinungen). Ich missbrauche mein NAS aber auch nicht für Sekundäre Dienste. Z. B. "iTunes-Server" läuft nativ bei mir auf einem echten MAC-MINI von 2011, "PIHOLE", "FHEM", "RSPAMD", "ADGUARD" laufen zusammen mit "PRTG-WIN10-VM", "MARIA10-VM", "Virtual-DSM 6.2" auf einer ZOTAC CI329 mit ProxMox. Dabei sind alle VM's und Container auf einer NFS Freigabe einer der Synology-Kisten gehostet. --- Kurzum bis auf die Survillance-Station, Synology Directory Server, Hyperbackup und rsync bilde ich alles in Docker oder VM's ab, und das so das weder ein DSM Update noch sonst eine Situation einer einzelnen Komponente groben Unfrieden in der Gesamtfunktionalität meines Netzwerk's auslöst. --- Ist ausreichend Strom da, läuft es (spätestens nach 45 Minuten --- reines HeimNetz mit 63 aktiven devices)
Und genau dafür nehme ich Synology. Das NAS Gui mit der für mich besten Usabillity.

undimmeinlicbeiderNac
F@H

 

[Jagnix]

Wer höhere Sicherheit will

lässt nicht alles mit root Rechten laufen.