doas statt sudo

[mcb]

Es gibt jetzt doas in testing:

https://tracker.debian.org/pkg/doas



Muß man aber per Hand konfigurieren:

https://wiki.gentoo.org/wiki/Doas

Mehr habe ich auf die schnelle nicht gefunden. Hat es schon jemand am laufen?

[willy4711]

doas ---> Differenzielle optische Absorptionsspektroskopie

Halte ich für anwendbarer als irgendwelche sudo Verbiegungen. Wobei sudo eh ziemlich überflüssig ist

Und weg

[DeletedUserReAsG]

Gut. Angenommen, ich nutze sudo auf die Art, wie’s ursprünglich gedacht war: ich gebe definierten Usern die Möglichkeit, definierte Aktionen mit den Rechten eines definierten Users auszuführen, und protokolliere das: welches ist das Argument, warum ich mir doas anschauen sollte?

[mcb]

Gute Frage:

- weniger Code -> weniger Angriffsfläche
- einfacher zu konfigurieren

Theroretisch zumindest ... der Port ist auch in keinster weise fertig. #983505 - doas persist option does not work - Debian Bug report logs: https://bugs.debian.org/cgi-bin/bugrepo ... bug=983505

Könnte ich nicht z.B. meinem Hauptbenutzer (also mir) z.B. nur apt erlauben ? mit der config ? Das wäre schon top.

[mcb]

Wow ! Works

Code: Alles auswählen

marc@mb:~$ apt policy doas
doas:
  Installed: 6.8.1-2
  Candidate: 6.8.1-2
  Version table:
 *** 6.8.1-2 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
          1 http://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
marc@mb:~$ 

Code: Alles auswählen

marc@mb:~$ cat /etc/doas.conf 
permit nopass marc cmd apt
marc@mb:~$ 

Code: Alles auswählen

marc@mb:~$ doas fdisk
doas: Operation not permitted
marc@mb:~$ doas apt update
Hit:1 http://ftp.nl.debian.org/debian-security bullseye-security InRelease
Hit:2 http://deb.debian.org/debian bullseye InRelease
Hit:3 http://ftp.nl.debian.org/debian bullseye-backports InRelease
Hit:4 http://deb.debian.org/debian bullseye-updates InRelease
Hit:5 http://deb.debian.org/debian unstable InRelease
Hit:6 http://deb.debian.org/debian experimental InRelease
^CInterrupt             
marc@mb:~$ 

Kann man bestimmt viel feiner und ausgefeilter konfigurieren, aber mir gefällt es gut.

[mcb]

So die erste "sinvolle" Config - das hat mich zu Tode genervt mit dem Passwort:

Code: Alles auswählen

root@mb291:/home/marc# cat /etc/doas.conf
permit nopass marc cmd shutdown
root@mb291:/home/marc# 

[DeletedUserReAsG]

das hat mich zu Tode genervt mit dem Passwort:

Das mit dem Shutdown erlauben doch eigentlich alle aktuellen Distributionen dem User via polkit, solange er lokal eingeloggt und der einzige User ist?

Das mit apt ohne Einschränkungen und ohne Passwort würde ich mir auch nochmal überlegen, und es zumindest auf ›apt update‹ begrenzen: apt kann auch lokale Files installieren und damit hat jeder, der damit beliebige lokale Pakete installieren kann, quasi Rootrechte und damit die Möglichkeit, sich eine Backdoor auf das System zu tun. Falls es sich mit doas nicht so einschränken lässt: mit sudo bekommt man das gut hin … [scnr]

[TRex]

Weniger Code, aber auch weit weniger Augen auf dem Code (als bei sudo). Ich halte mich da mal zurück. Ein paar Minuten Recherche und man versteht auch, was man für das gleiche Ergebnis mit sudo konfigurieren muss.

[mcb]

Ja - alles wahr !

Mit apt war ich schon selbst draufgekommen:

Thinkpad1:

Code: Alles auswählen

permit nopass marc cmd tlp-stat

Ich habe su aber kein sudo -> kann ich mir den Batteriestatus ausgeben lassen ohne Passwort.

Thinkpad2:

Code: Alles auswählen

permit nopass marc cmd shutdown
permit marc cmd apt
permit nopass marc cmd tlp-stat

