ubuntuusers.de

Tach zusammen,

Auf meinem Unbuntu Server läuft ein Asterisk, der unter bestimmten Bedingungen Dateien anlegt, die Später auf den Webserver (APACHE2) -genauer auf ein Verzeichnis im Owncloud, übertragen werden sollen.

Der Ablauf ist wie folgt: Unter dem Benutzer "asterisk" wird im Laufe eines Gespräches eine Datei angelegt. Nach Abschluss des Gespräches muss diese Datei "nachbehandelt" werden. Ist die Nachbehandlung erfolgt wird die Datei verschoben -in das Verzeichnis des OC Benutzers. Als letztes soll nun ein "occ scan:files --path [oc-ablagepfad]" aufgeführt werden, damit die Dateien zügig angezeigt werden.

Der letzte Schritt scheitert an den Berechtigungen der unterschiedlichen Benutzer. Die Owncloud Instanz läuft unter "www-data" und die VOIP-Instanz unter "asterisk".

Da die "occ" auf den "Besitzer" des config Verzeichnisses schaut, ist es nicht über die Gruppenmitgliedschaft lösbar. Also bin ich über den Weg der "visudo" gegangen. Das "occ" ist ein php-script und wird innerhalb des bash scriptes, welches unter dem Benutzer "asterisk" ausgeführt wird mit diesem Befehl gestartet:

1

sudo -u www-data /usr/bin/php5 /var/www/owncloud/occ files:scan --path=$USER/files/$VOIPABLAGE

Die "visudo" sieht bei mir so aus:

asterisk        ALL=NOPASSWD: /usr/bin/php5
www-data        ALL=NOPASSWD: /usr/bin/php5

Dennoch funktioniert es nicht, denn bei "manueller" Ausführung mit

1

sudo -u asterisk ./moveall

Werde ich mit

[sudo] password for asterisk:

geprompted.

Wo ist mein Gedankenfehler?! Gehe ich eventuell einen falschen Ansatz? Gibt es einen anderen -besseren; Weg?

Gruss und Dank

Carsten

inoculator schrieb:

Dennoch funktioniert es nicht, denn bei "manueller" Ausführung mit

1	sudo -u asterisk ./moveall

Werde ich mit

[sudo] password for asterisk:

geprompted.

Als welcher Benutzer gibst Du das ein?

Wo ist mein Gedankenfehler?!

Vermutlich nutzt Du zum testen den falschen Nutzer 😉

Gehe ich eventuell einen falschen Ansatz? Gibt es einen anderen -besseren; Weg?

Um das zu sagen, müsste man dein ZIEL kennen, siehe auch Richtig fragen "Nenne das Ziel, nicht den Schritt". Was soll am Ende dabei rauskommen?

Hallo redknight,

verzeih, wenn ich das Regelwerk nicht richtig verstehe. Ich bin davon ausgegangen, daß mit dem einleitenden Satz

"Auf meinem Unbuntu Server läuft ein Asterisk, der unter bestimmten Bedingungen Dateien anlegt, die Später auf den Webserver (APACHE2) -genauer auf ein Verzeichnis im Owncloud, übertragen werden sollen."

ich genau dieser Anforderung nachgekommen wäre. Ich könnte noch eine Stufe fragmentieren -bin aber davon ausgegangen, daß meine Ausführungen genau diese Fragestellung beinhaltet:

"Wie starte ich aus einem Bash Script, welches unter dem Benutzercontext "asterisk" gestartet wird, ein php Script, welches unter dem Benutzerkontext "www-data" laufen muss?"

Leider weiß ich da nun nicht, wie ich die Aufgabenstellung weiter präzisieren soll, da alles weitere tatsächlich technische Details sind, welche ich ja schon beschrieben hatte.

Zu Deinen Fragen:

"Als welcher Benutzer gibst Du das ein?"

Ich melde mich an der Konsole mit meinem regulären Benutzer "voipadmin" an.
Nun führe ich die "moveall" -besagtes Script, welches aus dem VOIP Server heraus nach einem Telefonat gestartet wird; mit dem angegebenen Befehl aus.
Zunächst werde ich dann -soweit ich den 15 Minuten Timeout überschritten habe; nach dem Passwort des "voipadmin" gefragt.

"[sudo] password for voipadmin:"

