Du bist nicht angemeldet.

#1 22.05.2021 15:39:52

Caramon2
Mitglied

Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Hallo.

Ich habe das in meiner /etc/rc.local (um es wieder zu setzen, wenn es durch eine Aktualisierung verloren ging):

chmod +s /usr/bin/dmesg
chmod +s /usr/bin/ddcutil
chmod +s /usr/bin/fstrim

Damit ich die Befehle als normaler Nutzer nutzen kann:

Win+D ist   "exo-open --launch TerminalEmulator "dmesg -w""
Win+Shift+D "exo-open --launch TerminalEmulator "dmesg -W""

Mit Win+F1-F4 regle ich die Bildschirmhelligkeit: "ddcutil setvcp 10 [Helligkeit]" (0, 20, 50, 100 - auf meinem IPS-TFT am gleichmäßigsten)

fstrim nutze ich als "Benutzerdefinierte Aktion" in Thunar: RMB/Trimmen (für externe SSDs oder Partitionen anderer Installationen, wenn ich dort etwas größeres "von außen" geändert habe)


Entstehen dadurch relevante Sicherheitsrisiken?

Falls ja: In welcher Form und wie kann ich das dann anders lösen?


Bzgl. "ddcutil" kann ich "chmod 666 /dev/i2c-*" in die rc.local setzen, aber für die anderen Befehle bin ich nur auf die Möglichkeit gestoßen, /etc/sudoers entsprechend anzupassen: Da 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.

Das betrifft ausschließlich die obigen Befehle.

Z. B. würde ich "rm" natürlich weder ein +s geben, noch per sudoers "freischalten" wollen.

Gruß,

Andreas

Offline

#2 22.05.2021 17:30:31

frostschutz
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

dmesg kannst du freischalten (kernel.dmesg_restrict o.ä.), beim Rest vielleicht besser, wenn normale User das nicht können...

Offline

#3 22.05.2021 19:40:26

GerBra
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Caramon2 schrieb:

Da 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¹.

Und BTW: 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.
Mit systemd wären wohl die systemd-tmpfiles der "passende"² Ersatz, siehe:
https://wiki.archlinux.org/title/System … rary_files


¹ Ich erkläre sudo meist immer so: Ein Tool um bestimmten Usern/Gruppen/Vorgängen evtl. nötige Root-Rechte selektiv ***einzuschränken***. Das macht das Gute an sudo IMHO deutlicher.

² Nun ja... Andere Geschichte...

Offline

#4 23.05.2021 11:37:08

Gerry_Ghetto
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Zu dmesg: https://bbs.archlinux.org/viewtopic.php?id=262222 erklärt ganz gut, welche Möglichkeiten du hast. Ich persönlich würde auf journalctl umsteigen.

Zu ddcutil: Kenne ich nicht.

Zu 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. 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.

Du könntest spezialisierte systemd Service Units schreiben und sie dann bei Bedarf starten.

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.

Offline

#5 23.05.2021 15:22:42

Caramon2
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

frostschutz schrieb:

dmesg 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 schrieb:
Caramon2 schrieb:

Da 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 schrieb:

Zu 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

Beitrag geändert von Caramon2 (23.05.2021 15:26:48)

Offline

#6 23.05.2021 15:41:28

frostschutz
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Caramon2 schrieb:

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.

Die Gruppe disk wird für fstrim wahrscheinlich keinen Unterschied machen.

Aber jeder Benutzer der in der Gruppe disk ist, kann am Dateisystem vorbei, die Dateisystemrechte ignorierend, alle Daten lesen u. schreiben. Ein solcher Nutzer ist damit effektiv root. Mit anderen Worten, das macht man auf gar keinen Fall.

fstrim hat konkrete Auswirkungen aufs Dateisystem (alle gelöschten Dateien sind spätestens dann wirklich weg, keine Datenrettung möglich). Es gibt schlichtweg keinen Grund für einen normalen User das jemals auszuführen.

Überhaupt wird unter Linux übertrieben viel, vorschnell, ungefragt ein TRIM ausgeführt.

Caramon2 schrieb:

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.

Wenn es um große Datenmengen geht, macht es eigentlich keinen Unterschied.

Write Amplification hast du dann, wenn du eine Winz-Datei schreibst und extra für diese kleine Datei dann ein großer Block (mit eigentlich schon gelöschten Daten) rumkopiert werden muss.

Wenn du große Datenmengen auf einmal schreibst, findet diese unnötige Kopie eigentlich nicht statt, es wird dann ohnehin der gesamte Block mit neuen Daten befüllt.



