On 1/2/2012 9:18 AM, Les Mikesell wrote:
There have been many, many vulnerabilities that permit local user privilege escalation to root (in the kernel, glibc, suid programs, etc.) and there are probably many we still don't know about. They often require writing to the filesystem. For example, one fixed around 5.4 just required the ability to make a symlink somewhere. The published exploit script (which I've seen in the wild) tries to use /tmp. If the httpd process can't write in /tmp, it would fail.
So are you saying that SELinux is supposed to prevent httpd from writing to /tmp ?
Because I just tested that and SELinux didn't appear to stop it. I set selinux to "enforcing", rebooted just to make sure, and put this perl script on my webserver:
#!/usr/bin/perl use IO::File; use strict; my $fh = IO::File->new("> /tmp/foo.txt"); close($fh); print "Content-type: text/html\n\nDone.\n";
then invoked it from the web, and this file was created: [root@g6950-21025 ~]# ls -l /tmp/foo.txt -rw-r--r-- 1 apache apache 0 Jan 2 16:47 /tmp/foo.txt
[root@g6950-21025 ~]# cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=enforcing # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted
So it looks like SELinux in this case does not prevent httpd from writing to /tmp , in which case it would not have prevented the exploit you're referring to. Or am I missing something?