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? ;-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Stable server hacked
On Wed, Aug 13, 2003 at 04:02:41PM -0400, Colin Walters wrote: 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. 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. Anyway, since grsec uses PaX, it's very unlikely that anyone will take control of apache through a buffer overflow. ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Stable server hacked
On Wed, Aug 13, 2003 at 04:02:41PM -0400, Colin Walters wrote: 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. 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. Anyway, since grsec uses PaX, it's very unlikely that anyone will take control of apache through a buffer overflow. ;-)
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? ;-(
Re: Strongest linux
On Tue, Jul 01, 2003 at 02:36:37PM +0200, Javier Castillo Alcibar wrote: Hi all, I want to setup a new linux server in internet (apache, php, postfix, mysql, dns...), and I would like to patch the standard kernel with some security patches. but my question is, what patches are the best?? - Openwall ?? - TrustedDebian ?? - LIDS?? Any suggestions?? Check this out: http://www.grsecurity.net/features.php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Strongest linux
On Tue, Jul 01, 2003 at 02:36:37PM +0200, Javier Castillo Alcibar wrote: Hi all, I want to setup a new linux server in internet (apache, php, postfix, mysql, dns...), and I would like to patch the standard kernel with some security patches. but my question is, what patches are the best?? - Openwall ?? - TrustedDebian ?? - LIDS?? Any suggestions?? Check this out: http://www.grsecurity.net/features.php
Re: Fwd: bugtraq.c httpd apache ssl attack
On Sat, Sep 14, 2002 at 12:56:00PM +0200, Wichert Akkerman wrote: One wonders why you would have gcc installed on a webserver.. Look at places like he.net... They offer full unix environment hosting services (including gcc).
