Je comprends bien la finesse que peut avoir la démarche d'impliquer les développeurs. C'est le principe des "capabilities" que fait tomber un programme au début de son lancement, pour que du code injecté puisse lancer certaine fonction système.
Le problème est qu'un gros programme commence à avoir de gros besoin. Si on ouvre tout, car on fait tout, on ne protège plus rien. C'est plus facile d'avoir des "niveaux de sécurités", définit par une seul lib qui protège certain type d'attaque (corruption de donné local ou pas, de binaire, du réseau, etc...).
C'est à mon avis hypersimple de faire une boulette avec seccomp qui permet d'ouvrir un shell ou autre chose qui permet ensuite d'avoir accès presque à tout (genre /dev/sda1 accessible dans un chroot).
[^] # Re: Autres projets utilisant seccomp-bpf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Seccomp, une sandbox intégrée au noyau Linux.... Évalué à 2.
Je comprends bien la finesse que peut avoir la démarche d'impliquer les développeurs. C'est le principe des "capabilities" que fait tomber un programme au début de son lancement, pour que du code injecté puisse lancer certaine fonction système.
Le problème est qu'un gros programme commence à avoir de gros besoin. Si on ouvre tout, car on fait tout, on ne protège plus rien. C'est plus facile d'avoir des "niveaux de sécurités", définit par une seul lib qui protège certain type d'attaque (corruption de donné local ou pas, de binaire, du réseau, etc...).
C'est à mon avis hypersimple de faire une boulette avec seccomp qui permet d'ouvrir un shell ou autre chose qui permet ensuite d'avoir accès presque à tout (genre /dev/sda1 accessible dans un chroot).
"La première sécurité est la liberté"