Rendre un processus impossible à tuer sous Linux


14

Je travaille sur une application de gestion de mot de passe, et pour des raisons de sécurité, je veux lancer un processus impossible à tuer.

Et d'ailleurs, je ne veux pas que ce programme soit un démon car j'ai besoin de lire à partir d'une entrée standard et d'y écrire.

Y a-t-il un moyen de faire cela?


11
"Pour des raisons de sécurité, je veux lancer un processus non destructif." Juste une note - si cela était autorisé, les gens pourraient facilement l'exploiter pour des raisons néfastes - par exemple, lancer une bombe à fourche imparable.
VLAZ

32
Cela ressemble à un problème XY . Je soupçonne que quoi que vous essayiez vraiment d'accomplir, un processus impossible à tuer n'est pas la façon de le faire. "Pour des raisons de sécurité" est très vague. Que voulez-vous exactement empêcher l'utilisateur de faire? Quel accès ont-ils?
Nate Eldredge

4
Tout processus impossible à tuer à toutes fins utiles est un virus.
Naftuli Kay

3
@NateEldredge: Demandez plutôt au programme d'ignorer les signaux. C'est la manière typique de le faire; sinon, quelqu'un pourrait envoyer un SIGINT ou SIGTSTP directement au processus, en contournant le terminal.
Noah Spurrier

2
@NoahSpurrier: J'imagine une situation où vous avez un utilisateur qui peut taper des choses sur la console, mais qui ne peut pas autrement exécuter du code sur l'ordinateur (comme un kiosque). Vous l'avez configuré pour qu'aucune clé qu'ils puissent taper n'ait un effet inattendu. S'ils peuvent exécuter un autre code, ignorer SIGINT et SIGTSTP et SIGQUIT n'aide pas; toute personne qui pourrait envoyer ces signaux directement au processus pourrait également envoyer SIGKILL ou SIGSTOP que vous ne pouvez pas ignorer.
Nate Eldredge

Réponses:


41

Faire le gestionnaire de mot de passe fonctionner sous un utilisateur distinct et poignée / ignore / bloquer les signaux générés bornes ( SIGINT, SIGQUIT, SIGHUP,SIGTSTP , SIGTTIN, et SIGTTOU).

Vous ne pouvez pas envoyer de signaux aux processus (= kill) exécutés sous un autre utilisateur (utilisateur dont l'uid réel et l'uid enregistré sont différents de votre uid effectif) à moins que votre identifiant effectif soit 0 (root).

Tous les processus seront toujours éliminables par root.

Pour plus de détails, voir kill (2) .


15

La seule façon de rendre un processus impossible à tuer est de le mettre en œuvre thread noyau , ce qui n'est pas anodin.

Vous pouvez toujours le tuer, mais ce serait un dommage collatéral de l'arrêt du système d'exploitation.

Vous pouvez également développer un module de noyau personnalisé qui définirait l' SIGNAL_UNKILLABLEindicateur de votre processus. Cet indicateur est conçu pour être défini uniquement pour init(ou systemd, quel que soit le processus initial de lancement du noyau) qui sont les seuls processus de l'espace utilisateur protégés contre une destruction inconditionnelle, mais rien ne semble interdire que cet indicateur soit présent pour un processus régulier.


1
cela pourrait être le processus d'initialisation
muhmuhten

@muhmuhten Vous avez raison, init est un processus utilisateur protégé contre un kill inconditionnel. Il n'est cependant pas conçu pour être personnalisé alors qu'il existe définitivement une API pour les modules du noyau et les threads.
jlliagre

Pour développer ma propre réponse, je suppose que vous n'avez pas accès à un compte root (ce qui, soit dit en passant, indique qu'il s'agit soit d'un exemple de jouet, d'un projet de cours ou d'un malware). Le empêche l'idée que vous pouvez câbler un module de noyau à cet effet. Notez également que l'indicateur SIGNAL_UNKILLABLE n'est pas disponible pour les processus normaux et empêche certaines opérations normales importantes (telles que vforking) et je le considérerais donc comme un cas de bord normalement impraticable.
GregD

@jlliagre en effet, ce n'est pas le cas.
muhmuhten

@dudek Un processus impossible à tuer est déjà un cas de bord normalement impraticable.
jlliagre

11

Techniquement, il n'y a aucun moyen de rendre un processus impossible à tuer.

Bien sûr, pour les utilisateurs non root, ils ne peuvent tuer que les processus qui ont le même ID utilisateur, donc si vous pouvez créer des comptes différents, vous pouvez utiliser un ID utilisateur "unique" pour le processus et alors seul root pourrait le tuer.

Une solution simple, mais moins robuste, consiste à faire en sorte que votre processus capture autant de signaux que possible (peut-être en les ignorant). Cela ne convient qu'aux exemples de jouets ou aux environnements non antagonistes car il n'y a aucun moyen d'attraper le signal KILL (signal 9), mais sinon vous pouvez éviter d'être tué par eux.

Enfin, vous pouvez faire en sorte que votre processus réapparaisse s'il est tué. C'est également fragile (très fragile), mais il sera un peu plus difficile à effacer. Cela peut être accompli en utilisant votre propre processus de surveillance ou en utilisant inittab. Pour un adversaire qui sait ce qu'il fait, cela peut être facilement contourné en tuant plusieurs processus à la fois.


1
Mais (autre que inittab), il est possible que le processus de surveillance puisse également être tué, non?
roaima

Non, les pilotes de périphériques (modules du noyau) peuvent créer des processus qui ne peuvent pas être tués par root.
Noah Spurrier
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.