|
safec
3.0
Safe C Library - ISO TR24731 Bounds Checking Interface
|
:toc:
This project's licensing restrictions are documented in the file 'COPYING' under the root directory of this release. Basically it's MIT licensed.
This library implements the secure C11 Annex K functions on top of most libc implementations, which are missing from them.
The ISO TR24731 Bounds Checking Interface documents indicate that the key motivation for the new specification is to help mitigate the ever increasing security attacks, specifically the buffer overrun.
The rationale document says ``Buffer overrun attacks continue to be a security problem. Roughly 10% of vulnerability reports cataloged by CERT from 01/01/2005 to 07/01/2005 involved buffer overflows. Preventing buffer overruns is the primary, but not the only, motivation for this technical report.''
The rationale document continues ``that these only mitigate, that is lessen, security problems. When used properly, these functions decrease the danger buffer overrun attacks. Source code may remain vulnerable due to other bugs and security issues. The highest level of security is achieved by building in layers of security utilizing multiple strategies.''
.The rationale document lists the following key points for TR24731:
and the following can be added...
The C11 Standard adopted many of these points, and added some secure _s variants in the Annex K. The Microsoft Windows/MINGW secure API did the same, but deviated in some functions from the standard. Besides Windows only Android's Bionic and Embarcadero implemented this C11 secure Annex K API so far. They are still missing from glibc, musl, FreeBSD, darwin and DragonFly libc, OpenBSD libc, newlib, dietlibc, uClibc, minilibc.
This library implements since 3.0 all functions defined in the specifications. Included in the library are extensions to the specification to provide a complementary set of functions with like behavior.
This library is meant to be used on top of all the existing libc's which miss the secure C11 functions. Of course tighter integration into the system libc would be better, esp. with the printf, scanf and IO functions. See the seperate libc-overview document.
Austin Group Review of ISO/IEC WDTR 24731 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1106.txt
C11 standard (ISO/IEC 9899:2011) http://en.cppreference.com/w/c
Stackoverflow discussion: https://stackoverflow.com/questions/372980/do-you-use-the-tr-24731-safe-functions
The TR24731 specification says an implementation may set errno for the functions defined in the technical report, but is not required to. This library does not set errno. The library does use errno return codes as required by functional APIs. Specific Safe C String and Safe C Memory errno codes are defined in the safe_errno.h file.
Per the spec, the library verifies that the calling program does not violate the function's runtime-constraints. If a runtime-constraint is violated, the library calls the currently registered runtime-constraint handler.
Per the spec, multiple runtime-constraint violations in the same call to a library function result in only one call to the runtime-constraint handler. The first violation encountered invokes the runtime-constraint handler.
The runtime-constraint handler might not return. If the handler does return, the library function whose runtime-constraint was violated returns an indication of failure as given by the function’s return.
rsize_t:: The specification defines a new type. This type, rsize_t, is conditionally defined in the safe_lib.h header file.
RSIZE_MAX:: The specification defines the macro RSIZE_MAX which expands to a value of type rsize_t. The specification uses RSIZE_MAX for both the string functions and the memory functions. This implementation defines two macros: RSIZE_MAX_STR and RSIZE_MAX_MEM. RSIZE_MAX_STR defines the range limit for the safe string functions. RSIZE_MAX_MEM defines the range limit for the safe memory functions. The point is that string limits can and should be different from memory limits. There also exist RSIZE_MAX_WSTR, RSIZE_MAX_MEM16, RSIZE_MAX_MEM32.
The specification states the various functions would be added to existing Standard C header files: stdio.h, string.h, etc. This implementation separates the memory related functions into the safe_mem_lib.h header, the string related functions into the safe_str_lib.h header, and the rest into the safe_lib.h header.
The make file builds a single library libsafec-VERSION.a and .so in the src/.libs directory. Built but not installed are also libmemprims, libsafeccore and libstdunsafe.
It is possible to split the make such that a separate safe_mem_lib.so and safe_str_lib.so are built. It is also possible to integrate the prototypes into the Standard C header files, but that may require changes to your development tool chain.
The build system for the userspace library is the well known GNU build system, a.k.a. Autotools. This system is well understood and supported by many different platforms and distributions which should allow this library to be built on a wide variety of platforms. See the xref:tested-platforms[``Tested Platforms''] section for details on what platforms this library was tested on during its development.
Note that the library will behave differently if built with a C11 compiler or not. With C11 mem{cpy,move,set}_s smax/n=0 is allowed, before not.
For those familiar with autotools you can probably skip this part. For those not and want to get right to building the code see below. And, for those that need additional information see the 'INSTALL' file in the same directory.
.To build you do the following:
$ ./build-tools/autogen.sh $ ./configure $ make
'autogen.sh' only needs to be run if you are building from the git repository. Optionally, you can do ``make check'' if you want to run the unit tests.
Installation must be preformed by root, an `Administrator' on most systems. The following is used to install the library.
$ sudo make install
The build for the kernel module has not been integrated into the autotools build infrastructure. Consequently, you have to run a different makefile to build the kernel module.
.To build do the following:
$ ./configure $ make -f Makefile.kernel
This assumes you are compiling on a Linux box and this makefile supports the standard kernel build system infrastructure documented in: <linux-kernel-src-tree>/Documentation/kbuild/modules.txt
NOTE: If you build the kernel module then wish to build the userspace library or vice versa you will need to do a +make clean+ otherwise a +make check+ will fail to build.
The kernel module will be found at the root of the source tree called 'slkm.ko'. The file 'testslkm.ko' are the unit tests run on the userspace library but in Linux kernel module form to verify functionality within the kernel.
[[tested-platforms]]
.The library has been tested on the following systems
[bibliography] .References