☰

Linux 2.6.32 Centos 6.4 setuid() fehlgeschlagen / Sicherheitsänderungen?

tag-icon • tag-icon linux security centos6.4 setuid
Linux 2.6.32 Centos 6.4 setuid() fehlgeschlagen / Sicherheitsänderungen?

Nach dem kürzlichen Update auf CentOS 6.4 haben zwei Maschinen setuid()-Einschränkungen, die sich wie Capabilities oder Selinux verhalten, jedoch beide deaktiviert sind. Beispielsweise schlägt Folgendes fehl:

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

Es sollte etwa Folgendes zurückgegeben werden:

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

Beim Aufruf von Perl ist der Aufruf von setuid() erfolgreich, das untergeordnete System() wird jedoch sofort beendet, als wäre es von Selinux oder Ähnlichem beendet worden. Es gibt jedoch keinen Protokolleintrag in /var/log/audit/audit.log, auch nicht nach 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)

Dieses Problem wurde nach dem ersten Neustart deutlich, da nfs.statd mit „Fehler beim Zugriff auf lokale Netconfig-Datenbank: Netconfig-Datenbank nicht gefunden“ fehlschlug. Und rpc.rquotasd schlug mit „RPC: Server localhost erfordert stärkere Authentifizierung“ fehl.

Das nfs.statd-Problem kann behoben werden, indem man es als Root ausführt (chown root:root /var/lib/nfs/statd ). Alles auf der Maschine als Root auszuführen scheint keine gute Problemumgehung zu sein. ;)

Auch der Versuch, per su auf ein anderes Konto zuzugreifen, funktioniert nicht:

[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

Es folgen grundlegende Systeminformationen:

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

Was könnte die Ursache dafür sein, wenn es offensichtlich nicht an den Selinux- oder Linux-Funktionen liegt?

Antwort1

Der Upgrade-Prozess hat die Berechtigungen irgendwie auf / geändert in:

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

Das Problem wurde behoben mit einem

chown root:root / && chmod 755 /

Eine große Hilfe bei der Eingrenzung des Fehlerbereichs war stattdessen das Ausführen von

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

Dies zeigte, dass der execve()-Aufruf von Perl jedes Mal mit EACCES fehlschlug, da alle $PATH-Verzeichnisse ausprobiert wurden.

verwandte Informationen