cronjob hilfe

[BugMeNot]

Hallo community,

ich habe Debian 10 und darauf Jirafeau installiert, ein programm um files hoch und runter zu laden, ähnlich wie firefox send oder we transfer.

man kann dort ein verfalls datum angeben, ab wann die daten gelöscht werden sollen.
ich möchte jetzt gerne ein cron job ausführen, der es täglich prüft und ggf löscht.

sollte also folgendes ausführen:
sudo -u www-data php admin.php clean_expired

die das php script liegt unter
/var/data/jirafeau

ich habe leider nicht viel erfahrung mit cron und benutzerrechten. das script sollte ausgeführt werden können, um die entsprechenden daten zu löschen, die unter
/var/data/jirafeau
liegen.

natürlich möchte ich mir keine sicherheitslücke einbauen, dass es mit zu hohen rechten ausgeführt wird, falls das script mal manipuliert wird.

könntet ihr mir sagen, wie/ wo ich den cron task dafür erstelle und wie ich es "sicher" halten kann?

Gruss

[thoerb]

Code: Alles auswählen

0 0 * * *  cd /var/data/jirafeau/ && sudo -u www-data /usr/bin/php admin.php clean_expired

Ohne Gewähr, mit sudo kenne ich mich nicht aus.

natürlich möchte ich mir keine sicherheitslücke einbauen, dass es mit zu hohen rechten ausgeführt wird, falls das script mal manipuliert wird.

Edit: Wie sicher diese Software ist kann ich dir auch nicht sagen.

[TomL]

natürlich möchte ich mir keine sicherheitslücke einbauen, dass es mit zu hohen rechten ausgeführt wird, falls das script mal manipuliert wird.

Dann solltest Du auf das obligatorische "sudo" verzichten. Für einen simplen Up-/Download sind eigentlich keine root-Rechte erforderlich. Um ein fremdes Script, dass für so einfache Aufgaben jedoch zwingend root-Rechte verlangt, würde ich jedenfalls einen großen Boden machen ... weil das definitiv eine unkalkulierbare Sicherheitslücke ist.

[BugMeNot]

ok, vielen Dank für das Feedback, ich werde es wohl anders lösen

[cronoik]

Gegen das sudo ist hier nichts einzuwenden. Denn es wird nicht als root ausgefuehrt, sondern als www-data user (Parameter -u).

[TRex]

Gegen das sudo ist durchaus was einzuwenden - verwende nicht die crontab von root, sondern wahlweise die von www-data oder besser, eine neue Datei in /etc/cron/cron.d/, und trage dort den User www-data in die entsprechende Spalte ein. Dann läuft das gesamte Script in der Zeile mit www-data, und ein Benutzerwechsel ist unnötig.

[tobo]

Meiner Meinung nach widersprechen sich die letzten beiden Standpunkte nicht wirklich!? Unnötig ist das sudo, aber nicht sicherheitstechnisch falsch. Allerdings ist das 1. ohne sudo klarer und 2. ist eine Möglichkeit der Fehlkonfiguration weggenommen:
https://github.com/Newlode/jirafeau#how ... ired-files

Code: Alles auswählen

# m h dom mon dow user  command
12 3    * * *   www-data  php /path/to/jirafeau/admin.php clean_expired
16 3    * * *   www-data  php /path/to/jirafeau/admin.php clean_async

Das ist dann nicht die Crontab von root, sondern die des Systems!

[BugMeNot]

hallo tobo,

schön, dass du es dir genauer angesehen hast.

zu meinem verständnis, der cronjob wird dann zu Zeitpunkt x aktiv und führt das script mit den rechten des systems aus.
sollte jetzt das script durch ein update/ hacker was auch immer manipuliert werden zu... weiss doch auch nicht formatiere sda, was passiert, wenn der cron job dem system sagt, bitte ausführen. sind die rechte genügend, um schaden anzurichten?

ich bewege mich in linux/bsd eigentlich nur in klicki bunte web guis, könnte ich etwas starthilfe bekommen, wie ich den cronjob anlege, resp. wo?

[tobo]

zu meinem verständnis, der cronjob wird dann zu Zeitpunkt x aktiv und führt das script mit den rechten des systems aus.
sollte jetzt das script durch ein update/ hacker was auch immer manipuliert werden zu... weiss doch auch nicht formatiere sda, was passiert, wenn der cron job dem system sagt, bitte ausführen. sind die rechte genügend, um schaden anzurichten?

Selbstverständlich!

ich bewege mich in linux/bsd eigentlich nur in klicki bunte web guis, könnte ich etwas starthilfe bekommen, wie ich den cronjob anlege, resp. wo?

Du öffnest (als root angemeldet) mit einem Editor die Datei /etc/crontab und editierst den Cronjob als vorletzte Zeile hinein.
https://wiki.ubuntuusers.de/Cron/
Da steht drin, wo es hingehört und was es bedeuten soll.

[BugMeNot]

vielen Dank!

um sicher zu gehen:

