Re: Debian Stable server hacked
On Wed, 2003-08-13 at 00:20, Adam Majer wrote:
> So, now I don't run a Debian kernel at all - only a monolithic
> (no modules) kernel with grsecurity.net patches. Then I set
> up the ACL system (more or less) so that all of the services
> that can be used to break into the system are quite useless for the attacker.
> For example, apache can only execute from paths that it cannot
> write to. Heck, same for root but apache can't even see /bin, etc..
I admit to not having investigated grsecurity very much. But one
question that comes up occasionally on the SELinux list and on IRC is
"How do I hide files/directories from a process, or prevent it from
executing them?". The answer for the former is that with SELinux you
can't reliably hide things, and although you can prevent execution of
normal binaries such as stuff in /bin, it's not widely used. For
example, regular users have permission to execute /bin/mount.
Why? Because SELinux doesn't solely associate security with executable
pathnames. If someone takes over control of the apache process via a
buffer overflow or whatever, they don't need /bin/ls to list a
directory; they can just as easily use the opendir/readdir/stat system
calls. Likewise, they don't need /bin/mount to mount filesystems; they
can just as easily use the mount syscalls.
So the whole grsecurity ACL system seems very weak in that respect.
Let me give an example of how SELinux protects my machine (verbum.org).
My blog is a Python script (pyblosxom) which runs in a domain called
httpd_user_script_t. This domain can execute programs such as /bin/sh
(I think pyblosxom might use system() in a place or two). Suppose an
attacker somehow got pyblosxom to execute arbitrary commands to /bin/sh.
With SELinux, that doesn't help an attacker at all, because the new
/bin/sh process gets the same security context as the CGI script, so it
doesn't have any more privileges. The security is at the level of the
system calls it can make, not what binaries it can execute.
Reply to: