On Wed, 2003-08-13 at 18:39, valerian wrote: > > grsec handles this by allowing you to restrict Linux capabilities for a > process. For example, there's no reason /usr/sbin/apache should have > access to CAP_SYS_ADMIN (allows mount/umount, amongst other things) or > CAP_SYS_PTRACE (run ptrace) or many others.
But Linux capabilities are so weak. They won't protect an apache master process that runs as root from scribbling over /etc/passwd and giving an attacker a new uid 0 shell account, for example. At that point it's really game over. The attacker then logs in, and has all the capabilities. From there, they have access to /dev/mem, where they can runtime patch the kernel and kill off grsecurity or do whatever else they want. > Anyway, since grsec uses PaX, it's very unlikely that anyone will "take > control" of apache through a buffer overflow. ;-) >From what I understand it is often possible to evade these kinds of restrictions. Anyways, I just wanted to point out that while grsecurity probably helps somewhat, it provides significantly less security than a system like SELinux. Its sole advantage as far as I can tell is that it's somewhat easier to set up.