via root:

Code: Alles auswählen

nano /etc/crontab

letzte zeile vor der# einfügen:

Code: Alles auswählen

12 3    * * *   www-data  php /var/data/jirafeau/admin.php clean_expired
16 3    * * *   www-data  php /var/data/jirafeau/admin.php clean_async

thats it?


nochmal zu dem ausführen von sem script, ich bin etwas irritiert von deinem selbstverständlich!

d.h. sollte sich das programm selbst updaten via git und das script wird dort verändert, ziehe ich es mir auf debian und lasse es ausführen und es wird auch alles so ausgeführt, was im script steht, es gibt demnach keine beschränkungen?

z.b. kann ssh zugang für einen neuen benutzer erstellt werden, firewall regeln auf debian umgebaut werden etc.?

Wenn das der fall ist, kann man doch unmöglich sowas benutzen

[tobo]

letzte zeile vor der# einfügen:

Code: Alles auswählen

12 3    * * *   www-data  php /var/data/jirafeau/admin.php clean_expired
16 3    * * *   www-data  php /var/data/jirafeau/admin.php clean_async

thats it?

Keine Ahnung! Das Ding läuft dann nachts um nach 3. Außerdem habe ich das lediglich aus deren FAQ kopieren - ich weiß nicht, ob
das ausreicht. Deine Umsetzung wäre dann aber richtig.

nochmal zu dem ausführen von sem script, ich bin etwas irritiert von deinem selbstverständlich!

d.h. sollte sich das programm selbst updaten via git und das script wird dort verändert, ziehe ich es mir auf debian und lasse es ausführen und es wird auch alles so ausgeführt, was im script steht, es gibt demnach keine beschränkungen?

z.b. kann ssh zugang für einen neuen benutzer erstellt werden, firewall regeln auf debian umgebaut werden etc.?

Wenn das der fall ist, kann man doch unmöglich sowas benutzen

Langsam - ich habe auch in keinster Weise gesagt, dass du das, wie auch immer angewendet, benutzen sollst! Ich habe mich inhaltlich damit überhaupt nicht befasst, sondern behauptet, dass das Ding, an der Stelle, mit den Rechten, potentiell Schaden anrichten kann.

[BugMeNot]

nochmal zu dem ausführen von sem script, ich bin etwas irritiert von deinem selbstverständlich!

d.h. sollte sich das programm selbst updaten via git und das script wird dort verändert, ziehe ich es mir auf debian und lasse es ausführen und es wird auch alles so ausgeführt, was im script steht, es gibt demnach keine beschränkungen?

z.b. kann ssh zugang für einen neuen benutzer erstellt werden, firewall regeln auf debian umgebaut werden etc.?

Wenn das der fall ist, kann man doch unmöglich sowas benutzen

Langsam - ich habe auch in keinster Weise gesagt, dass du das, wie auch immer angewendet, benutzen sollst! Ich habe mich inhaltlich damit überhaupt nicht befasst, sondern behauptet, dass das Ding, an der Stelle, mit den Rechten, potentiell Schaden anrichten kann.

das ist klar, man kann nicht erwarten, dass du dir das script anschaust.

mir ging es eigentlich nur darum zu wissen, ob das, was in dem script stehen könnte theoretisch mit rechten ausgeführt wird, die es ermöglichen systemkonfigurationen zu ändern.

Wenn nur der teil in /var/daten oder/www umgeschrieben werden kann, kann ich damit leben.

[TomL]

Wenn das der fall ist, kann man doch unmöglich sowas benutzen

Das Script kann die Rechte anwenden, mit denen es gestartet wird. Wird es mit root-Rechten gestartet, kann es beliebig das installierte System verändern. Wird es mit den Rechten eines unberechtigten Users gestartet, kann es das installierte System nicht verändern, sondern nur das, worauf dieser unberechtigte User Rechte hat.... im Regelfall sollte das nur sein eigenes Homedir sein - sofern er als virtueller User überhaupt eins hat.

Hat der (virtuelle o. reale) User, unter dessen UID das Script läuft, ein Recht das Script zu aktualisieren, kann sich also auch das Script selber außerhalb Deiner Kontrolle aktualisieren.

Wenn das Script also weder das System noch sich selber verändern können darf, muss das Script einfach nur unter einer UID laufen, die dazu keine Rechte hat. Du kannst mit htop nachsehen, unter welcher UID es läuft und dann prüfen, welche Rechte auf das Script bestehen. Im Vergleich dazu kannst Du beispielsweise in /usr/bin nachsehen, wie da die Rechte sind... ändernrechte hat dort immer nur root. Läuft ein Script aus einer Fremdquelle unter der UID 0 oder unter der UID eines Anwenders mit Admin-Berechtigung via aktiv angewandtem sudo ist das m.M.n. als brisant einzuschätzen.

Und wenn du verhindern möchtest, dass sich Scripte, die Du unter Deiner UID startest, Deine höherwertigen Admin-Rechte (durch sudo) erschleichen bzw. aneigenen können, solltest Du kein "sudo" verwenden.... wovon ich sowieso abrate.

