> Who is interested in stack protection? I am.
>I think it would be good to have some experiments of stack protected packages >for Debian. Probably the best way to do this would be to start with >ssh-stack and sysklogd-stack being uploaded to experimental. I don't have >time to do this, but I would like to help test it. I think it would be good too, but I would rather speak about 'security enhanced packages' in general. Nowadays, we are able to achieve way better things than just stack protection (see end of message). >Also is there any interest in uploading a kernel-image package with the grsec >PaX support built in? Do you mean a grsec kernel with some security options (such as PaX) enabled by default? Yes, it would be a good thing, and it's even necessary to have kernel based stuff to achieve good protection. gsecurity is a good choice because it includes PaX and adds some nice tricks (chroot() hardening, /proc restritions..) and a full ACL system. Here's (basically) what PaX can provide: - A non-executable pages semantic for alpha, i386, parisc, ppc, sparc, sparc64, which means the ability to build readable/writeable but non executable pages on those architectures which is achieved by some nice tricks on i386 (because there is no hardware support). - Use of this new semantic in the kernel (this is called MPROTECT feature), this will ensure that memory is writable (x)or executable but not both. This is achieved as a modification to mmap() and mprotect() interface, and as a result, you cannot create non executable anonymous mapping, and file mapping are NEVER executable/writable at the same time. (This means that you have a non executable stack, non executable heap and much more). - Address space layout randomization: (to prevent return-to-libc attacks), this tries to randomize the base adresses of stack, heap, mmaped libraries. This require no userland modification. But it does more, it will even randomize the main ELF executable (like .text section) and this is where 'security hardened' packages could be usefull. Because this randomization, to be done the proper way (without any performance impact) needs relocation information which is not available in most ELF files (which are ET_EXEC), but is in ET_DYN ELF files. Without this relocation, PaX can do a kind of 'emulation' (called RANDEXEC) which has a performance impact. Those ET_DYN ELF executables can (rather) easily be produced using a propolice gcc with some modified specfiles. This hardened gcc is already available for gentoo (thanks to pappy/solar). Debian could have a hardened gcc package, and have some binary packages (such as sshd) compiled with it. Compatibility: first, not all architectures are supported by PaX' NOEXEC. Second there are a few applications relying on the fact that the heap is executable (X, java..), PaX features can be disabled 'per executable', but not (for now) 'disabled by default and enabled 'per executable'. The 'security hardened' packages are no use for NOEXEC anyway (which does'nt need anything userspace), so this could be let disabled by default in the secure kernel, and we could enable ASLR only in PaX. Anyway, imho, this kernel stuff should be treated separately, but grsecurity is a good choice for a secure kernel, because it's ACL are needed to prevent some attacks for which PaX cannot do anything. For the 'security hardened' binary packages: building ET_DYN executables will improve security if PaX ASLR is enabled in kernel, but it will work just like a good old ET_EXEC if it is not. So I think it would be a good idea to build ET_DYN executable in 'security enhanced' packages. So, a security enhanced package, built using propolice + beeing ET_DYN will have all the features of propolice, and, if PaX ASLR is loaded in kernel, it will achieve another good protection layer. Julien
