Re: stack protection
> 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
Reply to: