1 What is LibSecRm?

LibSecRm (LIBrary for SECure ReMoval) is a set of replacements for these standard functions, which cause data removing from files. These functions are: ‘unlink’, ‘unlinkat’, ‘remove’ (obvious), ‘fopen’, ‘freopen’, ‘truncate’, ‘ftruncate’, ‘open’, ‘openat’ (with O_TRUNC passed in flags), ‘creat’ and their 64-bit versions. Also, ‘fallocate’ and ‘posix_fallocate’ are intercepted. The ‘syscall()’ function family will not be supported right now. This would probably double the work done with every wiping and is impossible anyway, because the number of parameters varies from one syscall to another.

These function replacements in LibSecRm first securely wipe the part of the file which would be deleted (just like shred, but only rejected parts of files get destroyed, not the whole files) to prevent leakage of sensitive data. After that, the original functions get called to do their job, so that the calling program can continue working as usual.

LibSecRm partially also takes care about memory security - some of the memory allocation functions are intercepted (namely: ‘malloc’, ‘posix_memalign’, ‘valloc’, ‘pvalloc’, ‘memalign’, ‘brk’, ‘sbrk’), and the allocated memory is wiped before passing it to the calling program.

In case of the functions which cause an object (file or directory) to be removed, after wiping it (in case of files), the object is renamed several times so even its name can’t be restored from the filesystem.

There is NO NEED to rebuild your software, because LibSecRm is a pre-loadable library, meaning you just need to RUN the software with LibSecRm loaded.

However, there are limitations. LibSecRm can do nothing if:

• The program using LibSecRm has no write permissions to the file,
• A program is using direct kernel calls, filesystem calls or non-standard calls, thus bypassing even the C library,
• LibSecRm is not loaded (Installing),
• A program is linked statically (so it doesn’t use shared libraries and has all the functions compiled in it),
• The operating system doesn’t support shared libraries (like DOS),
• The operating system doesn’t support preloading shared libraries before system libraries,
• LibSecRm is enabled by setting environment variables and a program is launched by another program, which clears the environment variables used by the dynamic linker, so the dynamic linker doesn’t preload LibSecRm. Some Java Runtime Environments seem to do this,
• A program is using functions not known to LibSecRm.

If unsure and security is very important, use the WipeFreeSpace program to clean the free space on the filesystem.

LibSecRm is also a library for programmers - look inside ${includedir}/ (default is /usr/local/include) for a header file with all the functions - libsecrm.h, and look inside ${libdir}/ (default is /usr/local/lib) for an "import library" - libsecrm.a.

NOTE To use LibSecRm as a development library, pass --enable-public-interface to ./configure and include the header BEFORE any system headers. Compile-time errors may occur otherwise. Remember to link your program with LibSecRm - adding -lsecrm (optionally preceded with -L ${libdir}) to GCC is enough. See the chapter on developing to learn how to use LibSecRm (Developing).

LibSecRm’s homepage is https://libsecrm.sourceforge.io.