On Wed, Aug 13, 2003 at 07:08:59PM -0400, Colin Walters wrote: > 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.
Well capabilities are only one of the things that grsec implements. You can also restrict a process to access various parts of the filesystem. There's no reason /usr/sbin/apache should have write access to /etc, so you just don't allow it. You can also place restrictions based on resources (cpu, memory, etc.) and IP addresses as well. BTW, grsec (well gradm actually) has an intelligent self-learning mode that can help you to give a process only the minimum amount of access necessary to operate in. That way, even a novice sysadmin should be able to benefit from a higher level of security. And even for experienced sysadmins, it makes the process of setting up ACLs much less error-prone. > > 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. It actually does a very good job of stopping any kind of "stack-smashing" attack dead in its tracks (both the stack and heap are marked as non-executable). That takes care of most vulnerabilities, both known and unknown. > 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. Why even jump to conclusions like this when you admitted a few messages back that you don't know much about grsec? ;-(
