Pasque wget a des vulnérabilités aussi. Nom d'un gruyère !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.
Je ne sais pas ou tu a copier l'explication mais droits prend un " t " ;)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:
" il faudra penser A attribuer " -> Les traductions ont des failles ;)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).
Vu,
Je suis passé de 4 à 7/10 lignes.
Si ça me semble correcte pour un lancement à la main, je ne sais
plus trop ou j'en suis pour un lancement du même script depuis la
crontab de root.
Mon script tel que proposé ici utilise sudo cp et par la suite
sudo -s
Lors d'une tache administrative lancée depuis la crontab de root,
puis je laisser le script ainsi, ou, faudrait t'il faire
disparaître les sudo et les sudo -s
Je pense que cela fonctionnerait avec les sudo comme ci-dessous,
mais, par contre, est ce qu'ils ont encore du sens dans un script
lancé par root .
Noter que j'ai bien lu ton explication, su ou sudo pourraient /
devraient être utilisés pour changer d'utilisateur avec su - ou
sudo - utilisateur.
# Proposition pour une copie manuelle
# Utiliser le lien direct vers le fichier superhosts.deny (Plus
de 15Mo) : https://hosts.ubuntu101.co.za/superhosts.deny
cd /etc
sudo cp hosts.deny hosts.deny.bak
# On peut télécharger le fichier dans le répertoire /tmp en tant
que simple utilisateur :
wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp
sudo -s
cat /tmp/superhosts.deny >> /etc/hosts.deny
exit
rm /tmp/superhosts.deny
# Proposition pour un script lancé depuis une tâche cron avec la
crontab de root
# Utiliser le lien direct vers le fichier superhosts.deny (Plus de
15Mo) : https://hosts.ubuntu101.co.za/superhosts.deny
cd /etc
cp hosts.deny hosts.deny.bak
# On peut télécharger le fichier dans le répertoire /tmp en tant
que simple utilisateur :
sudo - utilisateur_normal
wget https://hosts.ubuntu101.co.za/superhosts.deny -P /tmp
# On quitte le simple utilisateur pour copier le contenu du
fichier temporaire vers le fichier appartenant à root:root
exit
cat /tmp/superhosts.deny >> /etc/hosts.deny
# On supprime le fichier temporaire avec le simple utilisateur :
sudo utilisateur_normal
rm /tmp/superhosts.deny
# On quitte, deux fois (?) Une fois pour revenir à root, une
seconde pour quitter la fin du script (?)
exit
exit
Effectivement.Comme quoi, en quatre ligne, il y a tout de même des choses à dire... :)
Effectivement j'ai déjà pu constater ça, avec le paquet secure ou équivalent, qui demande à être installé, pour sécuriser l'échange.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
Merci pour ton complément d'informations.Amicalement,