5 votes

Linux 2.6.32 Centos 6.4 setuid() échoue / changements de sécurité ?

Après une récente mise à jour vers CentOS 6.4, deux machines ont des restrictions setuid() qui agissent comme capabilities ou selinux, mais les deux sont désactivées. Par exemple, l'opération suivante échoue :

[root@host statd]# perl -e 'use POSIX; POSIX::setuid(99);system("id")'
[root@host statd]# echo $?
0

Alors qu'il devrait renvoyer quelque chose comme :

host:~# perl -e 'use POSIX; POSIX::setuid(99);system("id")'
uid=99(nobody) gid=0(root) groups=99(nobody),0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Strace'ing l'invocation de perl, l'appel setuid() réussit, cependant l'enfant system() sort immédiatement, comme s'il avait été terminé par selinux ou similaire. Cependant, il n'y a pas d'entrée dans /var/log/audit/audit.log, même après semodule -DB.

setuid32(99)                            = 0
getuid32()                              = 99
geteuid32()                             = 99
pipe([3, 4])                            = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7705728) = 10073
close(4)                                = 0
rt_sigaction(SIGINT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
waitpid(10073, [{WIFEXITED(s) && WEXITSTATUS(s) == 255}], 0) = 10073
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigaction(SIGINT, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], 0}, NULL, 8) = 0
read(3, "\r\0\0\0", 4)                  = 4
close(3)                                = 0
exit_group(0)    

Ce problème est devenu évident après le premier redémarrage car nfs.statd a échoué en affichant "Failed to access local netconfig database : Netconfig database not found". Et rpc.rquotasd a échoué parce que "RPC : server localhost requires stronger authentication."

Le problème de nfs.statd peut être résolu en l'exécutant en tant que root (chown root:root /var/lib/nfs/statd ). Exécuter tout sur la machine en tant que root ne semble pas être une solution idéale ;)

La tentative de connexion à un autre compte ne fonctionne pas non plus :

[root@host ~]# su - jboss
su: warning: cannot change directory to /opt/jboss: Permission denied
su: /bin/bash: Permission denied
[root@host ~]# su jboss
su: /bin/bash: Permission denied

Les informations de base sur le système sont les suivantes :

[root@host statd]# getenforce
Permissive
[root@host statd]# uname -a
Linux host.example.com 2.6.32-358.14.1.el6.i686 #1 SMP Tue Jul 16 21:12:30 UTC 2013 i686 i686 i386 GNU/Linux
[root@host statd]# cat /etc/redhat-release
CentOS release 6.4 (Final)
[root@host statd]# getcap /usr/bin/perl
/usr/bin/perl =

Qu'est-ce qui peut causer cela alors qu'il ne s'agit apparemment pas de selinux ou de capacités linux ?

1voto

Patrick Points 61

D'une manière ou d'une autre, le processus de mise à jour a modifié les perms sur / en :

[root@host ~]# ls -alZ /
drw-r--r--. 42374 5031 system_u:object_r:root_t:s0      .
drw-r--r--. 42374 5031 system_u:object_r:root_t:s0      ..

Ce qui a été corrigé par un

chown root:root / && chmod 755 /

Pour réduire l'espace d'erreur, il a été très utile d'exécuter la commande

strace perl -e 'use POSIX; POSIX::setuid(99);exec("id")'

Ce qui a montré que l'appel execve() de perl échouait à chaque fois avec EACCES alors qu'il essayait tous les répertoires $PATH.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X