Re: Debian Stable server hacked
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? ;-(
Reply to: