Proposal: Optional libsafe add-on?

[Warren Togami]

Proposal: Optional libsafe add-on?

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 at togami.com

[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.