Allgemein gehen sehr viele Sicherheitslücken auf das SUID-Bit zurück, auch für Binaries die eigentlich gerade darauf ausgelegt waren, mit suid zu arbeiten. Selbst bei sudo ist erst dieses Jahr wieder so eine Lücke gefunden worden. Ein Risiko ist da immer vorhanden.

Du kannst es natürlich trotzdem so machen, ist dann deine Sache. Am Ende ist auf einem lokalen System auf dem ohnehin nur du selbst unterwegs bist, vieles möglich...

Ich mache das ja auch so: ich habe mitigations=off weil mir Spectre & Co. auf dem eigenen System völlig wurst ist. Aber man kann sich mit sowas auch auf dünnem Eis bewegen, muss jeder selber wissen.

Beitrag geändert von frostschutz (23.05.2021 15:56:23)

Offline

#7 23.05.2021 17:43:19

Caramon2
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

frostschutz schrieb:

Die Gruppe disk wird für fstrim wahrscheinlich keinen Unterschied machen.

Ne, so von sich aus nicht. Ich dachte nur, man könnte das evtl. erweitern, oder eben z. B. eine fstrim-Gruppe erstellen, die das ermöglicht.

Aber jeder Benutzer der in der Gruppe disk ist, kann am Dateisystem vorbei, die Dateisystemrechte ignorierend, alle Daten lesen u. schreiben. Ein solcher Nutzer ist damit effektiv root. Mit anderen Worten, das macht man auf gar keinen Fall.

Aua! Das erschreckt mich jetzt etwas: Darüber habe ich mir noch nie Gedanken gemacht, oder etwas dazu gelesen.

Ich nutze "disk" schon seit Jahren, weil sich dann Laufwerke direkt in eine VM einbinden lassen: Z. B. installiere ich Betriebssysteme, indem ich das ISO in KVM boote und daraus dann direkt auf den Datenträger installiere. - Dann brauche ich das ISO nicht erst auf einen Stick kopieren.

Wenn du große Datenmengen auf einmal schreibst, findet diese unnötige Kopie eigentlich nicht statt, es wird dann ohnehin der gesamte Block mit neuen Daten befüllt.

Ich lösche die Dateien gleich wieder: Das ist nur ein Zwischenschritt. Wenn ist das der SSD dann nicht sage, denkt sie der Speicherbereich wäre immer noch belegt: Mit allen Nachteilen, die das hat.

Allgemein gehen sehr viele Sicherheitslücken auf das SUID-Bit zurück, auch für Binaries die eigentlich gerade darauf ausgelegt waren, mit suid zu arbeiten. Selbst bei sudo ist erst dieses Jahr wieder so eine Lücke gefunden worden. Ein Risiko ist da immer vorhanden.

Du kannst es natürlich trotzdem so machen, ist dann deine Sache. Am Ende ist auf einem lokalen System auf dem ohnehin nur du selbst unterwegs bist, vieles möglich...

Richtig: Für mich sehe ich da auch kein Problem (einschließlich "disk"), aber bei anderen werde ich darauf verzichten und ihnen nur ddcutil einrichten.

Ich mache das ja auch so: ich habe mitigations=off weil mir Spectre & Co. auf dem eigenen System völlig wurst ist.

Das hatte ich auch mal getestet, aber auf meinen Fx8350 konnte ich keinen relevanten Unterschied feststellen. Nur auf fs-uae hatte das größere Auswirkungen, aber da ich den nur aus sentimentalen Gründen für meine alte Kfz-Kosten-Verwaltung nutze (also nichts rechenintensives), war auch das nicht relevant.

Offline

#8 24.05.2021 11:57:10

Gerry_Ghetto
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Caramon2 schrieb:
Gerry_Ghetto schrieb:

Zu 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.

Timer kann man nicht nur zu "Kalender"-Zeiten definieren, sondern auch zum Beispiel bei jedem Boot.

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.

Mir tut es leid, dass du absichtlich im falschen Forum um Hilfe bittest. Dadurch hast du ja absichtlich eine unnötige Diskussion gestartet.

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?

Ja, ein Angreifer müsste aufs System kommen. Einmal auf dem System, kann er nach SUID-Anwendungen suchen mit normalen Nutzerrechten und sie dann gegebenenfalls zur Rechteerweiterung nutzen.
Das Netzwerk ist übrigens nicht das einzige Einfallstor. Du selbst beschreibst ja, dass du mehrere Disks anschliesst.

