SECURITY: New security policy text

Let's have a policy to handle security issues reported against
libabigail.

This security policy text is derived from the elfutils project one at
https://sourceware.org/cgit/elfutils/tree/SECURITY.

	* SECURITY: New security policy text file.
	* Makefile.am: Add the new SECURITY file to the distribution.

Signed-off-by: Dodji Seketeli <dodji@redhat.com>
Reviewed-by:   Frank Ch. Eigler <fche@redhat.com>
This commit is contained in:
Dodji Seketeli 2024-11-12 16:33:39 +01:00
parent 8f70e52e82
commit dc71c24fee
2 changed files with 35 additions and 1 deletions

View File

@ -21,7 +21,7 @@ autoconf-archive/ax_check_python_modules.m4 \
autoconf-archive/ax_prog_python_version.m4 \
autoconf-archive/ax_compare_version.m4 \
NEWS README LICENSE.txt license-change-2020.txt \
COMPILING COMMIT-LOG-GUIDELINES VISIBILITY \
COMPILING COMMIT-LOG-GUIDELINES VISIBILITY SECURITY \
ChangeLog gen-changelog.py \
$(headers) $(m4data_DATA) \
libabigail.pc.in

34
SECURITY Normal file
View File

@ -0,0 +1,34 @@
The libabigail library and utilities aim to be generally robust and
reliable. However, libabigail routinely processes complex binary
structured data. This makes the code intricate and sometimes brittle.
While libabigail developers use a variety of static and dynamic checker
software (valgrind, sanitizers) in testing, bugs may remain. Some of
these bugs may have security-related implications.
While many errors are cleanly detected at runtime, it is possible that
vulnerabilities exist that could be exploitable. These may arise from
crafted / fuzzed / erroneous inputs, or perhaps even from valid inputs
with unforseen characteristics. Therefore, to minimize risks, users
of libabigail tools and libraries should consider measures such as:
- avoiding running complex libabigail analysis on untrustworthy inputs
- avoiding running libabigail tools as privileged processes
- applying common platform level protection mechanisms such as
selinux, syscall filtering, hardened compilation, etc.
Since libabigail tools are usually run in short-lived, local,
interactive, development context rather than remotely "in production",
we generally treat malfunctions as ordinary bugs rather than security
vulnerabilities.
Please report bugs via any of:
- email to <libabigail@sourceware.org>
- https://sourceware.org/bugzilla/enter_bug.cgi?product=libabigail
After considering the above exclusions, please report suspected
security vulnerabilities confidentially via any of:
- email to <dodji@seketeli.org>
- email to <fche@elastic.org>
- email to <secalert@redhat.com>