Ich habe sudo -> shutdown geht jetzt ohne Passwort, doas apt update alternatv zu sudo apt update (beide mit Passwort). Ich bevorzuge sudo su und dann apt u.....

Mal sehen so habe ich erstmal keine Scheunentore eingebaut - die Konfiguration ist aber wirklick "easy". Muß mir nochmal überlegen ob absolute Pfade besser wären ?!?

[DeletedUserReAsG]

Mal sehen so habe ich erstmal keine Scheunentore eingebaut - die Konfiguration ist aber wirklick "easy". Muß mir nochmal überlegen ob absolute Pfade besser wären?¹

Ist auf jeden Fall sinnvoll – so, wie es jetzt ist, könnte sich ein Angreifer möglicherweise einfach eine Datei mit dem Namen erstellen und die mit Rootrechten ausführen.

Und ich würde auch überhaupt nix ganz ohne Passwort ausführen lassen: zumindest das Userpasswort sollte schon bekannt sein. Oft hat es einen Grund, wenn Sachen eigentlich nur als Root ausgführt werden sollen – und dann möchte man die nicht jedem Scriptkid einfach so schenken.



---
¹) Artefakte der fehlfunktionierenden Tastatur entfernt

[mcb]

Na gut - ich finde es immer schön wenn man Auswahl hat.

- für mich ist doas "einfach" zu konfigurieren, meinetwegen auch um temporär etwas zuzulassen
- Rechner #1 ich habe einen root -> sudo und doas sind beide useless
- Rechner #2 ich habe sudo -> doas ist doppelt gemoppelt ...

Am sichersten wäre es auf #1 beide zu entfernen (ev. sind Fehler in den Programmen ...) mein Benutzer ist eh nicht in der Gruppe sudo.
Auf #2 kann ich mit sudo das gl. erreichen - o.k. ...

Sicherheit am PC ...

[mcb]

doas läuft überings auch unter buster! Einfach die Version aus testing/sid installieren. Gerade mal getestet im Linux Subsystem for Windows ... Entspricht aber nicht der "best practice" ...

[mcb]

Es gibt jetzt doas Version 6.8.1-3 und die 'persist option' geht jetzt endlich!

#983505 - doas persist option does not work - Debian Bug report logs
https://bugs.debian.org/cgi-bin/bugrepo ... bug=983505

Man kann das Programm unter bullseye ohne Probleme selbst bauen.

[hikaru]

Auch wenn's schon etwas her ist:

Code: Alles auswählen

permit nopass marc cmd tlp-stat

Ich habe su aber kein sudo -> kann ich mir den Batteriestatus ausgeben lassen ohne Passwort.

Wozu braucht man hier tlp-stat, bzw. warum braucht das zur Ausgabe des Akkustandes root-Rechte, wenn es doch nur Dateien ausliest, die sowieso jeder lesen darf? :

Code: Alles auswählen

$ ls -l /sys/class/power_supply/BAT0/
insgesamt 0
-rw-r--r-- 1 root root 4096 Okt 24 22:20 alarm
-r--r--r-- 1 root root 4096 Okt 24 22:20 capacity
-r--r--r-- 1 root root 4096 Okt 24 22:29 capacity_level
-r--r--r-- 1 root root 4096 Okt 24 22:22 cycle_count
lrwxrwxrwx 1 root root    0 Okt 24 22:29 device -> ../../../PNP0C0A:00
-r--r--r-- 1 root root 4096 Okt 24 22:20 energy_full
-r--r--r-- 1 root root 4096 Okt 24 22:20 energy_full_design
-r--r--r-- 1 root root 4096 Okt 24 22:20 energy_now
-r--r--r-- 1 root root 4096 Okt 24 22:20 manufacturer
-r--r--r-- 1 root root 4096 Okt 24 22:20 model_name
drwxr-xr-x 2 root root    0 Okt 24 22:29 power
-r--r--r-- 1 root root 4096 Okt 24 22:20 power_now
-r--r--r-- 1 root root 4096 Okt 24 22:20 present
-r--r--r-- 1 root root 4096 Okt 24 22:20 serial_number
-r--r--r-- 1 root root 4096 Okt 24 22:20 status
lrwxrwxrwx 1 root root    0 Okt 24 22:20 subsystem -> ../../../../../../../../../class/power_supply
-r--r--r-- 1 root root 4096 Okt 24 22:20 technology
-r--r--r-- 1 root root 4096 Okt 24 22:20 type
-rw-r--r-- 1 root root 4096 Okt 24 22:20 uevent
-r--r--r-- 1 root root 4096 Okt 24 22:20 voltage_min_design
-r--r--r-- 1 root root 4096 Okt 24 22:20 voltage_now

