Bonjour, G2PC, on 2020-05-08 18:06:36 +0200: > J'entends la proposition d'utiliser un utilisateur normal pour récupérer > le fichier. > mais ensuite, on utilise sudo ( manuellement ) pour déplacer le fichier > du /tmp vers /etc En fait, si d'aventure il y avait une tentative d'exploiter une vulnérabilité dans wget(1), alors cela n'affecterait que le compte qui aura lancé la commande. Évidemment, si le contenu du fichier téléchargé peut être affecté par la vulnérabilité en question, alors il y aurait fort à parier que la commande finale qui écrase le fichier système puisse poser problème. > De plus si on utilise ce script via crontab de root, le sudo ne sera pas > utilisé, et, éventuellement, on récupèrera le fichier directement via le > script lancé depuis la crontab de root, donc, en root. Il est possible de céder ses drois de super utilisateur, avec su(8) ou sudo(8) depuis un crontab(1) appartenant à root, en se rabaissant aux droits d'un utilisateur normal, par exemple au hasard nobody: su - nobody -c 'wget https://example.org/index.html -P /tmp' sudo -u nobody wget https://example.org/index.html -P /tmp Un détail auquel je n'ai pas pensé précédemment, la commande mv(1) conserve les utilisateurs et groupes, donc il faudra penser attribuer le fichier à root et au groupe root avec chown(1) avant de déplacer le fichier ou bien lancer à nouveau une commande cp(1). Comme quoi, en quatre ligne, il y a tout de même des choses à dire... :) > > Tout cela suppose que vous faites confiance au service délivré > > par hosts.ubuntu101.co.za pour ne pas mettre n'importe quoi dans > > votre /etc/hosts.deny, cat ils seraient en position de rendre > > votre machine inaccessible en mettant l'Internet complet dans ce > > fichier. > > C'est certain et effectivement, il me faut ici faire confiance au > contenu, ce qui peut être affiné, je suppose avec des contrôles de > certificats, ou, une politique de controle de /md5sum, ou les deux, et, > peut être encore d'autres choses./ md5sum(1) permet de vérifier l'intégrité du fichier, pour s'assurer qu'il n'y a pas eu de morceaux perdus ou corrompus pendant le transfert. Mais oui, il y a d'autres possibilités: j'utilise gpg(1) pour vérifier à la fois l'intégrité et l'autenticité de certains fichiers, pour m'assurer qu'ils ont bien été construits par la personne qui a signé l'archive ; sachant que même avec cette technique, il peut y avoir des ratés. Lisez plutôt la page suivante pour un cas rencontré dans la vie réelle : https://www.kernel.org/category/signatures.html Le gestionnaire de paquets APT utilise d'ailleurs cette méthode pour s'assurer que le dépôt ou les paquets ont bien été construits par les développeurs Debian, et pas quelqu'un autre ; d'où les questions de configuration de GPG apparaissant dans le fil de discussion « reprepro » lancé par Marc Chantreux. Malgré la mise en place de cette technique, ça n'a pas empêché un incident fâcheux avec apt l'an dernier : https://www.debian.org/security/2019/dsa-4371 Amicalement, -- Étienne Mollier <etienne.mollier@mailoo.org> Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * Rosetta@home: https://boinc.bakerlab.org/rosetta/ * Folding@home: https://foldingathome.org/
Attachment:
signature.asc
Description: PGP signature