Si tu arrives à créer un thread malicieux bravo.
Ce n'est pas plus dur de provoquer des overflows (et d'autres failles) dans un thread que dans un process !
Si ton privilège est sur un groupe ou un user et non sur le process,
Tous les programmes utilisant la séparation de privilèges (comme ssh ou X) utilisent évidemment des uid/groups spéciaux pour le process privilégié. Et ça ne coute rien en CPU supplémentaire.
Si tu as envie de placer des signaux dans tous les sens pour protéger tes variables dans les threads, c'est possible.
T2 ne peut pas empêcher un T1 malicieux d'accéder à une variable privée de T2 avec un signal.
) Si tu as un environement SE Linux tu peux protéger tes ressources/variables/accès aussi finement sur des threads que sur des process.
En userspace, tu ne peux pas empêcher T1 de modifier les variables privées de T2 pour forcer T2 à utiliser R malicieusement.
[^] # Re: Séparation des privilèges impossible avec threads actuelles !
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Ce n'est pas plus dur de provoquer des overflows (et d'autres failles) dans un thread que dans un process !
Si ton privilège est sur un groupe ou un user et non sur le process,
Tous les programmes utilisant la séparation de privilèges (comme ssh ou X) utilisent évidemment des uid/groups spéciaux pour le process privilégié. Et ça ne coute rien en CPU supplémentaire.
Si tu as envie de placer des signaux dans tous les sens pour protéger tes variables dans les threads, c'est possible.
T2 ne peut pas empêcher un T1 malicieux d'accéder à une variable privée de T2 avec un signal.
) Si tu as un environement SE Linux tu peux protéger tes ressources/variables/accès aussi finement sur des threads que sur des process.
En userspace, tu ne peux pas empêcher T1 de modifier les variables privées de T2 pour forcer T2 à utiliser R malicieusement.