tu vas m'expliquer comment SELinux peut détecter lors d'une slice se déroulant en userspace, que la thread T1 a modifié des variables privées de la thread T2 afin de lui faire faire des choses non voulues avec la ressource R.
C'est sur que si tu veux des variables privées ET une protection granulaire kernel ET pas de syscall ca va être dur.
Par contre si on s'autorise les appels systèmes, un mutex (au sens système du terme, par un lock informatif pthread) posé par un thread d'un domaine peut parfaitement devenir totalement insensible au niveau kernel à une demande de retrait par les threads des autres domaines.
Par contre dans ce cas là impossible de faire sauter le syscall.
[^] # Re: Séparation des privilèges impossible avec threads actuelles !
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
C'est sur que si tu veux des variables privées ET une protection granulaire kernel ET pas de syscall ca va être dur.
Par contre si on s'autorise les appels systèmes, un mutex (au sens système du terme, par un lock informatif pthread) posé par un thread d'un domaine peut parfaitement devenir totalement insensible au niveau kernel à une demande de retrait par les threads des autres domaines.
Par contre dans ce cas là impossible de faire sauter le syscall.