☰

Linux 2.6.32 Centos 6.4 setuid() falla/cambios de seguridad?

tag-icon • tag-icon linux security centos6.4 setuid
Linux 2.6.32 Centos 6.4 setuid() falla/cambios de seguridad?

Después de actualizar recientemente a CentOS 6.4, dos máquinas tienen restricciones setuid() que actúan como capacidades o selinux, sin embargo, ambas están deshabilitadas. Por ejemplo, falla lo siguiente:

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

Cuando debería devolver algo como:

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

Al rastrear la invocación de perl, la llamada a setuid() tiene éxito, sin embargo, el hijo system() sale inmediatamente, como si hubiera sido terminado por selinux o similar. Sin embargo, no hay ninguna entrada de registro en /var/log/audit/audit.log, incluso después del 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)

Este problema se hizo evidente después del primer reinicio, ya que nfs.statd falló con "Error al acceder a la base de datos local de netconfig: no se encontró la base de datos de Netconfig". Y rpc.rquotasd falló porque "RPC: el servidor localhost requiere una autenticación más sólida".

El problema de nfs.statd se puede solucionar ejecutándolo como root (chown root:root /var/lib/nfs/statd). Ejecutar todo en la máquina como root no parece una buena solución. ;)

Intentar acceder a otra cuenta tampoco funciona:

[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

La información básica del sistema es la siguiente:

[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é podría estar causando esto cuando aparentemente no se trata de capacidades de Selinux o Linux?

Respuesta1

De alguna manera, el proceso de actualización cambió los permisos en/a:

[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      ..

que se arregló con un

chown root:root / && chmod 755 /

Una gran ayuda para reducir el espacio de error fue ejecutar

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

Lo que mostró que la llamada execve() de Perl fallaba cada vez con EACCES cuando probaba todos los directorios $PATH.

información relacionada