Danach läuft das Script und erledigt die "Nacharbeiten" an den Dateien im Kontext des Benutzers "asterisk".
Im letzten Schritt im Script kommt dann besagte Zeile, wo der Kontext an den Benutzer "www-data" übergeben werden soll.

1

sudo -u www-data /usr/bin/php5 /var/www/owncloud/occ files:scan --path=$USER/files/$VOIPABLAGE

Dabei wird gefragt:

"[sudo] password for asterisk:"

Ich hoffe Deine offenen Fragen damit beantwortet zu haben.

Beste Grüße

Carsten

Hallo,

inoculator schrieb:

Ich könnte noch eine Stufe fragmentieren -bin aber davon ausgegangen, daß meine Ausführungen genau diese Fragestellung beinhaltet:

Das ist aber nicht das Ziel 😉 Dein Ziel könnte zB sein "Ich möchte die Mailbox-Aufnahmen meiner Telefonanlage für die Benutzer zum Download anbieten" - Das ist wild geraten. Ich frage das auch nicihtzum Spaß, es ist ja möglich, dass Dein eigentliches Zi8el auf dem Weg nicht zu erreichen ist. Dann müssten dir Alternativen empfohlen werden (vielleicht gibt es auch einfach shcnellere und bessere Alternativen), die wiederum nur empfohlen werden können, wenn das eigentliche Ziel bekannt ist.

Zu Deinen Fragen:

"Als welcher Benutzer gibst Du das ein?"

Das bestätigt meine Vermutung. Du hast in deiner sudoers die Ausführung des Skriptes für den user asterisk erlaubt. Du führst es aber als voipadmin aus. Da es für voipadmin keine Regel gibt, die Ausführung ohne Passwort erlaubt, fragt das System nach deinem Passwort.

Hallo,

ok... moment... jetzt habe ich ein grundsätzliches Verständisproblem.

Ich muss zugeben, daß ich aus der Windows Ecke komme und die Sicherheitsstruktur von dort gedanklich übertrage. Ausgangslage:

Ich bin als Benutzer "A" am System angemeldet. Mit einem "RunAs" starte ich nun ein Script und übergebe den Kontext dabei an den Benutzer "B". Alles was nun in diesem Script abgearbeitet wird, wird IMMER auf den Benutzer "B" bezogen. Wenn nun innerhalb des Scriptes wieder ein "RunAs" kommt, welches dann an den Benutzer "C" übergibt, so ist der Ausgangsbenutzer "B" aber niemals "A".

Wenn ich das nun auf meine Aufgabenstellung übertrage, bedeutet das:

Benutzer "voipadmin" startet in der Konsole per "sudo -u asterisk" ein Script. Dieses Script wird im Kontext des Benutzers "asterisk" ausgeführt. Die Beweisführung dafür ist, daß Dateien, die im Zuge der Ausführung des Script angelegt werden, immer den Besitzer "asterisk" haben. Nun kommt innerhalb des Scriptes ein "sudo -u www-data" womit ein weiteres Script in dem Kontext des Benutzer "www-data" gestartet werden soll. Ausgangslage muss dann doch der Benutzer "asterisk" sein, unter dem ja das erste Script gestartet wurde.

Ist diese Annahme falsch?

Gruss

Carsten

inoculator schrieb:

Ist diese Annahme falsch?

die sollte richtig sein - das hattest Du aber alles bisher nicht erwähnt. Man konnte es auch nicht ersehen, weil du nur Ausschnitte und nicht deinen kompletten Ablauf gezeigt hast. Daher auch "Sei genau und informativ über dein Problem".

Welche Aufrufe hast Du denn noch in dem Skript - Hast Du vllt ein weiteres sudo benutzt, welches nicht php aufruft?

ok... da bin ich erstmal beruhigt 😉

Jetzt versuche ich es noch einmal von Vorne:

Es muss unterschieden werden, zwischen dem "produktiven" Fall und dem "debugging". In der Produktion wird das Script über einen Aufruf aus dem Asterisk gestartet, der unter dem Benutzer "asterisk" läuft.

Beim Debuggen bin ich in der Konsole als "voipadmin" angemeldet und simuliere den Aufruf durch den "sudo -u asterisk ./moveall"

Da das Script aus dem Asterisk heraus nicht richtig läuft, sprechen wir aktuell über das Debugging.

Jetzt zum Ablauf und dem Inhalt des Scriptes:

