Posts by m_ueberall

    Habe kein 2FA gesehen.
    Wäre wichtiger, als ein neues UI.

    Du kannst es indirekt aktivieren. 2FA im CCP aktivieren und dann im SCP einstellen, dass der Login nur übers CCP möglich ist.

    Ich möchte in diesem Kontext nochmal auf den Anwendungsfall hinweisen, dass es bisweilen vorkommt, dass mehrere Personen Server via SCP administrieren, aber davon unabhängig eben keinen Zugriff auf die Verträge/Stammdaten haben sollen. (Noch besser wäre natürlich eine Zuordnung bestimmter 2FA-Methoden zu einzelnen Produkten, aber initial eine direkte 2FA-Unterstützung im SCP unabhängig von CCP wäre bereits ein riesiger Schritt in die richtige Richtung!)

    Muss ich mir da jetzt extra nen Account anlegen?

    Bei mir kommt nur "kein gültiger account gefunden" im jdl.

    Sollte nicht nötig sein; Test im "privaten Fenster" unter Firefox/amd64 (Standard-Browser ist Brave) ohne jegliche vorhandene Cookies funktioniert hier, ebenso die aktuelle Version von yt-dlp:

    FYI: [#SECURITY] "QEMUtiny – QEMU escape" (basiert auf CXL-Nutzung)

    Quote

    QEMUtiny is a memory corruption vulnerability in QEMU's implementation of CXL Type-3 device emulation, reported against QEMU master 007b29752e and confirmed working against 5e61afe (May 11, 2026).

    GhostBSD scheint ja eher Desktop-orientiert zu sein. Daher vielleicht mal einen Blick auf OpenBSD werfen?

    terence : Danke für den Tip; OpenBSD ist tatsächlich auch auf der Evaluationsliste, allerdings unterhalb von FreeBSD/GhostBSD. Bislang habe ich nach kurzer Durchsicht einiger Quellen (u. a. YouTube-Videos) im Hinterkopf, dass GhostBSD insbesondere bei der Hardwareunterstützung punkten soll (sowohl bezogen auf die existierenden SBC/Laptops als auch die Architekturen AMD64/ARM64/RISCV), und momentan steht hier auch die Überlegung im Raum, mittelfristig primär Desktops damit zu bestücken. In der Vergangenheit hatte ich *BSD primär "via FreeBSD" kennengelernt.

    Es ist nicht auszuschließen, dass BSD später auch für reine Serveranwendungen zum Einsatz kommt. Als erster Schritt ist hier zunächst allerdings sowieso ein Test im Kontext von signal-cli (und ZFS) eingeplant, wofür Installationen sowohl von FreeBSD, GhostBSD als auch OpenBSD via VM unter Incus anstehen. Das Ganze wird … eine gewisse Zeit in Anspruch nehmen (denn die Zeit verfliegt, wenn man sich amüsiert).

    FYI: Pünktlich zum verlängerten(?) Wochenende gibt es eine neue Kernel-Lücke: "VUL-0: CVE-2026-46300: kernel-source: FragNesia attack: another xfrm/esp based local root exploit"; diese ist insofern "Dirty Frag" sehr ähnlich, als sie auf denselben Kernelmodulen basiert wie CVE-2026-43284, weswegen auch derselbe Workaround von vor ein paar Tagen greift, wenn er bereits/noch aktiv ist (lies: Deaktivierung der extern nachgeladenen Kernelmodule esp4, esp6, rxrpc). AlmaLinux hat einen recht informativen Blog-Eintrag hierzu.

    Und dann pro Tool einen Thread oder wie stellst du es dir vor?

    Das wäre ein Ansatz, ja.

    Vielleicht bekommen wir es (ohne weitere Unterforen) hin, dass wir etwa auch für Kernel-Exploits systematisch Diskussionsfäden für "Kernel-Exploits (alle Distributionen|generisch)", "Kernel-Exploits (Debian/Ubuntu)", "Kernel-Exploits (Fedora)", "Kernel-Exploits (*BSD)", … eröffnen, so dass Nutzer sich nicht totsuchen müssen.

    Also letztlich ein Namensschema "<STACK|MODUL|KOMPONENTE> (<BETROFFENE_UMGEBUNG>)" für individuelle Diskussionsfäden.

    Wenn das zu unübersichtlich wird, kann man ggf. auch neue Unterforen einrichten; dann wäre ein (besserer) Startpunkt vielleicht "Systemabsicherung > Allgemein", gefolgt von "Systemabsicherung > Kernel", "Systemabsicherung > …"

    (Leider scheint es noch nicht möglich zu sein, nutzerseitig zusätzlich Tags zu einem Post hinzuzufügen, was ggf. die Suche vereinfachen würde.)

    [ CC Moderators ]

    Moderators : Könnten wir unter Sonstiges ein Unterforum "Systemabsicherung" bekommen, in welchem die Themen rund um Exploits zentral gesammelt werden können? Ansonsten dürften die "etwas untergehen", insbesondere, wenn Nutzer nicht regelmäßig eine große Zahl an Themen hier verfolgen …

    Da will man am Morgen einen neuen Post bzgl. dringend selbst abzusichernder Linux-Kernel hier einstellen, schon läuft wieder ein größerer Lieferkettenangriff ("Mini Shai-Hulud", zielt auf npm und PyPI). Naja, ist ja bald Freitag (und für manche quasi ein verlängertes Wochenende wg. Brückentag und so), also warte ich mit dem Post noch ein paar Tage … :evil:

    An dieser Stelle nochmal der Tip, keine Module zu installieren, welche kein vorgegebenes/erzwungenes Mindestalter von n Tagen aufweisen. Und wo ich das hier gerade schreibe, darf ich gleich einmal sehen, ob das eigene Build-Script für eine bestimmte Java-Anwendung auf Basis einer anderen bestimmten Rust-Bibliothek diesen Grundsatz auch konsistent einhält (vgl. cargo-cooldown-PoC). Gut, dass wir bald ein verlängertes Wochende haben … :|

    EDIT: Wir könnten das zum Anlass nehmen, und einmal für obige Stacks ein paar eigene Lösungsansätze zusammenzutragen (vgl. diese Kurzübersicht), wie wär's?

    Und ich nutze es gerade so gut wie nicht mehr, weil Ubuntu 26.04 LTS auf sudo-rs umgestellt hat und ansible noch sudo erwartet. become für sudo geht leider immer noch nicht :(

    Ich nutze zwar noch 24.04 LTS, habe aber u. a. in einer Build-Umgebung dafür aktuelle Versionen von sudo und coreutils von Debian "nachgebaut" und installiert; zumindest für sudo allein ist das recht schmerzfrei, wenn man das Paket installiert und via apt-mark hold vor einer späteren automatischen Ersetzung schützt. Natürlich bedeutet das, dass man selbst für Updates für dieses Paket sorgen muss, aber den relativ überschaubaren Mehraufwand ist es IMHO für die eigenen Umgebungen wirklich wert.