When a program reads passwords or other sensitive information, it should perform whatever processing is required, and then immediately erase the information from memory. (We show an example of this in Section 8.5.) Leaving such information in memory is a security risk, for the following reasons:
The virtual memory page containing the data may be swapped out (unless it is locked in memory using mlock() or similar), and could then be read from the swap area by a privileged program.
If the process receives a signal that causes it to produce a core dump file, then that file may be read to obtain the information.
Following on from the last point, as a general principle, a secure program should prevent core dumps, so that a core dump file can’t be inspected for sensitive information. A program can ensure that a core dump file is not created by using setrlimit() to set the RLIMIT_CORE resource limit to 0 (see Details of Specific Resource Limits).
By default, Linux doesn’t permit a set-user-ID program to perform a core dump in response to a signal (Core Dump Files), even if the program has dropped all privileges. However, other UNIX implementations may not provide this security feature.