Que se passe-t-il lorsqu'un user non root envoie des signaux au process de l'user root?

Je me questionne sur la security des signaux UNIX.

SIGKILL va tuer le process. Alors, que se passe-t-il lorsqu'un process d'un user non root envoie un signal au process d'un user root? Le process continue-t-il d'exécuter le gestionnaire de signaux?

Je suis la réponse acceptée (gollum's), et je tape des man capabilites , et je trouve beaucoup de choses sur le kernel Linux. De man capabilities :

 NAME capabilities - overview of Linux capabilities DESCRIPTION For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged processes (whose effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero). Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process's credentials (usually: effective UID, effective GID, and supplementary group list). Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities , which can be independently enabled and disabled. Capabilities are a per-thread atsortingbute. 

Sous Linux, cela dépend des capacités du file.

Prenez la source mykill.c simple mykill.c :

 #include <stdio.h> #include <sys/types.h> #include <signal.h> #include <stdlib.h> void exit_usage(const char *prog) { printf("usage: %s -<signal> <pid>\n", prog); exit(1); } int main(int argc, char **argv) { pid_t pid; int sig; if (argc != 3) exit_usage(argv[0]); sig = atoi(argv[1]); pid = atoi(argv[2]); if (sig >= 0 || pid < 2) exit_usage(argv[0]); if (kill(pid, -sig) == -1) { perror("failed"); return 1; } printf("successfully sent signal %d to process %d\n", -sig, pid); return 0; } 

construit le:

 gcc -Wall mykill.c -o /tmp/mykill 

Maintenant que la racine de l'user démarre un process de veille en arrière-plan:

 root@horny:/root# /bin/sleep 3600 & [1] 16098 

Maintenant, en tant qu'user normal, essayez de le tuer:

 demouser@horny:/home/demouser$ ps aux | grep sleep root 16098 0.0 0.0 11652 696 pts/20 S 15:06 0:00 sleep 500 demouser@horny:/home/demouser$ /tmp/mykill -9 16098 failed: Operation not permitted 

Maintenant, en tant qu'user root, changez les /tmp/mykill :

 root@horny:/root# setcap cap_kill+ep /tmp/mykill 

Et essayez à nouveau en tant qu'user normal:

 demouser@horny:/home/demouser$ /tmp/mykill -9 16098 successfully sent signal 9 to process 16098 

Enfin, veuillez supprimer /tmp/mykill pour des raisons évidentes;)

Rien:

 strace kill -HUP 1 [...] kill(1, SIGHUP) = -1 EPERM (Operation not permitted) [...] 

kill(2) page man explique:

Notes Linux

Dans différentes versions du kernel, Linux a imposé des règles différentes pour les permissions requirejses pour qu'un process non privilégié envoie un signal à un autre process. Dans les kernelx 1.0 à 1.2.2, un signal pourrait être envoyé si l'ID user effectif de l'expéditeur correspondait à celui du récepteur ou si l'ID user réel de l'expéditeur correspondait à celui du récepteur. Du kernel 1.2.3 à 1.3.77, un signal pourrait être envoyé si l'ID user effectif de l'expéditeur correspondait à l'ID user réel ou effectif du récepteur. Les règles actuelles, qui sont conforms à POSIX.1-2001, ont été adoptées dans le kernel 1.3.78.

le signal porterait mais le propriétaire du process appartient à la racine. donc, l'autre user n'a pas le droit de terminer le process afin que vous receviez un problème d'erreur de permission.

terminer le process n'est possible que si vous possédez la propriété (droits appropriés) du process.