Launchpad Entry: security-karmic-apport-abort
Created: 2009-06-02
Contributors: kees, pitti
Packages affected: glibc, apport
Summary
Apport currently ignore crashes that ending SIGABRT. Two kinds of crashes would be valuable to catch: assert() failures, and internal glibc failures via *_chk(). Glibc will be modified to make the crash string available, and apport will be modified to record aborts for later analysis.
Release Note
Apport is now able to collect crash details from assertion and internal glibc failures. In the case of crashes where this information is not available, Apport will report such crashes as being skipped.
Rationale
It is valuable to leverage the automatic crash reporting features of apport, especially to catch buffer overflows, etc, getting detected by FORTIFY_SOURCE. Having apport ignore the crashes makes it harder for users to catch and report these bugs.
User stories
- Tony runs a program that crashes via SIGABRT with a glibc *_chk() failure. Apport records the assertion string and coredump. Tony is prompted to report the bug to Ubuntu.
- Aaron runs a program that crashes via SIGABRT with an assert() failure. Apport records the assertion string and coredump. Tony is prompted to report the bug to Ubuntu.
- Sean runs a program that just calls abort() instead of assert(). Apport records the crash. Tony is prompted for crashes later, and Apport explains why it will not file this crash, as it lacks useful details.
Design
- Apport needs a way to distinguish "useful" aborts from "useless" aborts so it can save and report the "useful" aborts.
- Apport needs to handle crashes from init.
Implementation
UI Changes
- apport needs to describe "useless" abort crashes and how it will not be reporting them.
Code Changes
glibc will be modified to retain the assert/fatal message string in an exported global variable pointer ("__assert_msg"). (DONE: upstream bug, upstream commit)
- apport will be modified to not ignore SIGABRT for applications with a core file.
apport will be modified to look for "__assert_msg" when building up the crash report.
if __assert_msg exists, keep the report
- if missing, dismiss the report (see UI Changes above)
- apport will be tested to read coredumps from init without triggering a kernel panic.