Dass du keine eingehenden Verbindungen zulässt, ist zwar gut, aber nicht zwingend ausreichend. Wenn du im Internet herumsurfst, öffnest du die Verbindung von innen. Da kann immer etwas passieren.
Möglicherweise ist dein Computer auch nicht das einzige Gerät im Netzwerk und ein Angreifer bekommt dann mittels "lateral movement" Zugriff.
Überwachst du denn auch ausgehende Verbindungen? Angreifer versuchen üblicherweise eine Reverse-Shell zu starten.

Möglichkeiten, eine SUID-Anwendung auszunutzen gibt es ja viele: Ein ROP-Gadget, $LD_PRELOAD, eine Shell-Datei, die ausgeführt wird usw.

Bezüglich Wahrscheinlichkeit: Ich bezweifle, dass Angriffe auf private Rechner statistisch erfasst werden. Kriminelle, die Geld mit ihren Aktivitäten verdienen müssen, konzentrieren sich eher weniger auf Privatpersonen. Es sei denn, es sind Schlüsselpersonen in einer Unternehmung, die das eigentliche Angriffsziel darstellt.
Auf der anderen Seite sind Privatrechner eher für Botnetze interessant, da sie tendenziell weniger gut geschützt sind und einfacher gekapert werden können.

Offline

#9 24.05.2021 13:36:33

Caramon2
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Gerry_Ghetto schrieb:

Timer kann man nicht nur zu "Kalender"-Zeiten definieren, sondern auch zum Beispiel bei jedem Boot.

Beim booten sind die betreffenden Laufwerke/Partition auch nicht angeschlossen und eingehängt, sondern nur bei Bedarf und dann auch nur so lange wie ich sie brauche.

Praktikabel wäre höchstens, wenn sie beim aushängen automatisch getrimmt werden: Das wäre der richtige Zeitpunkt, da alle Arbeiten darauf abgeschlossen sind und nichts mehr geändert wird.

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.

Mir tut es leid, dass du absichtlich im falschen Forum um Hilfe bittest. Dadurch hast du ja absichtlich eine unnötige Diskussion gestartet.

Leider gibt es kein deutsches Artix-Forum und ich hatte bzgl. Artix gefragt, bevor ich mich hier angemeldet habe.

Auf jeden Fall danke für die Erklärungen bzgl. SUID: Da war ich echt viel zu blauäugig. Ich werde das höchstens noch auf meinen Systemen einsetzten und das wesentlich überlegter.

Da ich kein Festnetz habe und nur bei Bedarf möglichst kurz übers Handy online gehe (der AP geht ziemlich auf den Akku), wäre es sehr überraschend, wenn genau dann was passiert. Ein Netzwerk habe ich nicht, die SSD ist Opal-Verschlüsselt und der PC üblicherweise (auch jetzt) aus.

Beitrag geändert von Caramon2 (24.05.2021 13:38:46)

Offline

#10 25.05.2021 17:25:52

Caramon2
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Hallo.

Alle "chmod +s" sind jetzt weg (vorher mit "-s" durchlaufen lassen) und bis auf ddcutil in sudoers mit nopasswd.

Vorläufig einschließlich dmesg, da ein erster Versuch per Grub (try&error) nicht funktioniert hat:

GRUB_CMDLINE_LINUX_DEFAULT="quiet kernel.dmesg_restrict=0"

Da muss ich mich also doch erst einlesen.

Bleibt nur noch die Frage, was ich mit der Gruppe "disk" mache: Das brauche ich sehr oft, um Laufwerke direkt in KVM einzubinden.

Alternativ könnte ich höchstens qemu-system-x86_64 per sudo starten. Da ich es aber ständig brauche, "müsste" ich es auch in sudoers eintragen.

Was davon ist weniger dämlich?

Zu "disk" gehöre ich zwar immer, aber was lässt sich mit einem per sudo ohne Passwort startbaren qemu alles anstellen?

Bzw. was kann ein per sudo (egal ob mit/ohne Passwortabfrage) gestarteter qemu alles beschädigen, wenn ich ihn nutze, aber irgendwas schief läuft?

Also mir erscheint "disk" bedeutend besser: Das hat hier noch nie zu Problemen geführt, während ich ein ziemlich mulmiges Gefühl dabei hätte, qemu ständig per sudo zu nutzen.

Was meint ihr?

