> 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. Pasque wget a des vulnérabilités aussi. Nom d'un gruyère ! >> 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: Je ne sais pas ou tu a copier l'explication mais droits prend un " t " ;) > > 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). " il faudra penser A attribuer " -> Les traductions ont des failles ;)
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 > Comme quoi, en quatre ligne, il y a tout de même des choses à > dire... :) Effectivement. >>> 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 Effectivement j'ai déjà pu constater ça, avec le paquet secure ou équivalent, qui demande à être installé, pour sécuriser l'échange. > Amicalement, Merci pour ton complément d'informations.
