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.