Relevant ist vielleicht noch, dass ich bis auf mein VM-XP (natürlich ohne Internetverbindung) KVM nur für Linux-Distributionen nutze: Um mir Livesysteme anzusehen, zur Installation, um es schnell zu booten, um etwas nachzusehen (ohne dafür erst alles abbrechen zu müssen, um den PC zu rebootem), usw. - Wobei ich denen auch nur dann Internetzugriff gebe, wenn ich den wirklich benötige.

Btw: Das dürfte meine letzte offene Frage zu diesem Thema sein.

Nochmal danke für die Hilfe und nochmal Entschuldigung bzgl. Artix: Ich hatte einfach Angst, dass dieser Thread dann genauso zerredet wird, wie ich es in vielen anderen Foren schon gesehen habe. Das wird nicht wieder vorkommen.

Noch einen schönen Abend.

Andreas

P. S.: Sowas mache ich z. B. mit KVM: VM-Installation.mkv

Das war offline, weshalb es zu Anfang so lange dauert. - Währenddessen hat mir übrigens das Kabel der Maus geärgert. ;-)

Offline

#11 26.05.2021 13:14:02

Gerry_Ghetto
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Zu Grub: Ich gehe davon aus, dass du die grub.cfg neu erstellt hast mittels grub-mkconfig.

Zu sudo: Prinzipiell solltest du QEMU nur mit normalen Nutzerrechten laufen lassen. Ich habe vor Jahren mal mit nacktem QEMU herumexperimentiert, um Secure Boot zu testen. Dabei habe ich ein Skript erstellt, um die verschiedenen Funktionalitäten auszuwählen. Alles funktionierte ohne sudo, da alles nötige in meinem Benutzerverzeichnis gespeichert war. Ich gehe davon aus, dass du sudo benutzen möchtest, weil dir der Zugriff auf gewisse Dateien fehlt. Du solltest versuchen, das Problem zu lösen (Dateien am "richtigen" Ort speichern) und nicht mit dem Holzhammer arbeiten. Mit sudo hättest du dann nicht nur Zugriff auf die benötigten Dateien, sondern auch auf alles andere. Ein Ausbrechen aus der VM wäre dann besonders fatal.

Zur Gruppe "disk": Wenn ich zwingend darauf angewiesen wäre, in der Gruppe "disk" zu sein, dann würde ich es auch so machen. Allerdings musst du dir darüber im Klaren sein, dass dann jeder Benutzer (sprich "auch Angreifer") in der Lage ist, eine virtuelle Maschine mit einem beliebigen Linux zu starten. Dabei kann er natürlich auch eine vorhandene Partition in die VM hineinmounten und dort als VM-root arbeiten. (Details siehe https://wiki.archlinux.org/title/QEMU#U … isk_image)
Ich habe das zwar noch nie mit QEMU ausprobiert, aber vor Jahren mal mit Docker.

Die meisten Probleme kannst du umgehen, in dem du konsequent zwischen Systemdaten und Nutzerdaten unterscheidest und sie auch konsequent getrennt hältst.

Wenn du dein System dann noch weiter absichern möchtest, müsstest du dich in AppArmor oder SELinux einlesen. Aber das ist dann ein beträchtlicher Aufwand und gehört nicht mehr zu den "Hausmitteln".

Offline

#12 27.05.2021 14:02:38

Caramon2
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Gerry_Ghetto schrieb:

Zu Grub: Ich gehe davon aus, dass du die grub.cfg neu erstellt hast mittels grub-mkconfig.

Als es dann nicht funktioniert hat, habe ich sogar in /etc/grub/grub.cfg nachgesehen, ob es wirklich übernommen wurde. - Ich werde mir das irgendwann mal in Ruhe ansehen. Das hat keine Priorität, da es per sudoers ja funktioniert.

Zu Qemu:

Ich muss damit nicht auf besondere Dateien zugreifen, sondern es per sudo zu starten wäre offenbar die einzige Alternative für mich, nicht zur Gruppe "disk" zu gehören:

"disk" brauche ich ausschließlich dafür, um aus der VM heraus auf Laufwerke zugreifen zu können:

Wie oben geschrieben z. B. um ein Livesystem (iso) in der VM zu booten und von dort aus direkt auf dem Laufwerk zu installieren, so dass man es anschließend nativ booten kann *), es also "wirklich" auf dem PC installiert ist. Aber auch um ggfs. aus dem VM-XP heraus ntfs-Laufwerke per chkdsk prüfen zu können, oder Windows-Installationen per BootIce zu reparieren. Ich teste damit frisch erstellte Livesystem (indbes. per YUMI, weil ich dessen Menü-Konfiguration ziemlich unbrauchbar finde und es für meinen Bedarf anpasse) und noch vieles andere. - Dafür müsste ich einen eigenen Thread erstellen. Schon wegen der ganzen Skipts, die ich mir dafür gebastelt habe.

