eventadd als nicht root user ausführen nicht möglich !?

level20peon

Mitglied
Mitglied seit
11 Jul 2007
Beiträge
270
Punkte für Reaktionen
0
Punkte
16
Wenn ich zB. "eventadd 1 test" als nicht root user eingebe (adduser foo;modsave flash;), erscheint nichts im log des FritzBox webinterfaces, aber auch kein Fehler in der Konsole. Die Zugriffsrechte erlauben nicht root usern grundsätzlich die Ausführung des binary... wer kann mir hier weiterhelfen ?
 
Moins

Damit das funktioniert muss der User der Gruppe root angehören.
...wie alle anderen boxusr auch.
Code:
nobody:$1$HthSzgwF$e9NBn5ZBQndHXuq3q9QG20:65535:[COLOR=#ff0000]65535[/COLOR]:nobody:/nonexistent:/bin/false
Ändere also in /etc/passwd die Gruppenzugehörigkeit auf 0 (root).
Code:
nobody:$1$HthSzgwF$e9NBn5ZBQndHXuq3q9QG20:65535:[COLOR=#ff0000]0[/COLOR]:nobody:/nonexistent:/bin/false
 
Ich habe diesen weiteren user überhaupt nur eingerichtet, damit er keine root Rechte hat. Also werde ich mich wohl entscheiden müssen, ob der user doch root wird, oder ob er eventadd nicht nutzen kann ? Oder verwechsel ich da was: welche Auswirkung bezüglich Sicherheit hat es, den user der root Gruppe hinzuzufügen ?
 
Da die Datei mit den Ereignissen nun mal root gehört:
Code:
root@FB7490:~ $ ls -l /var/.ar7events
-rw-rw-r--    1 root     root         40000 Nov 14 14:19 /var/.ar7events
braucht man logischerweise entweder die Gruppe root oder sogar den Benutzer root oder man erlaubt dem Rest der Welt auch das Schreiben (ob das am Ende reicht, muß man aber erst mal probieren).

Alternativ könnte man "eventadd" mit "setuid"-Flag (oder setgid) bereitstellen, das geht wegen des r/o-Filesystem dann nur in durch Firmware-Änderung.

Wobei die Einführung eines einzelnen Nutzers mit geringeren Rechten beim FRITZ!OS schon sehr sehr gut durchdacht werden will (auch das Droppen bei Daemons auf "nobody/nogroup" ist beim FRITZ!OS eher symbolisch und funktioniert nur bei einigen wenigen Diensten wirklich, die anschließend keine Dateien neu öffnen wollen) - nur für einen einzelnen Einsatzfall bringt so ein Konzept nur wenig und der Aufwand ist entprechend hoch.

Wenn das ein öffentlich erreichbarer Dienst wird, dessen Sicherheit einem selbst nicht so recht geheuer ist, dann würde ich den eher nicht auf die Box bringen anstatt über eine Einschränkung von Rechten nachzudenken.

Genau für solche Fälle gibt es dann nämlich bei "richtigem Linux" die zusätzlichen Sicherheitslayer (SELinux oder AppArmor) - wenn man dem eventadd-Kommando (ClosedSource von AVM) das setuid-Bit verpaßt und durch geeignete Parameter beim Aufruf kann das dann mißbraucht werden (z.B. durch Überläufe beim Ersetzen von Zeichenketten in den Templates), ist man genauso weit mit einem Nutzer mit geringeren Rechten wie ohne einen solchen.

Wobei meine Haltung da schon etwas ambivalent ist ... so sehr so ein Schritt auch zu begrüßen ist (wenn sich niemand bewegt, ändert sich auch nichts), so wenig bringt er eben als einzelne Maßnahme - wenn man dabei nicht stehen bleibt und diese Linie konsequent weiter verfolgt, dann ist das etwas, was ich sehr gut finde. Aber nur für "das gute Gefühl" wäre es schon etwas Overkill ... wenn da irgendwann das "eventadd"-Kommando von AVM ausgeführt werden soll, dann ist das ja sicherlich nicht das einzige, was da stattfinden wird. Es kommt also schon sehr auf den Anwendungsfall an ...
 
ok, dann werde ich den user in sein homedir loggen lassen und das log file via tail von root an eventadd senden lassen - so bleibt der zusätzliche user kompromisslos ohne jegliche Rechte auf der Box. Er soll (auch in Zukunft) nichts weiteres können, außer eben events zu senden. Also ist das nach der oben abgegebenen Beschreibung scheinbar die beste Lösung, zumindest sofern ich mich nicht irre.
 
Yup, die Box ist einfach nicht als Multiuserfähig anzusehen.

Tip: Übermounte die /etc/profile mit einer leeren Datei*, damit ein sauberes Login für eigene User möglich ist



* Oder etwas sinnvollen, funktioniert ähnlich ~/.profile nur eben global für alle Logins
 
Zuletzt bearbeitet:
Tip: Übermounte die /etc/profiles mit einer leeren Datei, damit ein sauberes Login für eigene User möglich ist

Du meinst aber nur als rein kosmetische Maßnahme, um die Ausgabe von

-sh: /etc/init.d/rc.conf: line 4: can't create /var/env: Permission denied
grep: /etc/default.language: Permission denied
rm: can't remove '/var/TZ': Permission denied
ln: /var/TZ: File exists

zu unterbinden, oder?
 
Ja, genau.
Diese Kommandos sind nur dem User root erlaubt und deswegen hagelt es die Fehlermeldungen.

Abgesehen davon sind die Dateien schon längst erstellt worden, sind also vorhanden.
...deswegen ist eine erneute Ausführung von /etc/profile bei jeden Login nicht nötig.
 
Zuletzt bearbeitet:
...deswegen ist eine erneute Ausführung von /etc/profile bei jeden Login nicht nötig.
Ich gestatte mir noch die Bemerkung, daß das aber gerade der Sinn einer /etc/profile ist, bei jedem Login die Nutzerprofile (mit globalen Angaben) einzurichten.

Wenn man hingegen andere (unprivilegierte) Nutzer hat, die an die Dateien in /var nicht herandürfen, dann sollte man das zumindest mit passenden Kommandos ersetzen, die auf Dateien im zugänglichen Bereich bauen oder einfach die Leserechte für "other" (warum die /etc/default.language nur "640" hat, weiß vermutlich auch nur der Hausmeister bei AVM) korrekt einrichten. Ansonsten führen fehlende Einstellungen im Environment (fast alles bei AVM in der /etc/profile läuft darauf hinaus) in einer Session schon mal zu sehr merkwürdigen Effekten - so eine /etc/profile ist also schon sehr wohl sinnvoll, wenn man sie auch mit sinnvollen Kommandos füllt.
 
Nun, dann könnte die /etc/profile in Kopie so abgeändert werden, dass die (Fehler)Ausgaben der entsprechenden Kommandos nach /dev/null oder einer Logdatei gehen.
Siehe: command > /dev/null 2>> /tmp/error.log
...oder eine Bedingung, die auf root User prüft, die erst garnicht ausführt.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.