c programm, das nur shell script aufruft benötigt
Hallo, ich möchte eine Administrative aufgabe über ein shell script lösen. Da hier jedoch der suid Modus nicht arbeiten und ich suidperl nicht verwenden will, kommt mir in den sinn ein minni c-programm zu schreiben, das lediglich das shell script ausführt (von hinten ins Auge ...). Sicher kann mir einer von Euch cracks sagen, was ich benötige um sowas einfaches zu stricken und wie das Programm auszusehen hat um: sh shellscriptname $variable1 $variable2 zu übergeben. Beide Variable sollen dem c programm manuell übergeben werden sollen. Abgesichert soll das c programm durch eine andere neue usergruppe werden. also -rws---x--- root usergruppe programmname Ich hoffe ich verlange da nicht zuviel, aber die Thematik ist für mich zu umfangreich um da voll einzusteigen, nur um sowas relativ simples einfach zu lösen! greetinXs, Telefon: 07275/618351 Michael Hilscher Handy: 0173/3071899 Telefax: 07275/618352 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Michael Hilscher
ich möchte eine Administrative aufgabe über ein shell script lösen. Da hier jedoch der suid Modus nicht arbeiten und ich suidperl nicht verwenden will, kommt mir in den sinn ein minni c-programm zu schreiben, das lediglich das shell script ausführt (von hinten ins Auge ...).
Was spricht gegen setuidperl? Wenn Du sowas machst, dann musst Du "einfach" nur von der zu startenden Datei prüfen, ob dieses setuid-Flag gesetzt hat und ob der Owner root ist. Dann der eigentliche Aufruf. Diese Lösung hätte dann aber genau die gleichen Nachteile wie setuidperl. Eher sogar mehr, weil Du ja auch einen Fehler machen könntest und so. Daher mein Tipp: Nimm setuidperl! Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
On Thu, Apr 25, 2002 at 01:52:42PM +0300, Konrad Neitzel wrote:
ich möchte eine Administrative aufgabe über ein shell script lösen. Da hier jedoch der suid Modus nicht arbeiten und ich suidperl nicht verwenden will, kommt mir in den sinn ein minni c-programm zu schreiben, das lediglich das shell script ausführt (von hinten ins Auge ...).
Was spricht gegen setuidperl? Ich denke, dass suidperl auf einem Webserver aus sicherheitsgründen nicht installiert werden sollte. Aber Du sprichst ja von setuidperl.
Ich vermute mal, dass es ein perl Befehl ist und nicht zusätzlich installiert werden muss. Dooferweise kann ich überhaupt nichts genaueres darüber finden (und das nach nunmehr gut anderthalb Stunden intensiver Sucherei), aber vielleicht kannst Du mir ja auch aus dem Stehgreif weiterhelfen? Wie muss denn so ein setuidperl programm für den Aufruf eines shell scripts (oder eigentlich könnte man ja die einzelnen shell befehle auch direkt in diesem Script über System(); ausführen?) aussehen??? größten Dank im voraus! greetinXs, Telefon: 07275/618351 Michael Hilscher Handy: 0173/3071899 Telefax: 07275/618352 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Michael Hilscher
Was spricht gegen setuidperl? Ich denke, dass suidperl auf einem Webserver aus sicherheitsgründen nicht installiert werden sollte. Aber Du sprichst ja von setuidperl.
Schreibfehler von meiner Seite aus.
Ich vermute mal, dass es ein perl Befehl ist und nicht zusätzlich installiert werden muss. Dooferweise kann ich überhaupt nichts genaueres darüber finden (und das nach nunmehr gut anderthalb Stunden intensiver Sucherei), aber vielleicht kannst Du mir ja auch aus dem Stehgreif weiterhelfen?
Wie muss denn so ein setuidperl programm für den Aufruf eines shell scripts (oder eigentlich könnte man ja die einzelnen shell befehle auch direkt in diesem Script über System(); ausführen?) aussehen???
1) suidperl ist genau so ein Wrapper für perl. 2) Ich sehe darin kein Sicherheitsrisiko. Ausser eben, dass jedes suid- root Programm ein potenzielles Risiko sein könnte. 3) Was für ein Script musst Du denn starten? Shellscript? Was macht dieses Script? Warum nicht einfach zu einem Perlscript umschreiben? 4) Zusätzliche Sicherheit kann man ja einführen, in dem man z.B. eine neue Gruppe suidperl einrichtet und nur die User, die da drin sind, haben da ein executerecht drauf! Dann kann es nicht mehr jeder aufrufen. Wäre aber auch nicht so schlimm, denn suidperl lässt das alles nur mit root-Rechten laufen, wenn das Script selbst auch suid- root ist! 5) Eine Lösung wie: #!/usr/bin/suidperl system ("/path/to/my/program"); lehne ich 100% ab. DAS wäre eine Sicherheitslücke! Du musst prüfen: - Script hat suid Flag? - Script ist owner root? - user hat leserechte (Bei einem Script wird kein executerecht benötigt!) Und vielleicht vergesse ich hier auch noch etwas wichtiges. Ich wäre damit immer sehr vorsichtig. suidperl ist etwas, das sich schon halbwegs etabliert hat, sprich: Da haben schon mehrere Leute drüber geschaut, so dass grobe Lücken hoffentlich nicht drin sind! Zur Not baust Du Dir Dein eigenes suidperl in /home/xxxxx mkdir /home/xxxxx/priv chmod go-rwx /home/xxxxx/priv <-- Nur noch Du kommst in dieses Verzeichnis! cp /usr/bin/suidperl /home/xxxxx/priv su chown root.users /home/xxxxxx/priv/suidperl chmod u+s /home/xxxxxx/priv/suidperl Dann kann kein anderer User damit etwas anfangen noch wird dein Webserver irgendwie beeinflusst. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
Hallo, Am Donnerstag, 25. April 2002 13:26 schrieb Michael Hilscher:
ich möchte eine Administrative aufgabe über ein shell script lösen. Da hier jedoch der suid Modus nicht arbeiten und ich suidperl nicht verwenden will, kommt mir in den sinn ein minni c-programm zu schreiben, das lediglich das shell script ausführt (von hinten ins Auge ...).
$ man 3 execv
$ man 3 system
`exec..' tauscht den laufenden Prozeß /aus/ und kehrt
NICHT zurück, `system' startet einen Unterprozeß und
/kehrt/ zurück.
Irgendwie so (nicht getestet):
----schnipp----
#include
On Thu, Apr 25, 2002 at 02:27:40PM +0200, Bertram Scharpf wrote:
Irgendwie so (nicht getestet):
----schnipp---- #include
int main( int argc, char *argv[]) { return execv( "scriptname", argv); } ----schnapp----
Teil' dann mal mit, ob's geklappt hat. Erstmal vielen Dank für den Code. Ich kann ihn mangels Basiswissen jedoch noch nicht mal ausführen ... Nachdem ich die manpage zu gcc angesehen habe, speicherte ich den text als cprog.c und habe gcc mit -c aufgerufen. Als Resultat erhielt ich cprog.o. Ich sehe schon eure belustigten Gesichter. Habe ich völlig falsch gemacht, gelle ...?
greetinXs, Telefon: 07275/618351 Michael Hilscher Handy: 0173/3071899 Telefax: 07275/618352 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
Am Don, 25 Apr 2002 schrieb Michael Hilscher:
On Thu, Apr 25, 2002 at 02:27:40PM +0200, Bertram Scharpf wrote:
Irgendwie so (nicht getestet):
----schnipp---- #include
int main( int argc, char *argv[]) { return execv( "scriptname", argv); } ----schnapp----
Teil' dann mal mit, ob's geklappt hat. Erstmal vielen Dank für den Code. Ich kann ihn mangels Basiswissen jedoch noch nicht mal ausführen ... Nachdem ich die manpage zu gcc angesehen habe, speicherte ich den text als cprog.c und habe gcc mit -c aufgerufen. Als Resultat erhielt ich cprog.o. Ich sehe schon eure belustigten Gesichter. Habe ich völlig falsch gemacht, gelle ...?
Nee, nee, ist schon ok. Jetzt noch mit gcc -o cprog cprog.o Dann erhältst Du das ausführbare Programm cprog. Allerdings geht es bei einem einzigen Source-File auch mit gcc -o cprog cprog.c Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
* Christoph Maurer schrieb am 25.Apr.2002:
Nee, nee, ist schon ok.
Jetzt noch mit gcc -o cprog cprog.o
Dann erhältst Du das ausführbare Programm cprog.
Allerdings geht es bei einem einzigen Source-File auch mit gcc -o cprog cprog.c
oder ganz einfach make cprog Wie aus cprog.c cprog gemacht wird, weiß make. Du kanst natürlich auch einfach gcc cprog.c sagen und Dein ausfürbares Programm heißt dann a.out kann man ja umbenennen. Bernd -- Bei Fragen an die Liste erst mal nachschauen, ob es diese Frage nicht schon einmal gegeben hat. Ein Archiv der Liste findest Du auf: http://lists.suse.com/archives/suse-linux |Zufallssignatur 7
Hallo!
Michael Hilscher
Erstmal vielen Dank für den Code. Ich kann ihn mangels Basiswissen jedoch noch nicht mal ausführen ... Nachdem ich die manpage zu gcc angesehen habe, speicherte ich den text als cprog.c und habe gcc mit -c aufgerufen. Als Resultat erhielt ich cprog.o. Ich sehe schon eure belustigten Gesichter. Habe ich völlig falsch gemacht, gelle ...?
Lass den -c Schalter Weg. Der -c Schalter sagt, dass er nur compilieren soll und das ist falsch. Setz maximal noch ein -o cprog dazu. ABER: So würde ich das NIE machen wollen. Das Teil prüft ja absolut NICHTS! Ob das Script suid-Flag hat oder nicht wird nicht geprüft. Wenn ich es irgendwie schaffe, das script zu verändern, dann habe ich sofort root Rechte. Du willst Das so bestimmt nicht! Und wenn DU sowas nutzt, aber dir suidperl zu unsicher ist, dann fällt mir dazu nichts ein. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
On Thu, Apr 25, 2002 at 05:28:50PM +0300, Konrad Neitzel wrote:
ABER: So würde ich das NIE machen wollen. Das Teil prüft ja absolut NICHTS! Ob das Script suid-Flag hat oder nicht wird nicht geprüft. Wenn ich es irgendwie schaffe, das script zu verändern, dann habe ich sofort root Rechte. Du willst Das so bestimmt nicht! Und wenn DU sowas nutzt, aber dir suidperl zu unsicher ist, dann fällt mir dazu nichts ein. Wenn Du das shell script ändern kannst, obwohl es nur für root les- und ausführbar sein wird, dann ist sicherlich alles wurscht. Ich denke, dass ein kompiliertes c-programm mit suid bit und owner root sicherlich schwerer zu ändern ist als ein perlscript mit suidperl?
Aber zur Zeit bekomme ich weder das eine noch das andere hin, sodass ich
meinem Partner für diese Arbeiten einen root-login geben müsste. Das
wäre ja garnicht so tragisch, aber es ist halt eher unbequem, wenn ein
Admin Teil über ein (SSL-gesichertes) Web-Interface läuft und der andere
über ein shell script, wofür nach einem userlogin su "shellscript
kundenname passwort" aufgerufen werden muss. Ausserdem ist mein Partner
noch nicht so fit im linux bereich und wer weis welche Vertipper ihm in
der Konsole unterkommen. Aber zurück zum eigentlichen.
1. Testprogramm: perltest.pl
---
#!/usr/bin/suidperl
system ("date > datumsausgabe");
exit
-rwsr-x--- 1 root users 58 Apr 25 21:11 perltest.pl
macvampi@linbook:~/test> perltest.pl
Can't do setuid
-> macvampi gehört zur Benutzergruppe users. Ich habe über suidperl -h
ebensowenig wie im Internet hinweise gefunden wieso das nicht funzt.
-> gleiche Fehlermeldung bei aufruf perl perltest.pl und suidperl p...
2. Testprogramm: cprog (source: cprog.c / kompiliert mit gcc, option -o)
---
#include
3) Was für ein Script musst Du denn starten? Shellscript? Was macht dieses Script? Warum nicht einfach zu einem Perlscript umschreiben? Ich kenne mich mit Perl nicht so gut aus. Es geht um Erweiterungen an der httpd.conf (automatisches Eintragen von Directories und Aliasen, sowie dem anlegen eines Useraccounts mit Passwort (nur für FTP).
useradd $1 -g nogroup -s /bin/false -d /usr/local/httpd/htdocs/kundenserver/$1/ftp echo "$1"":""$2" | chpasswd chown -R $1 /usr/local/httpd/htdocs/kundenserver/$1/cms/ftp chown -R $1 /usr/local/httpd/htdocs/kundenserver/$1/cms/ftp chmod -R 770 /usr/local/httpd/htdocs/kundenserver/$1/cms/ftp chmod -R 770 /usr/local/httpd/htdocs/kundenserver/$1/cms/ftp zeile=`grep -sn "#Auto" httpd.conf` IFS=:; set -- $zeile edit_anfang=$1 zeilen=`wc -l httpd.conf` IFS=" "; set -- $zeilen; let bis=$1-$edit_anfang cat httpd.conf | head -$edit_anfang > httpd.tmp.conf echo "Alias und Core Directory bzw vserver bei domain" >> httpd.tmp.conf cat httpd.conf | tail -$bis >> httpd.tmp.conf cat httpd.tmp.conf > httpd.conf rm httpd.tmp.conf rcapache reload -----
4) Zusätzliche Sicherheit kann man ja einführen, in dem man z.B. eine neue Gruppe suidperl einrichtet und nur die User, die da drin sind, haben da ein executerecht drauf! Ja, werde ich auf jeden Fall machen, dooferweise bekommt wwwrun diese usergruppe dann zusätzlich aufgebrummt - sonst bin ich halt wieder beim shell login und hier könnte dann auch su "shellscript username passwort" eingegeben werden ...
greetinXs, Telefon: 07275/618351 Michael Hilscher Handy: 0173/3071899 Telefax: 07275/618352 -- Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? -- Linus Torvalds
* Michael Hilscher schrieb am 25.Apr.2002:
On Thu, Apr 25, 2002 at 05:28:50PM +0300, Konrad Neitzel wrote:
ABER: So würde ich das NIE machen wollen. Das Teil prüft ja absolut NICHTS! Ob das Script suid-Flag hat oder nicht wird nicht geprüft. Wenn ich es irgendwie schaffe, das script zu verändern, dann habe ich sofort root Rechte. Du willst Das so bestimmt nicht! Und wenn DU sowas nutzt, aber dir suidperl zu unsicher ist, dann fällt mir dazu nichts ein. Wenn Du das shell script ändern kannst, obwohl es nur für root les- und ausführbar sein wird, dann ist sicherlich alles wurscht. Ich denke, dass ein kompiliertes c-programm mit suid bit und owner root sicherlich schwerer zu ändern ist als ein perlscript mit suidperl?
Ändern wird da keiner was können. Das Problem bei Skripten, da braucht bloß jemand die Umgebungsvariablen zu ändern. Etwa $PATH Wenn im Skript ein ganz normaler Befehl ausgeführt wird, etwa rm oder mv, grep, find, ln oder was weiß ich, $PATH aber umgelenkt ist, dann kann dieser Befehl plötzlich eine ganz andere Bedeutung haben. Das kann man verhindern, indem man PATH im Skript explizit setzt, oder nur absolute Pfade setzt. Es gibt aber auch noch andere Umgebungsvariablen, die man explizit setzen müßte, etwa $IFS Aber warum nimmst Du nicht einfach sudo? Das macht doch genau das, was Du willst. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12
Michael Hilscher
Wenn Du das shell script ändern kannst, obwohl es nur für root les- und ausführbar sein wird, dann ist sicherlich alles wurscht. Ich denke, dass ein kompiliertes c-programm mit suid bit und owner root sicherlich schwerer zu ändern ist als ein perlscript mit suidperl? Ich versuche nicht, dein C-Programm zu verändern. Bei einer Veränderung entfällt ja automatisch das suid-Bit! Wenn Du z.B. nur einen Aufruf meinscript.sh verwendest, dann verändere ich den Pfad. Oder je nachdem, was in deinem Script verwendet wird, versuche ich wirklich, einfach über irgendwelche Ansatzpunkte etwas zu gewinnen. $PATH ist ein Ansatz, aber es gibt noch deutlich mehr. Du kannst natürlich den PATH setzen, aber was ist mit aliasen und und und ...
Aber zur Zeit bekomme ich weder das eine noch das andere hin, sodass ich meinem Partner für diese Arbeiten einen root-login 1. Testprogramm: perltest.pl --- #!/usr/bin/suidperl system ("date > datumsausgabe"); exit -rwsr-x--- 1 root users 58 Apr 25 21:11 perltest.pl
macvampi@linbook:~/test> perltest.pl Can't do setuid
ls -l /usr/bin/suidperl Ich bin sicher, dass es kein suid-Bit gesetzt hat! Also chmod u+s /usr/bin/suidperl Und dann noch dafür sorgen, dass SuSEconfig ihm dies nicht wieder wegnimmt!
2. Testprogramm: cprog (source: cprog.c / kompiliert mit gcc, option -o) --- #include
int main( int argc, char *argv[]) { return execv( "scriptname", argv); } -rwsr-x--- 1 root users 14669 Apr 25 22:02 cprog -r-xr-x--- 1 root root 71 Apr 25 21:59 scriptname macvampi@linbook:~/test> ./cprog scriptname: scriptname: Keine Berechtigung
Ähm ... was ist die erste Zeile von Deinem Script? #!/bin/sh oder so nehme ich an, oder? Ruf es doch ansonsten explizit auf: /bin/sh /path/to/scriptname
Ich kenne mich mit Perl nicht so gut aus. Es geht um Erweiterungen an der httpd.conf (automatisches Eintragen von Directories und Aliasen, sowie dem anlegen eines Useraccounts mit Passwort (nur für FTP).
useradd $1 -g nogroup -s /bin/false - d /usr/local/httpd/htdocs/kundenserver/$1/ftp echo "$1"":""$2" | chpasswd chown -R $1 /usr/local/httpd/htdocs/kundenserver/$1/cms/ftp chown -R $1 /usr/local/httpd/htdocs/kundenserver/$1/cms/ftp chmod -R 770 /usr/local/httpd/htdocs/kundenserver/$1/cms/ftp chmod -R 770 /usr/local/httpd/htdocs/kundenserver/$1/cms/ftp
zeile=`grep -sn "#Auto" httpd.conf` IFS=:; set -- $zeile edit_anfang=$1 zeilen=`wc -l httpd.conf` IFS=" "; set -- $zeilen; let bis=$1-$edit_anfang cat httpd.conf | head -$edit_anfang > httpd.tmp.conf echo "Alias und Core Directory bzw vserver bei domain" >> httpd.tmp.conf cat httpd.conf | tail -$bis >> httpd.tmp.conf cat httpd.tmp.conf > httpd.conf rm httpd.tmp.conf rcapache reload
Systemaufrufe kannst Du in Perl mit system machen. Aber das ist evtl. nicht ganz so sinnvoll. *grübel* Aber vielleicht konnte ich Dir ja erst einmal etwas helfen. Ansonsten können wir gerne eine erweiterte Fehlersuche per PM durchführen. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
* Konrad Neitzel schrieb am 26.Apr.2002:
Ich versuche nicht, dein C-Programm zu verändern. Bei einer Veränderung entfällt ja automatisch das suid-Bit! Wenn Du z.B. nur einen Aufruf meinscript.sh verwendest, dann verändere ich den Pfad. Oder je nachdem, was in deinem Script verwendet wird, versuche ich wirklich, einfach über irgendwelche Ansatzpunkte etwas zu gewinnen. $PATH ist ein Ansatz, aber es gibt noch deutlich mehr. Du kannst natürlich den PATH setzen,
ACK
aber was ist mit aliasen und und und ...
Wer setzt in einem skript schon ein alias? Und ein skript ließt nicht /etc/profile oder ~/.bashrc ein, so daß in einem skript keine aliases gesetzt sind. Gerade noch mal ausprobiert, ein skript benutzt keine aliases, noch nicht mal, wenn es darin definiert wurde. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
Michael Hilscher (macvampi@michaelhilscher.de) wrote:
Aber zur Zeit bekomme ich weder das eine noch das andere hin, sodass ich meinem Partner für diese Arbeiten einen root-login geben müsste. Das wäre ja garnicht so tragisch, aber es ist halt eher unbequem, wenn ein Admin Teil über ein (SSL-gesichertes) Web-Interface läuft und der andere über ein shell script, wofür nach einem userlogin su "shellscript kundenname passwort" aufgerufen werden muss. Ausserdem ist mein Partner noch nicht so fit im linux bereich und wer weis welche Vertipper ihm in der Konsole unterkommen. Aber zurück zum eigentlichen.
Du könntest das Skript in /root/.ssh/authorized_keys mit dem Schlüssel verknüpfen. Dann wird es automatisch aufgerufen wenn sich Dein Parter mit ssh als root anmeldet. -Falk
Hallo, On Thu, 25 Apr 2002, Michael Hilscher wrote:
ich möchte eine Administrative aufgabe über ein shell script lösen. Da hier jedoch der suid Modus nicht arbeiten und ich suidperl nicht verwenden will, kommt mir in den sinn ein minni c-programm zu schreiben, das lediglich das shell script ausführt (von hinten ins Auge ...).
Warum neu erfinden? sudo/su1 gibt's doch schon. -dnh -- Hah. I bet Al Qaeda inadvertently wiped out a number of bugs and security holes. They *were* working outside the rigorous MS development processes, right? No way that an outside programmer could achieve the same bug density as a trained MS programmer with full knowledge of the source. -- Arthur v. d. Harg in asr on the rumour, that Al Qaeda hacked MS Win
On Thu, Apr 25, 2002 at 07:55:36PM +0200, David Haller wrote:
> Warum neu erfinden? sudo/su1 gibt's doch schon.
Das Script wird vom Webserver ausgeführt. Das schöne an der sudo Lösung
ist, dass ich es so auf anhieb realisieren konnte. Allerdings denke ich,
dass es keine gute idee ist:
1. wwwrun ein Passwort (und damit einen "echten Account") zu verpassen
2. folgende sudo root rechte zu erteilen:
(ALL) /etc/httpd/auto_configure_httpd (vor. standort meines scrits)
(ALL) /bin/chown
(ALL) /bin/chmod
(ALL) /usr/sbin/chpasswd/
(ALL) /usr/sbin/useradd
(ALL) /usr/sbin/rcapache
ich habe ein mulmiges Gefühl und denke, dass die perl Script oder
c-programm Lösung die sicherere Möglichkeit ist?!
Neben der Probelmatik, dass wwwrun zu "einem vollen Useraccount"
wird, kann ich die Ausführung der freigegebenen suid Befehle nicht
weiter kontrollieren - in einem shell/perl/c script/programm indes
werden die Befehle nur im kontext (also tue das mit Datei X
und nicht du darfst Befehl mit beliebiger Datei nutzen) ausgeführt!
greetinXs, Telefon: 07275/618351
Michael Hilscher Handy: 0173/3071899
Telefax: 07275/618352
--
Would Mozart have been more productive if he had scribes to help him, a
secretary and a CEO to lead his way? -- Linus Torvalds
Hallo, On Fri, 26 Apr 2002, Michael Hilscher wrote:
On Thu, Apr 25, 2002 at 07:55:36PM +0200, David Haller wrote:
Warum neu erfinden? sudo/su1 gibt's doch schon. Das Script wird vom Webserver ausgeführt. Das schöne an der sudo Lösung ist, dass ich es so auf anhieb realisieren konnte.
Eben ;)
Allerdings denke ich, dass es keine gute idee ist: 1. wwwrun ein Passwort (und damit einen "echten Account") zu verpassen
Nimm /bin/false als shell. Und ich denke besser ein PW, als ein NOPASSWD in der sudoers... (oder aehnliches ;)
2. folgende sudo root rechte zu erteilen: (ALL) /etc/httpd/auto_configure_httpd (vor. standort meines scrits) (ALL) /bin/chown (ALL) /bin/chmod (ALL) /usr/sbin/chpasswd/ (ALL) /usr/sbin/useradd (ALL) /usr/sbin/rcapache
ich habe ein mulmiges Gefühl und denke, dass die perl Script oder c-programm Lösung die sicherere Möglichkeit ist?!
Weniger. Man muesste naemlich eben all die Pruefungen, die sudo mach selber schreiben. Und die Rechte lassen sich ja detaillierter vergeben. wwwrun localhost=(root) "/bin/chown /usr/local/httpd/htdocs/kundenserver/*" usw. Besonders auch mittels der Aliase (fuer Kommandos) sollte sich da was anstellen lassen. Leider kenne ich su1 nicht, weiss also nicht, ob das evtl. besser geeignet waere. Leider hab ich selbst noch kaum Ahnung von sudo, aber vielleicht hilft dir ja eine laengere Meditation ueber 'man sudoers' sowie ein paar tests ;)
Neben der Probelmatik, dass wwwrun zu "einem vollen Useraccount" wird, kann ich die Ausführung der freigegebenen suid Befehle nicht weiter kontrollieren - in einem shell/perl/c script/programm indes werden die Befehle nur im kontext (also tue das mit Datei X und nicht du darfst Befehl mit beliebiger Datei nutzen) ausgeführt!
Du kannst ja ein script _vor_ das sudo schalten, dass eben dies kontrolliert, perl im Taint-mode koennte da z.B. hilfreich sein, ein einfaches shellscript sollte aber auch gehen, nur muss man dann halt selber pruefen, ob man alle vom User eingegebenen Daten prueft. So in etwa also: - Pruefe Argumente (u.a. auf Sachen wie ';' '%' usw.) auf Korrektheit. - rufe sudo auf (sudo chown ... etc). Achso, eins ist mir noch eingefallen: Du koenntes evtl. das Problem umgehen, wenn du nicht die /etc/httpd/httpd.conf sondern .htacces (?) (usw.) oder auch spezifische confs in /etc/httpd/ verwendest, die dann eben nur von wwwrun lesbar sein muessen... Diese confs kannst du dann ja mittels 'include' einbinden... Das duerfe zumindest das script schonmal einfacher machen, aber natuerlich muss man auch da drauf achten, dass da nicht Unfug in der Datei landet. Dann sollte wohl ein einfaches 'echo > /etc/httpd/kundenserver.foo' oder auch 'cat <<EOF > ...' reichen... Zur Not koennte man aber immer noch ein (oder mehrere) C(++)-Programm(e) schreiben, die aber die DocRoot z.B. 'hartkodiert' drin hat: ==== kundenserver_chown.cc [C++ weil ich mit C-Strings adhoc nix sicheres hinbekomme ;( ] ==== #define HTTP_ROOT "/usr/local/httpd/htdocs/kundenserver/" int main(int argc, char * argv[]) { /* ... Parameter checken!!! */ string path = HTTP_ROOT; path += checked_arg_path; /* let C++ care about stringlengths ;) */ return chown(path, checked_arg_uid, checked_arg_gid); } ==== Ich wuerde aber erst versuchen, was mit sudo hinzubekommen! HTH, -dnh --
man tut ja was man kann, und wenn man mal was tut, was man nicht kann, tut man ja was man kann, dass das keiner merkt. Das klingt sehr weise. Ist das von Lao Tse? Nö. Von Mi Rse Lber [Jakob Krieger und Marian Wild in dag°]
participants (7)
-
B.Brodesser＠t-online.de -
Bertram Scharpf -
Christoph Maurer -
David Haller -
Konrad Neitzel -
Michael Hilscher -
suse-linux＠frodo.prima.de