Par exemple, si un processus qui n'a aucune raison d'utiliser des sockets réseau se met à essayer de le faire, ça peut être un symptôme d'exécution de code arbitraire, auquel cas tuer l'application est une bonne chose à faire pour protéger l'intégrité, la confidentialité, la disponibilité du code et des données de l'ordinateur, et donc des utilisateurs. A une époque (Vista ou 7 ?), Microsoft avait mentionné le même genre de capacités pour Windows, même si je ne suis pas au courant que beaucoup utilisent de telles capacités, à supposer qu'elles aient été mises en place.

Le problème, c'est qu'outre la création et l'évolution compliquées des policies SELinux, SELinux est facile à contourner et désactiver par les nombreux exploits qui s'attaquent au faible kernel standard, grâce auquel plusieurs fois par an pour chaque type de vulnérabilité, des gens font élever les privilèges (voir le bordel actuel avec la terrible passoire que sont les user namespaces, dont le mainteneur refuse la création d'une option permettant de les désactiver autrement que par le fait de ne pas les compiler), ou tranquillement déférencer des structures de données puis exécuter du code arbitraire situé en user-space (sur la quasi-totalité des processeurs existants)...
Même avec une couche soi-disant "Security-Enhanced", une passoire ne protégeant pas contre les techniques d'exploitation connues depuis plus d'une décennie, pour quelques pourcents de performance en plus, reste une passoire.

Des travaux d'incorporation de quelques features de PaX/grsecurity ont récemment commencé, de façon plus sérieuse qu'avant parce que les mainteneurs principaux du kernel prennent lentement conscience que le retard considérable du Linux standard s'aggrave avec le temps, et Linux (tel que presque tout le monde l'utilise) usurpe de plus en plus sa réputation de sécurité. Cependant, vu que Linus refuse les plus efficaces (UDEREF et KERNEXEC), leur préférant les capacités pourtant inférieures de processeurs rares, et n'est toujours pas chaud pour les plugins GCC, qui sont pourtant à la base des deux autres membres du quatuor de base (RANDSTRUCT et CONSTIFY), ça n'ira pas loin...
Je ne demande qu'à avoir tort, mais la seule vraie solution reste - et restera - l'utilisation d'un kernel grsec, tant qu'il existe. D'ailleurs, les distros qui proposent des intégrations plus ou moins avancées du kernel grsec sont de plus en plus nombreuses, et c'est une bonne chose. Debian sid a récemment ajouté un kernel grsec, et même si celui-ci n'arrivera jamais dans testing et donc dans une release stable, ça finira quand même par porter ses fruits.