[mcb]

Auch wenn's schon etwas her ist:

Code: Alles auswählen

permit nopass marc cmd tlp-stat

Ich habe su aber kein sudo -> kann ich mir den Batteriestatus ausgeben lassen ohne Passwort.

Wozu braucht man hier tlp-stat, bzw. warum braucht das zur Ausgabe des Akkustandes root-Rechte, wenn es doch nur Dateien ausliest, die sowieso jeder lesen darf? :

Code: Alles auswählen

$ ls -l /sys/class/power_supply/BAT0/
insgesamt 0
-rw-r--r-- 1 root root 4096 Okt 24 22:20 alarm
-r--r--r-- 1 root root 4096 Okt 24 22:20 capacity
-r--r--r-- 1 root root 4096 Okt 24 22:29 capacity_level
-r--r--r-- 1 root root 4096 Okt 24 22:22 cycle_count
lrwxrwxrwx 1 root root    0 Okt 24 22:29 device -> ../../../PNP0C0A:00
-r--r--r-- 1 root root 4096 Okt 24 22:20 energy_full
-r--r--r-- 1 root root 4096 Okt 24 22:20 energy_full_design
-r--r--r-- 1 root root 4096 Okt 24 22:20 energy_now
-r--r--r-- 1 root root 4096 Okt 24 22:20 manufacturer
-r--r--r-- 1 root root 4096 Okt 24 22:20 model_name
drwxr-xr-x 2 root root    0 Okt 24 22:29 power
-r--r--r-- 1 root root 4096 Okt 24 22:20 power_now
-r--r--r-- 1 root root 4096 Okt 24 22:20 present
-r--r--r-- 1 root root 4096 Okt 24 22:20 serial_number
-r--r--r-- 1 root root 4096 Okt 24 22:20 status
lrwxrwxrwx 1 root root    0 Okt 24 22:20 subsystem -> ../../../../../../../../../class/power_supply
-r--r--r-- 1 root root 4096 Okt 24 22:20 technology
-r--r--r-- 1 root root 4096 Okt 24 22:20 type
-rw-r--r-- 1 root root 4096 Okt 24 22:20 uevent
-r--r--r-- 1 root root 4096 Okt 24 22:20 voltage_min_design
-r--r--r-- 1 root root 4096 Okt 24 22:20 voltage_now

Das ist echt ne gute Frage. Einige gehen auch ohne root rechte '-s --cdiff' z.B.....

Brauche ich nicht oft und ich bin ja eh root. Für erste Versuche mit doas wars aber gut so wie es ist.

[mcb]

Auch wenn's schon etwas her ist...........................

Von Entwickler höchstpersönlich: "um mit tpacpi-bat via acpi_call Ladeschwellen und/oder force_discharge auszulesen." - ja so acht es Sinn https://thinkpad-forum.de/threads/82441 ... ost2293819

[hikaru]

Ja, hab ich gesehen. Danke für's Nachfragen.
Ich finde es trotzdem schlecht gelöst, dafür zwingend root-Rechte zu fordern, denn die meisten Akkuinformationen kann man ohne root-Rechte abfragen. Besser fände ich, wenn das Programm ohne root-Rechte eine Meldung ausgeben würde, dass manche Daten nur mit root-Rechten verfügbar sind.

[mcb]

Ja, hab ich gesehen. Danke für's Nachfragen.
Ich finde es trotzdem schlecht gelöst, dafür zwingend root-Rechte zu fordern, denn die meisten Akkuinformationen kann man ohne root-Rechte abfragen. Besser fände ich, wenn das Programm ohne root-Rechte eine Meldung ausgeben würde, dass manche Daten nur mit root-Rechten verfügbar sind.

Kannst du ja mal vorschlagen - macht Sinn die Idee.

[hikaru]

Ich habe mit dem Entwickler eine "Vorgeschichte". Daher glaube ich nicht, dass er meinen Vorschlägen gegenüber aufgeschlossen wäre. Sei mutig!