Tatsächlich sprechen wir vom "Mitschnitten" von Telefonaten, die unter bestimmten Bedingungen gestartet werden können. Dieser Mitschnitt soll dann in das Verzeichnis des Benutzers auf dem owncloud bereitgestellt werden.

Das Script hat nur die Aufgabe, die wav-Datei, welche in einem temporären Verzeichnis angelegt wird, zu verschieben und dann den Indexprozess des OwnCloud zu starten, damit die Datei unverzüglich angezeigt wird:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#!/bin/bash

TMP=/tmp/recordings
OCBASE=/var/www/owncloud/data
OCUSER=$1
OCREC=files/Dokumente/Recorder

chmod 775 $TMP/*.wav
mv $TMP/*.wav $OCBASE/$OCUSER/$OCREC/
chgrp www-data $OCBASE/$OCUSER/$OCREC/*

sudo -u www-data /usr/bin/php5 /var/www/owncloud/occ files:scan --path=$OCUSER/$OCREC

Tatsächlich werden die wav-Dateien in das Zielverzeichnis verschoben und die Gruppe "www-data" berechtigt. Jetzt kommt der Aufruf des php5 Scriptes "occ". Dieses hat die Bedingung, daß es unter dem "Besitzer" des "config"-Verzeichnisses des OwnCloud ausgeführt werden muss -das ist in meinem Fall "www-data". Also ein "sudo -u www-data" vorangestellt. Würde ich jetzt das "pseudo"-Passwort des Benutzer "asterisk" in der Kommandozeile eingeben, funktioniert der Aufruf. Da das Script aber Produktiv nicht interaktiv läuft, sondern "unattendet" aus dem Dienstkontext des Benutzers "asterisk" gestartet werden soll, muss eine Passwortabfrage hier verhindert werden. Das wiederum dachte ich erreichen zu können, mit dem "visudo" Einträgen

asterisk        ALL=NOPASSWD: /usr/bin/php5
www-data        ALL=NOPASSWD: /usr/bin/php5

Das tutet aber nicht.

Ich hab grad mal getestet, ich darf mit meinem user zB chgrp nicht ausführen. Möglicherweise kommt die Passwortabfrage daher.

Ich würde daher zunächst mal ein echo vpr jedem Befehl einbauen, um rauszufinden, welcher Befehl denn nun die Passwortabfrage auslöst.

Hi,

so, hat etwas gedauert, da ich nicht von überall Zugriff auf die Konsole zu Hause habe 😉

Also hier mal das "ungekürzte" Script mit "debug"-Schritten im Guttenberg-Verfahren:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#!/bin/bash

IAM="$(whoami)"
echo "I am ${IAM}"

TMP=/tmp/recordings
OCUSER=$1
OCREC=files/Dokumente/Recorder
OCBASE=/var/www/owncloud/data

 
echo "chmod 775 $TMP/*.wav"
chmod 775 $TMP/*.wav 1>/dev/null 2>/dev/null

echo "mv $TMP/*.wav $OCBASE/$OCUSER/$OCREC/"
mv $TMP/*.wav $OCBASE/$OCUSER/$OCREC/ 1>/dev/null 2>/dev/null

echo "chgrp www-data $OCBASE/$OCUSER/$OCREC/*.wav"
chgrp www-data $OCBASE/$OCUSER/$OCREC/*.wav 1>/dev/null 2>/dev/null

echo "chown www-data $OCBASE/$OCUSER/$OCREC/*.wav"
chown www-data $OCBASE/$OCUSER/$OCREC/*.wav 1>/dev/null 2>/dev/null

echo "sudo -u www-data /usr/bin/php5 /var/www/owncloud/occ files:scan --path=$OCUSER/$OCREC"
sudo -u www-data /usr/bin/php5 /var/www/owncloud/occ files:scan --path=$OCUSER/$OCREC

echo Fertig

Jetzt die Ausgabe, wenn ich an der Konsole als "voipadmin" angemeldet bin mit dem Aufruf:

voipadmin@derdvoip:/tmp/recordings$ sudo -u asterisk ./moveall carsten
I am asterisk
chmod 775 /tmp/recordings/*.wav
mv /tmp/recordings/*.wav /var/www/owncloud/data/carsten/files/Dokumente/Recorder/
chgrp www-data /var/www/owncloud/data/carsten/files/Dokumente/Recorder/*.wav
chown www-data /var/www/owncloud/data/carsten/files/Dokumente/Recorder/*.wav
sudo -u www-data /usr/bin/php5 /var/www/owncloud/occ files:scan --path=carsten/files/Dokumente/Recorder
[sudo] password for asterisk: 
Fertig

Ich hoffe, daß verdeutlicht wo die Abfrage kommt.

Gruss Carsten

ok, ok , ich glaub dir ja. Ich versuche das gleich mal nachzustellen - ich vermute (aber weiß es nicht) dass sudo nicht nested genutzt werden kann. in dem Fall müsstest Du zu debugzwecken für den voipadmin auch mal php wie für die Dienstnutzer erlauben

Vorschlag: Du erstellt ein Skript welches www-data:www-data gehört. Dort schreibst du die auszuführenden Befehle ohne "sudo" hinein. Falls gesetzt entziehe bitte "allen anderen" (others) die Schreibrechte der Datei. Nun setzt du das SUID-Bit + SGID-Bit. Durch das SGID/SUID-Bit wird das Skript immer mit den Rechten von www-data:www-data ausgeführt, egal welcher User es startet. Siehe Sonderrechte.

Bei deiner aktuellen Lösung erlaubst du www-data und asterisk jeden Befehl als Superuser auszuführen. Ich muss mein Kommando lediglich in ein PHP-Skript schreiben und ausführen. Damit hast du, meiner Meinung nach das Berechtigungssystem praktisch ausgehebelt.

Edit: Interessanterweise funktioniert das SUID-Bit nicht bei Bash-Skripten (Quellen: stackexchange, Real and Effective IDs). Das macht meinen Vorschlag leider ungleich schwerer. Ich habe es mittels C-Programm aber dennoch zum laufen bekommen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
   setreuid(geteuid(), geteuid()); //Real UID := Effective UID
   setregid(getegid(), getegid()); //Real GID := Effective GID
   system("/tmp/test.sh"); //Dein Script welches die Kommandos beinhaltet welche als www-data laufen sollen. Bitte anpassen.

   return 0;
}

Diese Datei habe ich "test.c" genannt. Anschließend bin ich wie folgt vorgegangen:

1
2
3
4

gcc test.c -Wall -o test #Das Programm kompilieren.
sudo chown www-data:www-data test #Das Programm www-data "unterschieben"
sudo chmod o-w test #"andeten" eventuelle Schreibrechte entziehen.
sudo chmod ug+s test #SUID/SGID-Bit setzen.

Diese Technik sollte sicherer sein da sich hierdurch der Angreifer auf diesem Weg höchstens die Berechtigungen von www-data beschaffen könnte. Mögliche Angriffsvektoren um dies zu erreichen findet man z.B. hier im Abschnitt "Setuid interpreters".

Moin,

danke erst einmal für die Entwicklungshilfe. Ich muss mich da in der Thematik tatsächlich erst reinfinden.

Über die möglichen Angriffszenarien habe ich mir so auch noch keinen Kopf gemacht, da das System nicht unmittelbar aus dem öffentlichen Netz erreichbar ist und wir "nur" von einem Familienserver reden.

Meine Herausforderung an der Sache ist, daß ich alle Konfigurationsschritte dokumentieren und nachvollziehen können muss, um sie bei späteren Wartungsarbeiten oder im Falle einer notwendigen Wiederherstellung nicht zu vergessen.

Ich arbeite Deine Lösung jetzt mal Stück um Stück durch und melde mich, wenn ich Fragen habe.

Gruss

Carsten

Abschluss

Hallo zusammen,

danke nochmal für die Hilfe. Ich habe jetzt eine ganze Menge in Richtung UID probiert und auch gelernt. Auch daß verschiedene Shells anders mit dem Flag umgehen.

Da ich im Laufe der Tests -die teilweise sogar Erfolgreich waren, immer mehr in das Problem gelaufen bin, daß ich daß nicht "mal eben" in das operations manual oder BHB einarbeiten kann, habe ich mich dann doch für den Weg über das "Webinterface" unter Verwendung von "curl" entschieden.

sinngemäß: curl -X put -u [username]:[password] "http://[FQDN]/remote.php/webdav/Dokumente/Recorder/[filename]" --data-binary @"./[filename]"

Damit gehe ich zwar mit allem eine "Runde um den Block" aber ich bin aus der ganzen UID Geschichte raus und habe auf diesem Wege nun auch zwei weitere Herausforderungen gelöst.

Beste Grüße

Carsten