En même temps faire un peu de défense en profondeur, ça ne fait pas de mal. Surtout pour le forensic qui suivra l'attaque.
Je me suis mal exprimé : je suis pour , mais pas au détriment de la compatibilité.
Que le rsyslog/... ait un champ en plus, spécifique, ou il indique par ex le pid et le chemin vers l'exe qui tourne oui, mais en plus.
Et puis, on prend quoi pour assurer la sécu, le pid ? le lwp ? le contexte selinux ? ...
On fait une liste blanche des programmes qui ont le droit d'utiliser syslog ? on fait juste une indication dans le log ?
D'où l'intérêt que ce soit des champs en plus , et configurable.
Sachant toujours que ce n'est pas du tout une sécurité absolue (si un process est exploité, tous les messages d'erreurs seront envoyé avec un pid "qui semble correcte").
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par briaeros007 . En réponse au journal Lennart casse les logs!. Évalué à 2.
Je me suis mal exprimé : je suis pour , mais pas au détriment de la compatibilité.
Que le rsyslog/... ait un champ en plus, spécifique, ou il indique par ex le pid et le chemin vers l'exe qui tourne oui, mais en plus.
Et puis, on prend quoi pour assurer la sécu, le pid ? le lwp ? le contexte selinux ? ...
On fait une liste blanche des programmes qui ont le droit d'utiliser syslog ? on fait juste une indication dans le log ?
D'où l'intérêt que ce soit des champs en plus , et configurable.
Sachant toujours que ce n'est pas du tout une sécurité absolue (si un process est exploité, tous les messages d'erreurs seront envoyé avec un pid "qui semble correcte").