---
*) also nicht in einer Image-Datei wie im Video (dafür bräuchte man kein "disk"): Das hatte ich neulich für einen Bekannten aufgenommen, um ihm (erstens) zu zeigen, dass es keine Raketenwissenschaft ist, eine Linux-Distributionen zu installieren und er (zweitens) sieht, wie einfach man unter Linux eine VM installieren kann: Statt sich aufwändig durch das vBox-GUI zu klicken, einfach Rechtsklick aufs iso, zack und fertig.
---

Natürlich funktionieren mit "disk" auch "lustige" Sachen wie "ls > /dev/sdX" (nicht ausprobieren!), aber ich weiß dass ich da aufpassen muss. - Ich aber nicht was alles passieren kann, wenn ein per sudo gestartetes qemu z. B. aufgrund eines Bug plötzlich "durchdreht".

Angreifer schließe ich für mein System praktisch aus, da ich mit dem PC oft tagelang nicht online bin und wenn doch mal, dann eben möglichst kurz, da mir der AP des Handys zu sehr auf den Akku geht. - Der Browser (Opera) wird z. B. fast häufiger aktualisiert, als dass ich ihn nutze: Primär surfe und maile ich mit dem Handy.

Auf anderen PCs hatte ich "disk" (mangels Bedarf) sowieso nicht eingerichtet. Das werde ich jetzt natürlich erst recht nicht mehr machen.

Offline

#13 29.05.2021 13:15:45

Caramon2
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Ich hatte gerade eine Idee:

Das Problem ist: Ich muss Laufwerke direkt in die VM einbinden können, was aber meines Wissens nur per sudo oder der Gruppe "disk" funktioniert.

sudo hätte den Vorteil, dass es nur für die jeweilige Nutzungsdauer auf qemu beschränkt ist, während man zu "disk" permanent gehört und jede Anwendung es nutzen kann. Andererseits ist mir sudo zu mächtig, um qemu quasi standardmäßig damit zu starten.

Optimal wäre es, wenn ich nur qemu während ich es nutze, zur Gruppe "disk" hinzufügen könnte. - Also sozusagen statt "sudo qemu" eben "diskdo qemu": Damit könnte es alles was ich brauche und ich müsste nicht permanent zur Gruppe "disk" gehören.

Das ist aber auf die Art nicht möglich, oder?

Meine Idee ist jetzt: Ich lege mir einen Nutzer "kvmuser" an, der statt mir zur Gruppe "disk" gehört und starte qemu dann per "su" als "kvmuser": Dann würde qemu praktisch nur zur Laufzeit zu "disk" gehören, oder?

Nur wie mache ich das? Vor allem ohne dass eine Passwortabfrage nötig ist: Ich möchte es wie bisher einfach per Win+V starten können.

Wie oben gesagt, geht es mir dabei weniger um potentielle Angreifer, als um die möglichen Auswirkungen von Bugs oder Fehlbedienung einzuschränken. - Also das "kvmuser"-Passwort aus einer Textdatei zu holen wäre eine Option, falls das mit "su" möglich ist: Die manpage hilft mir da leider nicht.

Offline

#14 29.05.2021 13:28:35

frostschutz
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Und wenn du dir einen ganz bestimmten Qemu-Befehl in ein Startscript schreibst und nur dieses mit sudo ausführst?

Du kannst vielleicht auch mit einer udev Regel nur ein ganz bestimmtes Device für dich schreibbar machen (gehört dann user:disk statt root:disk).

Qemu als User arbeitet eben oft auch mit einfachen Image-Dateien so daß dort nur die normalen Benutzer-Zugriffsrechte wei bei jeder anderen Datei greifen. Sobald man mit Qemu direkt auf die Hardware geht ist es halt ein wenig anders.

Ich installiere Windows & Co ja auch mit Qemu (sonst müsste ich umständlich Platten abklemmen), aber dann hab ich auch kein Problem damit, qemu vorübergehend als Root laufen zu lassen. sudo ist bei mir eh nicht installiert, wenn man als root mal was machen muss dann ist das halt so und das ist dann auch okay.

Offline

#15 29.05.2021 17:49:10

GerBra
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

Caramon2 schrieb:

Bleibt nur noch die Frage, was ich mit der Gruppe "disk" mache: Das brauche ich sehr oft, um Laufwerke direkt in KVM einzubinden.

