I personally have been using libsafe on all of my RH7.x, RH8 and RH9 servers with apparently no ill effects in these past years [1]. libsafe intercepts many of the potentially dangerous glibc calls like string operations, and replaces it with functionally equivalent functions. If it detects an overflow or format string exception, the process group is sent SIGKILL and a /var/log/secure entry is generated. The following list of functions is from the libsafe manpage.
strcpy(char *dest, const char *src)
strpcpy(char *dest, const char *src)
wcscpy(wchar_t *dest, const wchar_t *src)
wcpcpy(wchar_t *dest, const wchar_t *src)
May overflow the dest buffer. strcat(char *dest, const char *src)
wcscat(wchar_t *dest, const wchar_t *src)
May overflow the dest buffer. getwd(char *buf)
May overflow the buf buffer. gets(char *s)
May overflow the s buffer. [vf]scanf(const char *format, ...)
May overflow its arguments. realpath(char *path, char resolved_path[])
May overflow the path buffer. [v]sprintf(char *str, const char *format, ...)
May overflow the str buffer.
May exploit "%n".What I find especially attractive about libsafe is that it is exceedingly easy to install. Simply install the libsafe RPM and restart your daemons, and they should be protected. It is true that it is not COMPLETE protection, higher overhead than exec-shield, and not as paranoid protection as propolice. [2] However due to this easy-to-install-and-use nature and the fact that it provides SOME protection, I feel it is better than nothing.
For Legacy I am thinking to either put libsafe into the legacy-utils channel for sysadmins to install at their option, or keep it on the webpage so they need to install it manually only after reading how it works, and associated warnings about potential BAD BEHAVIOR and to test again after uninstalling it if weird stuff happens. [3] The must-install-manually-from-webpage option may be best due to [1] footnote below.
https://bugzilla.fedora.us/show_bug.cgi?id=163
The libsafe package needs fixing if Legacy wants to use it. It must remain the old fedora.us-style package naming in order to not conflict with fedora.us' libsafe.
Thoughts?
Warren Togami warren@xxxxxxxxxx
[1]
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89145
RH9's glibc introduced some behavior where libsafe would cause segfaults in this case of useradd where uninitialized memory was being read. It turned out that selinux also caused this segfault, so the problem has finally been patched in rawhide for FC2.
If Legacy pushes an optional libsafe within the legacy-utils channel in April 2004 for RH9, it should require also optional shadow-utils upgrade to prevent this useradd segfault problem. QA needs to match ldd output in order to verify that no functionality was lost due to missing BuildRequires.
[2]
http://www.research.ibm.com/trl/projects/security/ssp/
propolice is IBM research's gcc extensions for all sorts of security protection stuff in the resulting binaries when coupled with patched glibc. They claim it is far more complete than stackguard compiler (Immunix) while lower overhead than any other protection mechanism. OpenBSD uses propolice compiler by default now I believe.
[3]
While I personally have never run into any bad behavior due to libsafe in RH7.x through RH9 other than the above shadow-utils problem, I personally use mainly software distributed in the RH core distribution and fedora.us. Java seems fine too. I have zero experience running stuff like Oracle or other massive proprietary software... but arguably those folks should have moved to RHEL or other better commercially supported distributions a long time ago anyway.
