Personnellement, je suis d'accord avec le commentaire au dessus : je ne pense pas que ça soit à l'application de gérer ce genre de cas.
Donc tu penses que apache, bind, sshd, postfix et autres daemons devraient tourner 100% en root, par ce que ce n'est pas à eux de gerer ca ?
seccomp c'est le meme principe que tous les daemons qui démarrent en root, et une fois qu'ils ont terminé les operations qui necessitaient des droits root, changent leur uid en un autre, et pour certains s'enferment dans un chroot. Avec seccomp, en plus de changer d'uid et se mettre dans un chroot, le processus se retire l'accès aux appels systemes qu'il sait ne pas avoir besoin d'utiliser.
Après, rien n'empêche bien sûr de multiplier les mesures de sécurité mais j'ai peur que ça n'empiète sur les performances.
Pourquoi est ce que ca empièterait sur les performances ?
[^] # Re: Autres projets utilisant seccomp-bpf
Posté par Anonyme . En réponse au journal Seccomp, une sandbox intégrée au noyau Linux.... Évalué à 8.
Donc tu penses que apache, bind, sshd, postfix et autres daemons devraient tourner 100% en root, par ce que ce n'est pas à eux de gerer ca ?
seccomp c'est le meme principe que tous les daemons qui démarrent en root, et une fois qu'ils ont terminé les operations qui necessitaient des droits root, changent leur uid en un autre, et pour certains s'enferment dans un chroot. Avec seccomp, en plus de changer d'uid et se mettre dans un chroot, le processus se retire l'accès aux appels systemes qu'il sait ne pas avoir besoin d'utiliser.
Pourquoi est ce que ca empièterait sur les performances ?