nicht angemeldet
setuid (wrapper und perl-script problem)
Hallo zusammen,
ich habe im Forumsarchiv gesucht und habe zu meinem problem leider keine Lösung gefunden. Ich habe Probleme mein perl-skript mit setuid auszuführen.
Folgendes habe ich gemacht:
-
c-wrapper geschrieben, der mit system("pfad/zum/script"); mein perl-script aufruft
-
c-wrapper mit gcc compiliert und in test.cgi umbenannt
-
chmod 4711 test.cgi
-
in meinem perl-script soll iptables-restore, bzw. iptables-save ausgeführt werden (jeweils mit system())
-
das perl-script erstellt ein login-formular (form-action: test.cgi)
-
chmod 755 perl-script.pl (700 funktioniert nicht, weiß nicht warum)
mein wrapper ruft das perl-script auf und es erscheint mein login-formular. beim bestätigen des formulars mit korrekten zugangsdaten soll dann iptables-xxx ausgeführt werden. rückgabewert von system("iptables-xxx /pfad/zur/datei"); ist aber -1.
das mod-suexec vom apache ist gestartet. ich versteh nicht, warum er trotz gesetztem s-bit beim wrapper immer noch nix macht.
kann mir jemand helfen?
grüße
tobias
-
Hi,
- c-wrapper geschrieben, der mit system("pfad/zum/script"); mein perl-script aufruft
Und system() gibt hier keinen Fehler zurück?
- c-wrapper mit gcc compiliert
Ausgabe von 'uname -a' und 'gcc --version'?
Irgendwelche Sicherheitspatches in die GCC oder den Kernel eingespielt?- chmod 4711 test.cgi
Ausgabe von 'chmod -v 4711 test.cgi'?
- in meinem perl-script soll iptables-restore, bzw. iptables-save ausgeführt werden (jeweils mit system())
Warum auch immer, aber gut.
- das perl-script erstellt ein login-formular (form-action: test.cgi)
Ich hoffe doch schwer, das das nur im Intranet passiert, oder?
- chmod 755 perl-script.pl (700 funktioniert nicht, weiß nicht warum)
Nun, das 700 nicht funktioniert sollteeinem doch schon zu denken geben,oder?
Was funktioniert denn nicht? Mag chmod nicht oder funktioniert das Skript/der Wrapper danach nicht mehr?mein wrapper ruft das perl-script auf
Ist das Perlscript ausführbar? Wenn nicht: stimmt der Aufruf?
und es erscheint mein login-formular. beim bestätigen des formulars mit korrekten zugangsdaten soll dann iptables-xxx ausgeführt werden. rückgabewert von system("iptables-xxx /pfad/zur/datei"); ist aber -1.
Perls system() gibt die Meldungen von wait(2) zurück, das setzt errno im Fehlerfalle, also: mit welcher Fehlermeldung?
das mod-suexec vom apache ist gestartet.
Das hast Du wie geprüft?
so short
Christoph Zurnieden
-
Hi,
- c-wrapper geschrieben, der mit system("pfad/zum/script"); mein perl-script aufruft
Und system() gibt hier keinen Fehler zurück?
nein
- c-wrapper mit gcc compiliert
Ausgabe von 'uname -a' und 'gcc --version'?
Irgendwelche Sicherheitspatches in die GCC oder den Kernel eingespielt?gcc --version = gcc (GCC) 3.3.4 (pre 3.3.5 20040809)
uname -a = Linux wlanauth 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 i686 i386 GNU/Linux
neuinstallation von suse 9.2 ohne patches
- chmod 4711 test.cgi
Ausgabe von 'chmod -v 4711 test.cgi'?
mode of `test.cgi' changed to 4711 (rws--x--x)
- in meinem perl-script soll iptables-restore, bzw. iptables-save ausgeführt werden (jeweils mit system())
Warum auch immer, aber gut.
ein user kann über das formular seine ip in iptables eintragen.
erfolgreiche anmeldung (mysql-db abfrage) -> eintrag in iptables- das perl-script erstellt ein login-formular (form-action: test.cgi)
Ich hoffe doch schwer, das das nur im Intranet passiert, oder?
user aus einem wlan sollen über uns (firma) ins internet. dafür müssen sie sich an dem rechner, auf dem dieses script läuft erfolgreich anmelden.
- chmod 755 perl-script.pl (700 funktioniert nicht, weiß nicht warum)
Nun, das 700 nicht funktioniert sollteeinem doch schon zu denken geben,oder?
Was funktioniert denn nicht? Mag chmod nicht oder funktioniert das Skript/der Wrapper danach nicht mehr?ich dachte eigentlich, dass durch das s-bit beim wrapper nun nur noch die rechte für den besitzer des scripts benötigt werden.
die meldung lautet (bei 700): perl-script.pl: permission deniedmein wrapper ruft das perl-script auf
Ist das Perlscript ausführbar? Wenn nicht: stimmt der Aufruf?
ich habe den pfad zu iptables-xxx angegeben. er führt es nun aus aber die datei, in die er schreiben soll ist leer.
der aufruf sieht nun so aus:
system("/usr/sbin/iptables-save > /var/lib/filters");
und es erscheint mein login-formular. beim bestätigen des formulars mit korrekten zugangsdaten soll dann iptables-xxx ausgeführt werden. rückgabewert von system("iptables-xxx /pfad/zur/datei"); ist aber -1.
Perls system() gibt die Meldungen von wait(2) zurück, das setzt errno im Fehlerfalle, also: mit welcher Fehlermeldung?
perls system gibt jetzt 256 zurück.
das mod-suexec vom apache ist gestartet.
Das hast Du wie geprüft?
nach start des apache2 steht im error log folgendes:
[Tue Dec 07 15:04:28 2004] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
[Tue Dec 07 15:04:29 2004] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
[Tue Dec 07 15:04:30 2004] [notice] Apache/2.0.50 (Linux/SUSE) configured -- resuming normal operationsso short
Christoph Zurnieden
hoffe, du verstehst was ich meine.
gruß
tobi-
Hi,
- in meinem perl-script soll iptables-restore, bzw. iptables-save ausgeführt werden (jeweils mit system())
Warum auch immer, aber gut.
[...]
user aus einem wlan sollen über uns (firma) ins internet. dafür müssen sie sich an dem rechner, auf dem dieses script läuft erfolgreich anmelden.
Und was hat dann IPTables damit zu tun? Was hat ein normaler User in der Firewall zu fummeln?
Nein, das muß alles im Userspace laufen und das kann auch alles im Userspace laufen. Es gibt einige Howtos für eine WLAN-Sicherung im Netz, folge denen und laß den fußnägelaufrollenden Unsinn mit den SUID-Scripts.
http://www.linux-wlan.org/
http://wlsec.net/
http://wlan.informatik.uni-bremen.de/doku/debian/
http://board.protecus.de/showtopic.php?threadid=8751
Etwas ältlich:
http://130.149.232.81/~hildmann/wvlan-config/prz-wlan-howto.pdfVielleicht hat ja auch einer der hier Postenden Erfahrungen damit (ich kenn sogar einen, der bietet Kurse dazu an ;-)
so short
Christoph Zurnieden
-
Hallo, vielen Dank schonmal für die Links!
Hi,
Und was hat dann IPTables damit zu tun? Was hat ein normaler User in der Firewall zu fummeln?
Unsere Firewall blockt halt erstmal alle IP's des Wlans. Außerdem existiert eine DB mit Usernamen und Kennwörtern. Wenn jetzt jemand ein gültiges Passwort + Usernamen hat und sich anmeldet, soll seine IP im Firewallscript freigeschaltet (in die forward-chain) werden.
Der Rückweg soll genauso möglich sein. Mit nem Logout, oder Ablauf der Session, soll die IP wieder geblockt werden.
Wir haben uns an Open-Source-Radius-Servern für Linux schon versucht. Da findet sich auch nix tolles. Wegen nicht vorhandener Dokus und Infos haben wir das dann abgebrochen.Kann man das mit den u.g. Links realisieren? Ich steh halt etwas auf dem Schlauch. Gibts ne sinnvollere Lösung?
Nein, das muß alles im Userspace laufen und das kann auch alles im Userspace laufen. Es gibt einige Howtos für eine WLAN-Sicherung im Netz, folge denen und laß den fußnägelaufrollenden Unsinn mit den SUID-Scripts.
http://www.linux-wlan.org/
http://wlsec.net/
http://wlan.informatik.uni-bremen.de/doku/debian/
http://board.protecus.de/showtopic.php?threadid=8751
Etwas ältlich:
http://130.149.232.81/~hildmann/wvlan-config/prz-wlan-howto.pdfVielleicht hat ja auch einer der hier Postenden Erfahrungen damit (ich kenn sogar einen, der bietet Kurse dazu an ;-)
so short
Christoph Zurnieden
Grüße
Tobias-
Hi,
Und was hat dann IPTables damit zu tun? Was hat ein normaler User in der Firewall zu fummeln?
Unsere Firewall blockt halt erstmal alle IP's des Wlans.
Ja, eine Whitelist ist natürlich bequem, das ist wahr. Auch ist es durchaus Usus und auch empfohlen Firewalls erstmal ganz dicht zu machen und dann erst gezielt Ein- bzw Auslaß zu gewähren. Eine Withelist also.
Aus Sicherheitsgründen sollte eine Firewall auch so nah wie möglich eingestellt werden, d.h. am besten mit der seriellen Konsole im Serverraum. Das geht natürlich selten. Aber auch bei Remotbedienung sollten so wenig wie möglich Bediener vorhanden sein und auch gute Kryptographie beim Login (Nicht nur einfach SSH, sondern z.B. SSH mit RSA Anmeldung o.ä.).
Das Schlimmste was Du machen kannst ist aber die unbeaufsichtigte Änderung an den Einstellungen der Firewall: also in Deinem Fall über eine andere Maschine und ein Script von jedem User der ein Paßwort hat oder anderweitig Zugriff. Letzteres ist es, das einem dabei die Fußnägel kräuselt.
Das ist also vollkommen tabu, aber das macht nichts.Wieviele Leute können sich denn an den Anschluß anhängen ohne das es lahmt? Da ich keine Ahnung habe, wie dick die Pipe ist, setze ich die Anzahl einfach mal willkürlich auf 25 fest. Warum machst Du das bei der Firewall nicht genauso und setzt 25 IPs fest? Die verteilst Du dann über den WLan-Server. Sind keine mehr da, ist's halt Essig mit einloggen (aussagekräftige Fehlermeldung nicht vergessen!)
Wir haben uns an Open-Source-Radius-Servern für Linux schon versucht. Da findet sich auch nix tolles. Wegen nicht vorhandener Dokus und Infos haben wir das dann abgebrochen.
Ja, das kann ich gut verstehen, das ist verdammt nicht einfach.
Kann man das mit den u.g. Links realisieren? Ich steh halt etwas auf dem Schlauch. Gibts ne sinnvollere Lösung?
Ob meine die sinnvollste, weiß ich nicht, ich habe da keine Erfahrung (betreue nur Firmennetze, da ist WLan nicht sicher einsetzbar bzw gibt mehr Kopfschmerzen als Vorteile), aber einer der Links ist das Clienthowto einer Uni. Davon habe ich so einige gefunden, deshalb würde ich vorschlagen, einfach mal da anzufragen. Schließlich sind es auch Deine Steuergelder, die das finanzieren! ;-)
Aber um Deine erste Frage zu beantworten: ich würde mit diesen beiden Links
und Google einen WLan Server einrichten können, ja. Aber ich bin nicht Du und es gibt viele Gründe damit nicht zurecht zu kommen.
Aber ich hoffe ja immer noch, das sich jemand aus dem Forum erbarmt, der sich damit auskennt.
Also: der Anbieter eines Kursus bezüglich WLan residiert auf fastix.org, hier im Forum gibt es jemanden mit dem Nickname fastix, ob die beiden evt zusammengehören?so short
Christoph Zurnieden
-
Hallo
Ja, eine Whitelist ist natürlich bequem, das ist wahr. Auch ist es durchaus Usus und auch empfohlen Firewalls erstmal ganz dicht zu machen und dann erst gezielt Ein- bzw Auslaß zu gewähren. Eine Withelist also.
Aus Sicherheitsgründen sollte eine Firewall auch so nah wie möglich eingestellt werden, d.h. am besten mit der seriellen Konsole im Serverraum. Das geht natürlich selten. Aber auch bei Remotbedienung sollten so wenig wie möglich Bediener vorhanden sein und auch gute Kryptographie beim Login (Nicht nur einfach SSH, sondern z.B. SSH mit RSA Anmeldung o.ä.).
Das Schlimmste was Du machen kannst ist aber die unbeaufsichtigte Änderung an den Einstellungen der Firewall: also in Deinem Fall über eine andere Maschine und ein Script von jedem User der ein Paßwort hat oder anderweitig Zugriff. Letzteres ist es, das einem dabei die Fußnägel kräuselt.
Das ist also vollkommen tabu, aber das macht nichts.Wieviele Leute können sich denn an den Anschluß anhängen ohne das es lahmt? Da ich keine Ahnung habe, wie dick die Pipe ist, setze ich die Anzahl einfach mal willkürlich auf 25 fest. Warum machst Du das bei der Firewall nicht genauso und setzt 25 IPs fest? Die verteilst Du dann über den WLan-Server. Sind keine mehr da, ist's halt Essig mit einloggen (aussagekräftige Fehlermeldung nicht vergessen!)
Wir haben zur Zeit eine 4mbit Anbindung. Die Anzahl der Zugriffe sollte keine Rolle spielen. Der Wlan-Access-Point ist DHCP. Er verteilt Ip's aus einem Netz, z.b. 192.168.100.0. Diese IP's sind dann im Script gesperrt (von 192.168.100.1 bis 192.168.100.254).
Wenn sich jemand am Acces-Point anmeldet zieht er eine IP, die ja noch gesperrt ist. Klar. Es könnte ja jeder kommen und sich am Acces-Point anmelden.Wir wollen durch die zusätzliche Abfrage eines Usernamens + Kennwort sicher stellen, dass der User "rein" darf. Dann erst soll die Ip im Script freigeschaltet werden.
Ich werde mich unter deinen Links mal schlau machen und hoffe auf fastix.
Vielen Dank!
Grüße
Tobias-
Hi,
Wir haben zur Zeit eine 4mbit Anbindung. Die Anzahl der Zugriffe sollte keine Rolle spielen. Der Wlan-Access-Point ist DHCP. Er verteilt Ip's aus einem Netz, z.b. 192.168.100.0.
Also soweit schon alles fertig? Wo liegt dann das Problem?
Betriebsblind? Ja, das kann passieren, passiert mir auch oft genug, also nochmal:Diese IP's sind dann im Script gesperrt (von 192.168.100.1 bis 192.168.100.254).
Wie wäre es, wenn Du die nicht sperrst, sondern als einzige zuläßt?
Wenn sich jemand am Acces-Point anmeldet zieht er eine IP, die ja noch gesperrt ist. Klar. Es könnte ja jeder kommen und sich am Acces-Point anmelden.
Es _kann_ _jeder_ kommen und sich am Accesspoint anzumelden versuchen! Die Frage ist nur, wie weit er dann kommt. Bis zm Accesspoint hat er nur einen Login (auf welcher Basis auch immer, Du hast z.B. eine Webserver laufen und bedienst per Browser). Da steht er nun und kommt aber nicht weiter, wenn er die Zauberworte nicht kennt. Login failed, keine IP. Da Du aber per Browser das Login machen möchtest, brauchst Du einen Webserver und damit auch eine IP für den Clienten. Auch kein Problem, dann verfällt die IP eben wieder, wenn das Login verfehlt wurde (Vorsicht: Gefahr von (D)DoS!).
Das Login schaltet dann nicht die IP frei, sondern den Zugang. Das ist aber alles etwas fummelig, warum nutzt Du kein Protokol, das die IP erst zuweist, wenn das Login erfolgreich ist? Wenn ich mich bei meinem Provier einwähle, geht das doch auch? Gut, ob PPP (RFC 1661, siehe http://www.linux-magazin.de/Service/Books/Buecher/Netzwerk/netz0808.htm für den Client und http://www.linux-magazin.de/Service/Books/Buecher/Netzwerk/netz0810.htm ff. für den Serverbetrieb. Das ganze Buch ist übrigens zu empfehlen, vor allem wegen des Preises ;-) das richtige Protokol für Deine Zwecke ist, weiß ich nicht, wäre aber eine Möglichkeit.Die Uni Münster mit ihrem Bürgernetz:http://twiki.org/cgi-bin/view/Sandbox/FhMuensterSandbox
Ich werde mich unter deinen Links mal schlau machen und hoffe auf fastix.
Letzte Meldung von ihm datiert auf den 5. diesen Monats, mit ein wenig Pech ist der in Urlaub.
so short
Christoph Zurnieden
-
Es _kann_ _jeder_ kommen und sich am Accesspoint anzumelden versuchen! Die Frage ist nur, wie weit er dann kommt. Bis zm Accesspoint hat er nur einen Login (auf welcher Basis auch immer, Du hast z.B. eine Webserver laufen und bedienst per Browser). Da steht er nun und kommt aber nicht weiter, wenn er die Zauberworte nicht kennt. Login failed, keine IP. Da Du aber per Browser das Login machen möchtest, brauchst Du einen Webserver und damit auch eine IP für den Clienten. Auch kein Problem, dann verfällt die IP eben wieder, wenn das Login verfehlt wurde (Vorsicht: Gefahr von (D)DoS!).
Das Login schaltet dann nicht die IP frei, sondern den Zugang. Das ist aber alles etwas fummelig, warum nutzt Du kein Protokol, das die IP erst zuweist, wenn das Login erfolgreich ist? Wenn ich mich bei meinem Provier einwähle, geht das doch auch? Gut, ob PPP (RFC 1661, siehe http://www.linux-magazin.de/Service/Books/Buecher/Netzwerk/netz0808.htm für den Client und http://www.linux-magazin.de/Service/Books/Buecher/Netzwerk/netz0810.htm ff. für den Serverbetrieb. Das ganze Buch ist übrigens zu empfehlen, vor allem wegen des Preises ;-) das richtige Protokol für Deine Zwecke ist, weiß ich nicht, wäre aber eine Möglichkeit.Das klingt alles ziemlich einleutend. Leider ist es anders gewünscht. Es gibt ein Wlan, in dem alle, die sich darin bewegen, eine Ip per Dhcp zugewiesen bekommen. Das ist auch alles schön. Die können da unter sich in ihrem Netz tun und lassen was sie wollen. Aber nur da.
Wenn jetzt einer ins Internet will, dann soll festgestellt werden, ob er es darf. Er muss dann ein Netz weiter durch eine Firewall. Irgendwie muss ja dieser Firewall gesagt werden: Hallo ich habe gültige Benutzerdaten und möchte mit meiner IP (die ich hier im Wlan benutze) durch dich ins Internet.Das ist gewünscht. Vielleicht habe ich es vorher etwas umständlcih beschrieben.
Viele Grüße
Tobias-
Hi,
Das klingt alles ziemlich einleutend. Leider ist es anders gewünscht. Es gibt ein Wlan, in dem alle, die sich darin bewegen, eine Ip per Dhcp zugewiesen bekommen. Das ist auch alles schön. Die können da unter sich in ihrem Netz tun und lassen was sie wollen. Aber nur da.
Ah ....
Wenn jetzt einer ins Internet will, dann soll festgestellt werden, ob er es darf.
... ha!
Ja, das ist natürlich etwas anderes. Es braucht also eine extra Authorisierung, wenn einer in's Netz möchte. Ein Recht, auf's Netz zuzugreifen, wenn mir der Wink mit dem Zaunpfahl gestattet ist.Er muss dann ein Netz weiter durch eine Firewall.
Ja, das ist löblich. Soweit.
Irgendwie muss ja dieser Firewall gesagt werden: Hallo ich habe gültige Benutzerdaten und möchte mit meiner IP (die ich hier im Wlan benutze) durch dich ins Internet.
Nein, an der Firewall wird nicht's dynamisch geändert, das ist absolut tabu. Dann kannst Du sie genausogut abschalten, dann ist sie nix mehr wert. Spar Dir den Strom.
Das ist gewünscht.
Von wem? Bist Du Dir auch sicher, das genau das gewünscht wurde oder nur, das es ein extra Kärtchen braucht in's Internet zu dürfen? Bei letzterem kannst Du das mit einem einfachem (transparentem) Proxy erledigen. Die Leute, die in's Netz dürfen, bekommen auch Zugriff auf den Proxy, die anderen nicht. Der Proxy ist dann der einzige, der Zugang zum Netz hat. Du könntest sogar einen cachenden Proxy zwischenschalten z.B. squid o.ä. Wenn Du nicht weißt, was squid ist, solltest Du aber die Finger davon lassen, ist nicht unbedingt etwas für den Eiligen ;-)
Wenn das so ungefähr gewollt ist, kann ich ja mal ein paar entsprechende Links zusammensuchen. Muß ja nicht unbedingt ein Proxy sein, das geht bestimmt auch einfacher, dafür müßte ich allerdings dann nachschlagen.
Vielleicht habe ich es vorher etwas umständlcih beschrieben.
Das macht nix. Wenn Du jetzt mit G. Grass unterschrieben hättest, dann, ja ... aber so ;-)
so short
Christoph Zurnieden
-
Wenn das so ungefähr gewollt ist, kann ich ja mal ein paar entsprechende Links zusammensuchen. Muß ja nicht unbedingt ein Proxy sein, das geht bestimmt auch einfacher, dafür müßte ich allerdings dann nachschlagen.
Gewünscht ist es vom Chef. Egal. Es muss eine Stelle geben, an der ich auch den Zugang sperren kann. D.h. Dass ich gewisse Ip's, bzw. Benutzer ausschließen könnte, wenn sie sich denn nicht benehmen. Oder, dass ich jemanden rauswerfen kann.
Also eine Stelle an der steht wer sich im Internet aufhält, um es zu kontrollieren.
Jemand MUSS seine Zugangsdaten angeben um ins Internet zu kommen, was er vorher im Wlan betreibt interessiert uns nicht.
Ich weiß nicht in wie weit ein Proxy das kann...?Vielleicht habe ich es vorher etwas umständlcih beschrieben.
Das macht nix. Wenn Du jetzt mit G. Grass unterschrieben hättest, dann, ja ... aber so ;-)
Dafür hat's nicht gereicht...;o)
-
Hi,
Wenn das so ungefähr gewollt ist, kann ich ja mal ein paar entsprechende Links zusammensuchen. Muß ja nicht unbedingt ein Proxy sein, das geht bestimmt auch einfacher, dafür müßte ich allerdings dann nachschlagen.
Gewünscht ist es vom Chef.
Ja, hatte es schon befürchtet ;-)
Jemand MUSS seine Zugangsdaten angeben um ins Internet zu kommen, was er vorher im Wlan betreibt interessiert uns nicht.
Aha, das ist doch schon mal eine deutlich umgrenzte Aufgabenstellung, gut.
Ich weiß nicht in wie weit ein Proxy das kann...?
Das Proxy kann gar nichts, das ist nur die Tüt mit Schloß. Um die Verteilung der Schlüssel mußt Du Dich selber kümmern und zwar ganz normal per Login. Das ist ja auch schon fertig und muß nur noch entsprechend umgebogen werden.
Anstatt also jedesmal die Firewall durcheinander zu würfeln, gibts Du einfach nur den Zugang auf den Proxy frei.
Das kannst Du loggen und beeinflussen (aka rausschmeißen).
Wenn das in Echtzeit passieren soll kann das per Application-Firewall geschehen, da viele der Gründe für einen Rausschmiss wahrscheinlich global sind, für jeden gleich, oder? Individuell (bei Abgang, zu oft daneben benehmen o.ä.) ist das auch simpel.Ja, erscheint mir insgesamt die preiswerteste Lösung.
Eien genaue Anleitung dafür kann ich Dir natürlich nicht geben, dafür fehlen mir nicht nur die Einzelheiten, das würde auch den Rahmen hier sprengen. Aber bei einzelnen Schwierigkeiten sind wir gerne weiter behilflich.
Puh, nä, habe ich mich da jetzt klar genug ausgedrückt? Bezweifele es etwas. Frag' einfach nochmal nach, wenn etwas allzu unverständlich sein sollte.
so short
Christoph Zurnieden
-
-
-
-
-
-
-