frostschutz schriebdmesg kannst du freischalten (kernel.dmesg_restrict o.ä.), beim Rest vielleicht besser, wenn normale User das nicht können...
Bzgl. "kernel.dmesg_restrict" danke, aber "vielleicht besser" - häh?
Dass jeder Nutzer auf einfache Art die Bildschirmhelligkeit verändern kann (anstatt sich mit den fummeligen Tasten durchs OSB zu quälen und dabei vielleicht sonstwas zu verstellen - aka "Mein Computer ist kaputt!", weil er auf den falschen Monitoreingang geschaltet hat) ist doch kein Nachteil.
Und was kann mit mit dmesg oder fstrim falsch machen, wenn man es versehentlich (Win+D) oder aus Neugier (Hm, was ist RMB/Trimmen?) auslöst?
Meine Frage war: Entstehen dadurch relevante Sicherheitsrisiken? - Falls ja: In welcher Form und wie kann ich das dann anders lösen?
"chmod +s /usr/bin/ddcutil" habe ich inzwischen durch "chmod a+rw /dev/i2c-*" ersetzt. Mit "kernel.dmesg_restrict=0" muss ich mich noch beschäftigen, aber bzgl. fstrim habe ich noch keine Alternative gefunden.
Wie sieht es z. B. mit der Gruppe "disk" aus (oder einer extra dafür erstellten): Könnte man es nicht so konfigurieren, dass jeder der dazu gehört fstrim nutzen kann? - Damit kenne ich mich leider noch überhaupt nicht aus.
Btw:
Mit Arch-Derivaten beschäftigte ich mich erst seit letztem Jahr (bis letzten Monat war LinuxMint 18.3 mein Produktivsystem) und bin jetzt dabei mir eine saubere Artix-Runit-Xfce-Installation einzurichen. Aktuell nutze ich die Testinstallation, an der ich schon seit fast einem Jahr herumbastle.
Mir ist klar, dass ich hier "nur" zu Arch Hilfe bekommen kann, aber das reicht mir: Das meiste lässt sich direkt übertragen (u. a. das Arch-Wiki hat mir schon oft geholfen) und Ausnahmen sind mein Problem: Dadurch lerne ich Artix besser kennen.
GerBra schriebCaramon2 schriebDa ich nicht sehe wo es ein Unterschied sein soll, ob sich der Befehl per "sudo" ohne Password oder direkt ausführen lässt, habe ich mich nicht weiter damit beschäftigt.
Der "Unterschied" wäre IMHO: Das setuid-Flag gilt halt für *alle* User, die das Programm starten können (bei 755 halt alle).
Mit der Lösung über sudo kann das User-/Gruppen-bezogen reglementiert werden. Ich würde im Normalfall immer sudo vor root-setuid bevorzugen¹.
Prinzipiell schon klar, aber "meine" Befehle sollen ja ruhig "alle" nutzen können (s. o.), zumal es hier und bei den Bekannten, um deren PCs ich mich kümmere, sowieso nur einen Benutzer (+root) gibt: Der ist quasi "alle Benutzer", was soll ich da beschränken? - Oder übersehe ich etwas?
Die /etc/rc.local hat aktuell keinerlei Funktion mehr, wird also nicht abgearbeitet. Das war aktuell zur Zeit der Archlinux-eigenen Initscripts basierend auf SysV-Init.
Sorry, das wusste ich nicht.
Unabhängig davon geht es mir nur darum, ob bzw. in welcher Form man durch "chmod +s bei dmesg, ddcutil und fstrim" angreifbar wird und wie man es ggfs. anders umsetzen kann. - Ganz allgemein, da ich das auch bei Bekannten (Solus-Budgie, LinuxMint-Xfce, Zorin-Lite - bei denen funktionierte rc.local das letzte Mal noch) nutzen möchte.
Gerry_Ghetto schriebZu fstrim: Es sollte eigentlich einen systemd Service und einen systemd Timer dazu geben. Dies scheint mir auch der bessere Ansatz zu sein, anstatt einem Nutzer zu erlauben, fstrim zu starten.
Wie gesagt: Es geht um ext. SSDs um Partitionen anderer Installationen. Da bringt ein Cronjob o.ä. nichts, da es ein sehr großer Zufall wäre, wenn die genau zu dem Zeitpunkt angeschlossen und eingehängt sind. - Insbes. wenn der nur wöchentlich ausgeführt wird.
Um mal aus der man-page zu zitieren:
Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-quality SSD devices. For most desktop and server systems a sufficient trimming frequency is once a week.
Das ist inzwischen längst überholt: Selbst meine erste SSD (250 GB BX100 von 2015 - die zeigt sogar auch die tatsächlichen Flashwrites an) betraft das schon lange nicht mehr.
Da ich viel mit Videoschnitt mache (DVB-S-Aufnahmen), habe ich auf der betreffenden SSD durchschnittlich 7 GiB/Tag Hostwrites: Überwiegend temporäre Dateien, die anschließend gleich wieder gelöscht werden: Weshalb sollte der SSD-Controller diese Daten (7x7 = zuletzt 49 GiB - auf einer in meinem Fall 120 GB SSD) noch bis zu eine ganze Woche lang mitschleppen und herumschaufeln, obwohl sie eigentlich schon längst gelöscht sind? - DAS wäre schädlich für die SSD.
Mit trimmen macht man keine SSD mehr kaputt und es kostet seit SATA 3.1 auch keine Zeit mehr, da es vom Laufwerk gecached wird. Deshalb nutzte ich auf allen automatisch eingehängten Partitionen (btrfs+zstd, xfs, ntfs3) online-discard.
Du könntest spezialisierte systemd Service Units schreiben und sie dann bei Bedarf starten.
Tut mir leid: Ich hatte nicht erwartet, dass systemd bzgl. "chmod +s" zum Thema wird und habe deshalb Artix nicht erwähnt, um unnötige Diskussionen zu vermeiden.
Aber auch letzten Monat, nach 6 Jahren LinuxMint (mit systemd) hätte ich nicht gewusst, was "systemd Service Units" sind und was man damit macht. Bzw. ob mir das was bringt:
Ich schließe die ext. SSD an, arbeite damit, trimme sie anschließend per RMB/Trimmen, hänge sie aus und lasse sie noch eine weite angeschlossen, damit der SSD-Controller seine internen Arbeiten abschließen kann.
Ich nutze zwei interne SSDs und drei externe: Auf einer davon habe ich mehrere Linux-Installationen parallel (natürlich bootfähig) installiert (letztes Jahr bis zu 9 Stück - div. Distributionen), die ich an div. PCs und ggfs. auch in VMs boote, wenn ich mehrere Installationen gleichzeitig nutzen will: Z. B. um die anderen zu aktualisieren, ohne für jede den PC rebooten zu müssen.
Ich will damit sagen: Ich bin nicht "most desktop" und die Möglichkeit manuell zu trimmen ist sinnvoll und notwendig.
Ganz grundsätzlich würde ich dem Nutzer so wenig Berechtigungen wie möglich geben. Dies ist ein weit verbreiteter und einfach zu befolgender Grundsatz.
Und ich finde es auch wichtig, dass man eine klare Trennung zwischen Nutzeraktionen und Systemaktionen hat.
Ob durch das SUID-Bit eine Gefahr besteht oder nicht, ist etwas schwierig abzuschätzen. Es ist allerdings so, dass ein Angreifer relativ leicht nach Befehlen mit dem gesetzten SUID-Bit suchen und sich dann Angriffe überlegen kann.
Deshalb fragte ich auch nach der Relevanz:
Dass man nach einem gesetzten SUID-Bit suchen kann, wusste ich nicht. Aber dazu musst der Angreifer zuerst aufs System und dann muss er auch tatsächlich etwas finden, dass sich mit fstrim (nur dafür fehlt mir noch eine Lösung: s. o.) anstellen lässt. - Wie wahrscheinlich ist das bei Privatpersonen, deren Internetverbindung keine eingehenden Verbindungen zulässt und die z. B. mit Raubkopien, usw. nichts am Hut haben?
Freundliche Grüße,
Andreas