Abseits der Überlegungen, an denen ihr gerade "dran" seid:

Sind die "Laufwerke" (Devices), die du für qemu-Aktionen brauchst, fest im Rechner verbaut und/oder Wechsellaufwerke?
Sind diese Devices unabhängig vom Linux-Rootdevice bzw. sonstigen Partitionen, die für dein Linux-System genutzt werden?

Was ist das "Blöde an der disk-Gruppe, warum man diese vermeiden sollte"?
Alle Blockdevices für Festplatten gehören per default eben root:disk. Dein qemu-User benötigt z.B. eigentlich "nur" rw-Zugriff auf /dev/sdb und /dev/sdd1.
Diesen User nun in disk reinzupacken ermöglicht zum einen - wie gewollt - den direkten - raw - Zugriff auf eben sdb und sdd1.

Aber ebenso den Zugriff auf alle anderen Platten/Partitionen (Systemplatte, $HOMES, etc.) - obwohl dieser Zugriff garnicht erforderlich wäre für die qemu-Aufgabenstellung.
Spätestens jetzt sollten beim Admin die Alarmglocken läuten: Eine Aufgabenstellung zu lösen, indem die notwendige Aktion dem User mehr "Rechte" gibt als dafür eigentlich notwendig ist i.d.R. "falsch gelöst".

Ich glaube dir, daß Du bisher mit disk "verantwortlich" umgegangen bist, und eben nichts "Dummes", "Willkürliches" mit *Deinem" Rechner angestellt hast. Aber Fehler z.B. passieren jedem: Ein auf das falsche Device angesetzte dd oder fdisk oder qemu, und schon wäre z.B. dein System-Device /dev/sda "hinüber" obwohl du eigentlich auf /dev/sdb agieren wolltest. Als Mitglied in der Gruppe disk könnte das deinem User "ohne Nachfrage" passieren. Ideal wäre doch ein Mechanismus, der deinen User diese "Fehler" *nur* auf ausgewählten Devices machen ließe...
Ebenso kann man sich so einem Problem "nähern" wenn man sich mal fragt: Was, wenn ich Admin an einem "Fremdrechner" wäre und müßte für "User Müller" die Aufgabenstellung lösen? Würde ich Müller in die disk-Gruppe stecken? Wäre ja fast schon ein Kündigungsgrund für mich als Admin ;-)

Gibt es also andere Möglichkeiten, um dem User (dir also) die Aufgabe zu ermöglichen, ohne dem User mehr Rechte einzuräumen als er wirklich braucht?
IMHO ja, ähnlich zur ursprünglichen Frage setuid-Bit vs. sudo.
Mittels sudo konntest du *deinem* User Root-Rechte für dedizierte Aufgaben erteilen, während ein setuid eben für Hinz und Kunz gegolten hätte. Ebenso hast du diese Root-Rechte deinem User *gezielt* nur für bestimmte Programme erteilt - und eben *nicht* den User "bequemerweise" in die wheel-Gruppe gepackt, wo er *alle* Aktionen mit Root-Rechten hätte ausführen können. Sudo "richtig und überlegt" eingesetzt hat also hier IMHO für mehr Sicherheit gesorgt als die erste Idee.

Zur qemu-Aufgabenstellung fielen mir noch zwei Ansätze ein, um z.B. die "globale disk-Gruppenorgie"<g> zu umgehen:
a) Posix ACLs
b) mit (anderen) Gruppen arbeiten

Vorausgesetzt, dein User bräuchte zum Arbeiten mit qemu wirklich nur (raw)-Zugriff auf /dev/sdb und /dev/sdd1. Nur auf diese Platte(sdb) und diese Partition(sdd1) müßte dein User direkten rw-Zugriff haben. Und eben nicht auch auf alle anderen Devices (sda mit dem System z.B.).

Möglichkeit mittels a) ACLs:
ACLs ermöglichen weitere Rechtevergaben an "Dateien" abseits der Unix-"User/Gruppen"-Rechtevergabe. So ist es z.B. möglich daß /dev/sdb weiterhin root:disk gehört mit rw-rw---- und das der User foo auch ein rw- Recht an /dev/sdb bekommt. Zu ACLs siehe z.B. man acl und:
https://wiki.archlinux.org/title/Access_Control_Lists
Für /dev/sdb würde das z.B. bedeuten:

# getfacl /dev/sdb

# file: dev/sdb
# owner: root
# group: disk
user::rw-
group::rw-
other::---

