Cronjobs erstellen geht das ?

    Quote from BeNe


    Zu dem Thema Sicherheit, hier hab ich jetzt noch nicht verstanden wo es "unsicher" sein soll ?
    Ob jetzt ein Script zu einer bestimmten Uhrzeit angestoßen wird, oder das Script manuell durch einen Besuch einer bestimmte Seite passiert ist doch völlig egal.
    Der CronJob muss als vu2xxx User laufen, damit hat der Kunde die gleichen Rechte wie sonst auch.


    Das siehst du falsch. Wenn ich etwas per CJ ausführe, dann ist das eine CLI-Ausführung und dafür braucht es im Gegenzug wieder eine eigene php.ini. Dazu kommt, dass ein CJ ja keinesfalls auf .php beschränkt ist. Es können auch Shell/Perl/Python und sonstige Scripte ausgeführt werden. Und diese sind, zumindest auf meinem Webserver, keineswegs per Webaufruf triggerbar. Insofern kannst du dem Benutzer, dem du CJs gewähren willst, auch einfach einen SSH-Zugang (ohne chroot) auf deinem Server geben. Sicherheitstechnisch kommts aufs Gleiche raus - lediglich ne GUI gibts da halt nicht.

    Im Grunde kann man das auch wieder vorbeugen mit dem CJ frei geben und dann wieder ändere ... in dem einfach dem Script gesagt wirte es soll Prüfen wenn was geänderte wurden ist wenn ja muss es zu Freigabe gesperrte werden.

    Quote from biologist


    Das siehst du falsch. Wenn ich etwas per CJ ausführe, dann ist das eine CLI-Ausführung und dafür braucht es im Gegenzug wieder eine eigene php.ini. Dazu kommt, dass ein CJ ja keinesfalls auf .php beschränkt ist. Es können auch Shell/Perl/Python und sonstige Scripte ausgeführt werden. Und diese sind, zumindest auf meinem Webserver, keineswegs per Webaufruf triggerbar. Insofern kannst du dem Benutzer, dem du CJs gewähren willst, auch einfach einen SSH-Zugang (ohne chroot) auf deinem Server geben. Sicherheitstechnisch kommts aufs Gleiche raus - lediglich ne GUI gibts da halt nicht.


    Man kann aber:
    1. die Skripte unter dem User:Gruppe ausführen, wodurch die Rechte eingeschränkt wären
    2. nur eine php-Ausführung erlauben (was Anderes ergibt derzeit auch keinen Sinn, da nur php unterstützt wird)
    3. anstatt es über die passenden Services zu machen, nur eine Webausführung (wget) auf die vorhandenen Domains erlauben, wodurch 1. und 2. entfällt, denn dann werden nur die Skripte ausgeführt, welche der User sowieso schon selber anpingen könnte.


    Ich plädiere sogar für Dritteres, weil das die bequemste und sicherste Variante ist. Wenn python mal unterstützt wird, muss man die Cronjob-Funktionalität z.B. nicht mal erweitern. Aber da werden sich die Entwickler schon Gedanken drum machen.

    Quote from Ninos

    Man kann aber:
    1. die Skripte unter dem User:Gruppe ausführen, wodurch die Rechte eingeschränkt wären
    2. nur eine php-Ausführung erlauben (was Anderes ergibt derzeit auch keinen Sinn, da nur php unterstützt wird)
    3. anstatt es über die passenden Services zu machen, nur eine Webausführung (wget) auf die vorhandenen Domains erlauben, wodurch 1. und 2. entfällt, denn dann werden nur die Skripte ausgeführt, welche der User sowieso schon selber anpingen könnte.


    Ich plädiere sogar für Dritteres, weil das die bequemste und sicherste Variante ist. Wenn python mal unterstützt wird, muss man die Cronjob-Funktionalität z.B. nicht mal erweitern. Aber da werden sich die Entwickler schon Gedanken drum machen.


    Kommt schon Leute... Perl aufzurufen ist jetzt schon per Webzugriff möglich, sofern die richig (falschen/schlechten) PHP-Einstellungen gemacht wurden! Beispiel...


    hello.pl


    Mit Inhalt:

    Perl
    1. #!/usr/bin/perl print "Hello World!\n";


    Dann eine test.php:

    PHP
    1. <?php passthru("./hello.pl");?>


    Und dann ruft Ihr mal das PHP-Skript mit dem Browser auf.


    Gut, "passthru" muss aktiv sein in diesem Beispiel... Aber es soll ja auch nur verdeutlichen, dass perl / ls / cat und viele weitere Tools mit den entsprechenden PHP-Einstellungen (über I-MSCP einstellbar, je nach Einstellung sogar durch den Endkunden) zugreifbar sind und sich damit die Diskussion über Sicherheit (oder besser gesagt: "security through obscurity") erledigt hat!


    exec muss ja sogar teilweise aktiv sein, da gewisse Webframeworks dies voraussetzen (z.B. für Zugriff auf ImageMagick)!


    Wollt Ihr noch ein Beispiel? Dann enabled mal passthru und erstellt folgende PHP-Datei:


    PHP
    1. <?php
    2. passthru("/bin/cat /etc/passwd");
    3. ?>


    Und jetzt? 8|<X Seid Ihr euch immer noch so sicher, das nur PHP unterstützt wird? :thumbup: Durch eine Falsch-Konfiguration (es braucht z.B. nur ein falsch deaktiviertes "disable_functions") kann man Tür und Tor für solche Spielereien liefern! :thumbsup:


    @Ninos : Bei Punkt 3 muss ich Dir wiedersprechen. Typo3 Crons müssen teilweise in der Shell ausgeführt werden zwecks Parameter-Übergabe. Aber es ist sicherlich der bessere Weg als jedem einfach die Welt in die Hand zu drücken... ;) Von daher wäre es ebenfalls meine präferierte Wahl! :thumbsup:


    Greez

    Ja Also im Großen und ganzen kann man so viel wie man es will an der Sicherheit arbeiten wenn was falsche ein Gestelle wurden ist kann man auch per CJ / Perl oder auch Ajax / java schon Großen schaden anrichten.

    Also das halte ich jetzt für arg konstruiert. Es braucht auch nur ein schlechtes root-PWD und schon kann sich jeder als root einloggen :-P


    - passthru ist bei mir deaktiviert (bei imscp soweit ich weiß auch per default), Gleiches gilt für system() exec() & Co
    - imagemagick kann man übrigens auch als PHP-Extension einbinden


    @Ninos:
    Zu 1) Also das ist wirklich Mindestvoraussetzung :-) Aber wie gesagt: die Möglichkeiten sind dann die Gleichen wie auch in der Shell.
    Also Fakt ist: wenn du das *sicher* machen willst, musst du die Möglichkeiten extrem einschränken und dann ist es halt auch kein wirklicher CJ mehr. Was man meines Erachtens gefahrenlos machen kann: biete den Usern eine Möglichkeit eine (lokale!) URL anzugeben, die zu (vom User) definierten Zeitpunkten aufgerufen wird. Darüber könnten quasi Autotrigger für PHP-Scripts realisiert werden, die sowas machen wie: erstelle ein Backup der DB und kopiere es in Verzeichnis xyz. Ist dann aber für mich kein CJ, sondern ein Trigger für Dinge, die man jederzeit auch von extern ausführen könnte.

    Denke das es nur sinn macht wenn das SSH Jailkit als Addon fertig ist.
    Damit würde der CronJob innerhalb der Jail als vu2xxx User laufen.
    Das hier wäre damit nicht mehr möglich

    Code
    1. passthru("/bin/cat /etc/passwd");


    um die Daten aller User anzuzeigen.


    "wget" alleine als CronJob funktion wäre etwas schwach finde ich.

    Da gebe ich dir recht @BeNe im Grunde sollten wir alle erst mal abwarten was bei der neuen Version raus komme , und so lange muss man halte auf anfrage machen oder eine andere Lösung finden wie man es machen kann .