S'assurer que toutes les entrées du PATH de root sont des répertoires
Garantit que le PATH de root ne contient ni entrée vide ni . et qu'aucun de ses répertoires n'est accessible en écriture par group ou other.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Le PATH de root ne doit contenir que des répertoires sûrs. Une entrée vide, une entrée relative . ou un répertoire accessible en écriture par group/other permet à un utilisateur non privilégié de déposer un binaire malveillant que root exécutera ensuite avec tous les privilèges, une élévation de privilèges par détournement du PATH classique. Supprimer les entrées vides/. et restreindre les permissions des répertoires garantit que chaque commande exécutée par root provient d'un emplacement de confiance.
Ce que vérifie Pavois
Pavois lit le PATH effectif depuis l'environnement (os_env('PATH')) puis fait un stat sur chaque répertoire, auditant ainsi la valeur que root utilise réellement pour résoudre les commandes, et non une ligne statique de /etc/profile ou /etc/environment. Un scan basé sur les fichiers raterait un PATH modifié par un fichier rc shell, un drop-in ou un extrait de profil ; l'environnement résolu est la seule source de vérité.
rp = os_env('PATH').content.to_s.split(':')
describe rp do
it { should_not be_empty }
it { should_not include '' }
it { should_not include '.' }
end
rp.reject { |d| d.empty? || d == '.' }.each do |d|
describe file(d) do
it { should_not be_writable.by 'group' }
it { should_not be_writable.by 'other' }
end
endComment vérifier qu’elle est appliquée
En tant que root, exécutez echo "$PATH", il ne doit contenir aucun segment vide (pas de ::, pas de : en début/fin) ni .. Vérifiez ensuite les permissions de chaque entrée, par ex. ls -ld /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin : aucun ne doit montrer de bit d'écriture pour group ou other (pas de w en position 6 ou 9).
Inspecter et investiguer
Aucun journal dédié n'existe pour cette règle. Inspectez l'état courant avec echo "$PATH" et ls -ld <chaque répertoire>. Si auditd surveille les répertoires concernés, les événements de création de fichier ou de changement de permissions apparaissent dans /var/log/audit/audit.log.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit donc être appliquée manuellement. Supprimez toute entrée vide ou . du PATH de root (modifiez le profil shell / /etc/environment qui le définit), et restreignez tout répertoire trop permissif avec par ex. chmod g-w,o-w <rép> (ou chown root <rép> s'il appartient à un utilisateur non-root). Relancez pavois harden verify pour confirmer.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | sudo -l 2>/dev/null | grep -i secure_path; grep -rE 'PATH=' /root/.bashrc /root/.profile /etc/profile 2>/dev/null # ensure no empty entry, no '.', no world-writable dir; fix in the relevant file |
|---|---|
| reason | fixing root's PATH may be in a shell profile or sudoers secure_path, review the source |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Supprimer une entrée . ou vide du PATH peut casser des scripts qui s'appuient implicitement sur l'exécution de commandes depuis le répertoire courant, auditez ces scripts et appelez plutôt les binaires par chemin absolu. Restreindre les permissions des répertoires avec chmod g-w/o-w pourrait perturber un outillage qui y écrit légitimement ; confirmez que le répertoire est un chemin bin système avant de le modifier. Aucun de ces changements ne risque un verrouillage, mais testez dans un shell avant de les rendre persistants dans le profil de root.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.4.2.5 | direct | per OS, see the benchmark table | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.