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?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
