SECURITY UPDATE: Fix local root privilege escalation through suid root exe core files

When /proc/sys/fs/suid_dumpable is enabled, crashing a program that is suid
root or not readable for the user would create root-owned core files in the
current directory of that program. Creating specially crafted core files in
/etc/logrotate.d or similar could then lead to arbitrary code execution with
root privileges.

Fix apport's drop_privileges() to actually drop privileges to the crashed
program's real ID. Before it was dropping to the owner of /proc/pid/stat, which
is root for suid root or unreadable executables.
This requires special-casing when writing .crash reports: We can't chmod the
written file to become readable as it needs to be owned by root and we already
dropped privileges; so create the reports with 0640 permissions right from the
start.

Don't write a core file for the kinds of executables above. Their
/proc/pid/stat is owned by root (or the user suid'ed to), only write core files
for processes whose real ID matches that ownership. (Note that comparing
against effective ID does not work as processes can drop their privileges.)
This is in accordance with the intention of core(5) and proc(5) whose intention
is to only allow suid_dumpable to pipes (i. e. apport) but not to core files in cwd.

Adjust signal_crashes.test_crash_setuid_{keep,drop} accordingly.  Add tests for
running a suid root and an unreadable executable in a non-user-writable cwd.
These reproduce the original exploit.

Thanks to Sander Bos for discovering this issue!

CVE-2015-1324
LP: #1452239