[BugMeNot]

so wie ich es interpretiere läuft cron als root, php aber unter www-data

in der cron tab wird bei mir der nuter www-data angegeben, somit sollte das eigentlich passen. www-data sollte eigentlich bei der installation von nginx angelegt werden und somit auch nur in www-data zugriff haben, somit nicht systemweit.
bei der installation habe ich

Code: Alles auswählen

chown -R www-data:www-data /var/www/html/jirafeau/lib /var/data/jirafeau

rechte ausgeweitet.




ich denke das ist ok so oder wie seht ihr es?

[TomL]

so wie ich es interpretiere läuft cron als root,

Das ist völlig normal...

Code: Alles auswählen

$ ps -aux | grep cron
root      2211  0.0  0.0   8828  3120 ?        Ss   09:40   0:00 /usr/sbin/cron -f

...und absolut irrelevant. Maßgeblich ist, unter welcher UID das Script selber läuft. Wie ich sagte, das kannst Du mit htop nachsehen... oder alternativ mit:

Code: Alles auswählen

ps -aux | grep jirafeau

Ich würde die Script-Eigentums-Rechte auch nicht auf www-data setzen, sondern auf root, damit eben nur root eine Änderungsberechtigung hat. Wenn es dann unter der UID www-data läuft, hat diese UID keine Ändernrechte auf das Script. Die Eigentumsrechte haben nur eine sekundäre Relevanz für die Rechte, unter denen es letztlich ausgeführt wird.

Es ist wie mit anderen Programmen, die Du mit Deiner UID startest und die dann unter den Rechten Deiner UID laufen... sowie z.B. bei nano, das Du zwar starten kannst, aber die Eigentumsrechte auf die Datei 'nano' in /usr/bin trotzdem bei root liegen. Das heisst, Du kannst es zwar starten, aber Du kannst es mit Deinen Rechten nicht verändern.

[Meillo]

@BugMeNot:

Vielleicht mal als Grundsaetze:

1) Du willst, dass die Programme/Scripte auf deinem System mit den minimal noetigen Rechten ausgefuehrt werden.
2) Du willst, dass die Programme/Scripte auf deinem System mit den minimal noetigen Rechten geaendert werden koennen.

Wenn dein Script Dateien aendern/loeschen muss, die (nur) www-data aendern darf, dann wird es kaum umhin kommen auch als www-data zu laufen. (Das hast du fuer Cron ja schon umgesetzt.)

Die Scriptdateien selbst muessen nun auch noch so eingeschraenkte Rechte und Besitzer haben, dass nicht ein beliebiger User des Systems dort einfach boese Befehle reinschreibt, die dann von Cron als User www-data ausgefuehrt werden. (Poste dazu mal die derzeitigen Rechte der Scripte.)

Und nicht zuletzt musst du sicherstellen oder darauf vertrauen, dass die Autoren der Scripte dort nichts Boeses reingeschrieben haben. (Falls das Scripte eine Selbstupdatefunktion hat, dann vertraust du damit auch automatisch allen zukuenftigen Versionen, ... oder du sorgst dafuer, das das Script sich nicht selbst aendern kann, indem der ausfuehrende User (www-data) keine Schreibrechte auf die Scriptdatei und das umgebende Verzeichnis hat.)


Was generell Angriffsmoeglichkeiten angeht, so musst du unterscheiden was ein erfolgreicher Angreifer mit dem geknackten Account machen kann -- falls das externe Script also Schadcode enthaelt, dann kann dieser alles machen was der ausfuehrende User www-data auch machen kann --, und zum anderen, ob es Moeglichkeiten gibt die Rechte zu erweitern -- falls beispielsweise ein beliebiger User ein Script aendern kann, das unter einem hoeher priviligiertem User laeuft.


In diesem Themengebiet gibt es keine einfachen Antworten. Es handelt sich immer umkomplexe Sachverhalte, die man analysieren muss. Du merkst ja selber, dass die Antworten, die du bekommst nicht glar, einfach und abschliessend sind, sondern nur Betrachtungsweisen, Aspekte und Bausteine eines groesseren Gebildes, das letztlich nur du ueberblicken kannst, weil wir gar nicht genug Informationen haben um dies zu tun. Wir koennen nur dir dabei helfen es selber zu tun ... oder du muesstest jemand Vertrauenswuerdiges fuer ein (teures) Security-Audit engagieren.

[BugMeNot]

danke für die erklärungen.

bin heute den code durchgegangen und konnte nichts finden, was auf ein automatisches update hindeutet, somit sollte das File nicht mehr geändert werden.
debian läuft isoliert in einer VM, in einer DMZ, hinter einem reverse proxy. Security updates werden automtisch, täglich geprüft und ggf. geladen und installiert.

Meiner Meinung nach verbleibt ein recht kleines restrisiko.

ich denke, ich werde es dabei belassen.