[Avancé] chattr et cron.daily

Support Debian
#1

Bonjour,

Voilà le problème très spécifique que je rencontre, et il vaut mieux avoir de bonnes connaissances pour me répondre - c’est pourquoi j’ai mis le drapeau [Avancé] :wink:

Je suis partisan de durcir un tant soit peu sa Debian/Devuan.
Parmi ce durcissement, j’utilise l’outil chattr.
(j’explique tout ça dans mon article dédié)

Mais j’ai un problème très particulier lors de l’exécution de la tâche cron.daily
Tous les jours, la tâche cron.daily exécute les tâches précisées dans le répertoire /etc/cron.daily/.
La première tâche exécutée est celle d’anacron (dixit le fichier 0anacron) qui s’occupe, si j’ai bien compris d’exécuter les autres - mais je peux peut-être me tromper quant à ma compréhension.

Le mail de rapport me retourne le message suivant :

/etc/cron.daily/apt-listbugs:
Fixed packages : kmod
cp: cannot create regular file '/etc/apt/preferences.d/apt-listbugs': Operation not permitted
run-parts: /etc/cron.daily/apt-listbugs exited with return code 1
/etc/cron.daily/google-earth-pro:
/etc/cron.daily/google-earth-pro: 246: cannot create /etc/apt/sources.list.d/google-earth-pro.list: Operation not permitted
/etc/cron.daily/google-earth-pro: 247: cannot create /etc/apt/sources.list.d/google-earth-pro.list: Operation not permitted

Ces opérations non permises sont en effet empêchées d’exécution du fait de l’usage de chattr.

Donc, la question que je me pose est comment appeler chattr de manière adéquate pour permettre l’exécution correcte de la tâche cron.daily ?!

#2

Salut
Google sur « /etc/cron.daily/apt-listbugs/ »
trouve entre autres

apt-listbug: cron.daily apt-listbugs job chokes when run by anacron

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289361

Anacron fonctionne très bien, voici mon petit pense-bête

#3

je n’ai pas dit le contraire, et ne pense pas l’avoir insinué !

Pour le reste, merci :smiley:

#4

il n’y a pas que toi qui lira ce fil…un peu de modestie ne saurait nuire

As tu bricolé les droits de /etc/apt/ avec chattr??

#5

Sans commentaire. :frowning:

STP, si tu ne réponds que pour afficher tes jugements de valeur, passe ton chemin. Merci d’avance.

« bricolé » n’est pas le terme. Je ne bricole pas !
Ensuite, oui, j’utilise chattr, tel que je l’exprime dans mon article.

C’est sympa de répondre, mais ça serait certainement mieux de tout lire correctement - ça sert à quoi que je m’efforce d’être explicite. :wink:

#6

Je suis toujours surpris de l’imaginations de certains pour se compliquer la vie :wink:
Entre blinder son système et le rendre inutilisable (ou difficilement) il y a un juste compromis à trouver.
Note que tu aurais pu monter ta partition système en lecture seule, cela reviendrait à peu près au même et serait sans doute plus facile à gérer.
Si tu veux conserver cette configuration tordue il faudrait que tu surcharges le service systemd anacron (ou cron) pour qu’il exécute un script qui enlève l’attribut immuable (-i), lance anacron, puis remet cet attribut (+i).

#7

Rien à voir avec l’imagination !
Cela fait partie des conseils de sécurité formulées en 2015, 2016 par l’ANSSI, pour justement sécuriser son Linux…
Après tu as le droit de penser autrement !

Et, des deux, entre toi et l’ANSSI, je te laisse comprendre les conseils de qui je préfère. :stuck_out_tongue:

Il est loin d’être utilisable, loin sans faut.
Si, j’ai créer un script shell, c’est justement pour me faciliter la tâche, justement dans l’esprit de ce « compromis ». :stuck_out_tongue:

Maintenant, j’ai ce détail qui me « chatouille » l’esprit ; si je peux trouver une réponse intéressante à ce « problème », c’est tant mieux. C’est en étant confronté à certaines choses qu’on améliore sa compréhension, son expérience, et qu’on décide des choix à retenir ou non ?!

ça, en effet, je m’en doute très fortement. :smiley:

#8

Je veux bien que tu me donnes la référence de l’ANSSI qui indique cette utilisation très particulière de l’attribut d’immuabilité.

Si tu t’en doutes, tu n’as plus qu’a essayer d’appliquer cette solution.

Sinon cela pourrait peut-être aussi fonctionner avec :

CapabilityBoundingSet=CAP_LINUX_IMMUTABLE
AmbientCapabilities=CAP_LINUX_IMMUTABLE

dans l’unité de service.

#9

Je pensais sincèrement que cela faisait partie de ce fichier :

Ce qui est sûr, c’est que je ne l’ai pas « inventé ». Mais bon… :joy:
Donc, je te pries de m’excuser de l’avoir « avancé »

#10

Cela m’étonnerait fort que l’ANSSI fasse ce genre de recommandation (tel que dans le lien de ton premier message). Quel intérêt de mettre cet attribut sur des dossiers/fichiers qui ne sont accessibles qu’à root ? (ex : /root)

#11

j’ai pas tout lu :rofl: :rofl: :rofl:

1 J'aime
#12

@grandtoubab: oui, la dernière version date de 2019 :wink:
c’est le même document que la référence que j’ai donnée, simplement màj !