Das widerspiegelt die *normalen" Unix-Berechtigungen root:disk rw-rw---- für /dev/sdb. Weiter ACLs sind nicht gesetzt.
Jetzt gewähren wir gezielt dem User foo zusätzliche Rechte:

# setfacl -m u:foo:rw /dev/sdb
# getfacl /dev/sdb

# file: dev/sdb
# owner: root
# group: disk
user::rw-
user:foo:rw-
group::---
mask::rw-
other::---

Auf /dev/sdb haben nun weiterhin root und Mitglieder in disk rw-Zugriff, aber auch der User foo. foo erhält dadurch aber nur die wirklichen notwendigen Rechte für bestimmte Devices, nicht unnötigerweise für alle.
ACLs bleiben im Normalfall im Dateisystem gespeichert wenn einmal gesetzt. Da /dev ja ein volatiles Dateisystem ist, wird nichts "gespeichert" sondern bei einem Reboot mit Default-Werten reinitialisiert. Deshalb müßten die ACLs bei jedem Systemstart entsprechend gesetzt werden. Der momentan beste Weg sind systemd-tmpfiles.
Dazu würde z.B. eine Konfiguration in /etc/tmpfiles.d/qemu-disk-device-acls.conf angelegt:

# Gewährt dem User foo rw-Rechte an Devices für qemu-Zugriffe
#
a+ /dev/sdb  - - - - u:foo:rw
a+ /dev/sdd1 - - - - u:foo:rw

Diese Konfiguration wird von systemd nun bei jedem Systemstart entsprechend gesetzt.

Möglichkeit mittels b) andere Gruppen:
//Edit: Mir fehlt aktuell die Zeit, daß näher auszuführen, ich hole das nach. Nur soviel mein Gedanke:
Man würde beim Beispiel /dev/sdb und /dev/sdd1 gezielt eben diese Devices eine andere Gruppe als disk geben. Z.B. die benannte Usergruppe des Users (root:foo z.B.), oder eine neu Gruppe. So könnte foo gezielt über die normalen Unix-Rechte den nötigen rw-Zugriff erhalten, gleichzeitig wäre verhindert daß dieser auch auf unnötige Devices ebenfalls Zugriff hätte, diese würden root:disk bleiben.

Soweit meine Gedanken...

Beitrag geändert von GerBra (29.05.2021 17:54:56)

Offline

#16 29.05.2021 19:30:04

Caramon2
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

GerBra schrieb:

Alle Blockdevices für Festplatten gehören per default eben root:disk. Dein qemu-User benötigt z.B. eigentlich "nur" rw-Zugriff auf /dev/sdb und /dev/sdd1.
Diesen User nun in disk reinzupacken ermöglicht zum einen - wie gewollt - den direkten - raw - Zugriff auf eben sdb und sdd1.

Aber ebenso den Zugriff auf alle anderen Platten/Partitionen (Systemplatte, $HOMES, etc.) - obwohl dieser Zugriff garnicht erforderlich wäre für die qemu-Aufgabenstellung.
Spätestens jetzt sollten beim Admin die Alarmglocken läuten: Eine Aufgabenstellung zu lösen, indem die notwendige Aktion dem User mehr "Rechte" gibt als dafür eigentlich notwendig ist i.d.R. "falsch gelöst".

Du bringst es auf den Punkt:

Wenn ich mit mit der VM auf z. B. /dev/sd{b,c} zugreifen möchte, soll qemu möglichst auch nur auf diese Laufwerke zugreifen dürfen und das auch nur solange ich es dafür nutze.

Da ich lange XP genutzt habe und dort natürlich als Admin unterwegs war (ich wusste es nicht besser), sind die Möglichkeiten von "disk" nichts besonderes für mich, weshalb ich mir vor dem Hinweis von Frostschutz nie Gedanken darüber gemacht habe: Man kann eben einfach eine Platte löschen und muss aufpassen, wie schon immer…

Als "Gegenmaßnahme" kommt als erstes meine Swap, so dass ich, wenn mehr als MBR und Partitionstabelle überschrieben wird, sie nur neu formatieren muss: Die noch nicht überschriebenen Partitionen sind ja wieder da, wenn ich die Partitionstabelle wiederherstelle. *)

