Problem - Kevin Tafuro

#include
#include
#include
void spc_limit_core(void) {
struct rlimit rlim;
rlim.rlim_cur = rlim.rlim_max = 0;
setrlimit(RLIMIT_CORE, &rlim);
}
In addition to the RLIMIT_CORE limit, the setrlimit( ) function also
allows other per-process limits to be adjusted. We discuss these other
limits in Recipe 13.9.
The advantage of disabling core dumps is that if your program has particularly sensitive
information residing in memory unencrypted (even transient data is at risk,
because a skilled attacker could potentially time the core dumps so that your program
dumps core at precisely the right time), it will not ever write this data to disk in
a core dump. The primary disadvantage of this approach is that the lack of a core file
makes debugging program crashes very difficult after the fact. How big an issue this
is depends on program deployment and how bugs are tracked and fixed. A number
of shells provide an interface to the setrlimit( ) function via a built-in command.
Users who want to prevent core file generation can set the appropriate limit with the
shell command, then run the program.
However, for situations where data in memory is required to be protected, the application
should limit the core dumps directly via setrlimit( ) so that it becomes
impossible to inadvertently run the program with core dumps enabled. When core
dumps are needed for debugging purposes, a safer alternative is to allow core dumps
only when the program has been compiled in “debug mode.” This is easily done by
wrapping the setrlimit( ) call with the appropriate preprocessor conditional to disable
the code in debug mode and enable it otherwise.
Some Unix variants (Solaris, for example) allow the system administrator to control
how core dumps are handled on a system-wide basis. Some of the capabilities of
these systems allow the administrator to specify a directory where all core dumps
will be placed. When this capability is employed, the directory configured to hold
the core dump files is typically owned by the superuser and made unreadable to any
other users. In addition, most systems force the permissions of a core file so that it is
only readable by the user the process was running as when it dumped core. However,
this is not a very robust solution, as many other exploits could possibly be used
to read this file.
See Also
Recipe 13.9
Disabling Memory Dumps in the Event of a Crash | 37
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.