Btw: Bei LinuxMint (das konnte ich mit allen getesten Ubuntus reproduzieren) war die Gefahr besonders groß, da dort gerne die Laufwerke gewürfelt werden: Z. B. wenn ich bei angeschlossener Sicherungsplatte (USB3) reboote, war die oft (aber nicht immer: es wurde wirklich "gewürfelt") /dev/sda/ und die anderen Laufwerke entsprechend verschoben: Wenn man dann z. B. einen vorherigen "dd"-Befehl nochmal ausführt, ist man hinterher schlauer und erstellt die Swap als erstes. ;-)

Den Rest von dem, was du geschrieben hast, muss ich mir in Ruhe durchlesen. ACLs sagen mir z. B. noch gar nichts.

@Frostschutz: Ähnlich wie udev: Damit wollte ich mich schon immer mal beschäftigen, aber bin noch nicht dazu gekommen.


*) Außerdem sichere ich oft und auf mehrere ext. Platten: Eine bei meiner Mutter, da ich in einer Dachwohnung wohne und es vor einigen Jahren kaum 20 km vor hier so stark gestürmt hat, dass mehrere Häuser abgedeckt wurden.

Offline

#17 29.05.2021 19:56:03

frostschutz
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

in der qemu manpage gibts auch noch das hier:

       -runas user
              Immediately before starting guest execution, drop root
              privileges, switching to the specified user.

man kann qemu also als root starten, dann macht qemu die angegeben laufwerke auf, und dann werden die privileges gedroppt... so daß nicht im laufenden Betrieb noch weitere Laufwerke (über Qemu Konsole/Monitor/etc.) aufgemacht werden können.

das wär dann sowas für das sudo script

Offline

#18 30.05.2021 12:56:42

Caramon2
Mitglied

Re: Alternativen zu chmod +s bei dmesg, ddcutil und fstrim?

frostschutz schrieb:

man kann qemu also als root starten, dann macht qemu die angegeben laufwerke auf, und dann werden die privileges gedroppt...

Genau das was ich suche: Einfach und effizient. :-)

Vermutlich extra für solche Sachen gedacht.

Ich habe mich aus "disk" entfernt, /usr/bin/qemu-system-x86_64 in sudoers eingetragen und mich kurz abgemeldet, damit es übernommen wird.

Dann habe ich es mit meinem "vms"-Skript getestet ("s" für snapshot (s. u.) - das nutze ich, wenn ich z. B. nur etwas nachsehen, oder nach Bastelarbeiten gefahrlos auf Bootfähigkeit testen möchte): "vms b", um die Installation auf der zweiten SSD zu booten.
(es sind beliebig viele Laufwerke möglich, z. B. "vms d b j", wobei vom zuerst angegebenen gebootet wird)

Zuerst ohne "sudo", was wie erwartet eine Fehlermeldung bzgl. /dev/sdb ergab (sonst hätte ich irgendwas übersehen), dann mit "sudo" und es funktionierte wie gewünscht:

#!/bin/bash
if [ $# == 0 ];then echo "vms /dev/sd? …";exit;fi
cl="sudo qemu-system-x86_64 -runas $USER -sdl -enable-kvm -nodefaults -cpu host -smp cores=2 -m 2G -vga virtio"
while [ $# -gt 0 ]
do cl=$cl" -drive file=/dev/sd$1,if=virtio,snapshot=on,format=raw"
shift;done
$cl

(ich weiß: grauenhaft strukturiert, aber ich komme damit besser zurecht, als wäre es mit diesen ganzen Einrückungen "verschandelt")

"snapshot=on" bewirkt, dass Änderungen im nur im RAM gepuffert aber nicht wirklich geschrieben werden
"-nodefaults" nutze ich, damit keine Internetverbindung eingerichtet wird

2 Cores und 2 GiB RAM reichen normalerweise und es soll z. B. auch beim Nachbarn (2,7 GHz K9 mit 4 GiB RAM) gut funktionieren.

@GerBra: Die ACLs werde ich mir auf jeden Fall noch ansehen, da man das ja immer mal brauchen kann.

Ich hatte übrigens noch einen anderen Ansatzpunkt: Man könnte statt dem Nutzer auch der Gruppe "kvm" für die benötigten Laufwerke "rw" geben, da man bzgl. KVM ja sowieso dazu gehören soll. Dann ist es egal welchen Usernamen man hat: Ich möchte es möglichst allgemeingültig halten: Keep it simple. ;-)

Dass es nicht dauerhaft gespeichert wird ist in diesem Fall ja gewünscht: Nach dem beenden von qemu würde ich es gleich wieder löschen, aber falls es z. B. einen Stromausfall gibt oder ein Hardreset nötig ist, würde es ansonsten gesetzt bleiben.

Offline

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums