Bug 176582 - Review Request: freedt -- Reimplementation of Dan Bernstein's daemontools under the GNU GPL
Summary: Review Request: freedt -- Reimplementation of Dan Bernstein's daemontools und...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Package Reviews List
Depends On:
Blocks: 176581
TreeView+ depends on / blocked
Reported: 2005-12-27 01:33 UTC by Enrico Scholz
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2007-07-07 08:33:47 UTC

Attachments (Terms of Use)

Description Enrico Scholz 2005-12-27 01:33:40 UTC
Spec Name or Url: http://ensc.de/fedora/freedt.spec
SRPM Name or Url: http://ensc.de/fedora/freedt-0.21-1.src.rpm
GNU Arch: ensc@ensc.de--fedora (http://ensc.de/tla/{archives}/fedora)


freedt is a reimplementation of Dan Bernstein's daemontools under the
GNU GPL, sharing no code with the original implementation.

It currently includes feature-equivalent replacements for argv0,
envdir, envuidgid, setlock, setuidgid, softlimit, supervise, svc,
svok, svscan, svstat and recordio. It also includes dumblog (a
simple multilog replacement), mkservice (a script for automatically
creating service directories), anonidentd (an anonymising identd
implementation) and ratelimit (a bandwidth-limiting filter along
the lines of recordio). All the tools include usage messages; for
instance, do "ratelimit -h" for a brief rundown of the options.

Please note that this package is not a drop-in replacement for
daemontools; the internal state files in service directories are
different, and the error messages (and a few of the options)
aren't quite the same. While it's stable enough that the author
(and several other people) are using it, it's also still somewhat
experimental, so the author recommends sticking with daemontools
on production systems until a stable release.

Comment 1 John Mahowald 2006-02-25 21:28:14 UTC
The binaries appear to be statically linked. This needs to be fixed unless
there's a real reason to do so.

Comment 2 Enrico Scholz 2006-02-26 18:00:09 UTC
1. linking dynamically creates significantly larger binaries (>50%);
   e.g. building with default settings and with '--without dietlibc'
   creates binaries with the following sizes (bytes):

			  diet	 glibc    glibc/diet
	anonidentd 	  6732	 11572		171%
	argv0      	  6580	 10304		156%
	dumblog    	  8636	 11784		136%
	envdir     	  7448	 11288		151%
	envuidgid  	  8624	 10752		124%
	mkservice  	  1286	  1286		100%
	ratelimit  	  8400	 13288		158%
	recordio   	    34	    34		100%
	setlock    	  7112	 11372		159%
	setuidgid  	  8852	 11160		126%
	softlimit  	  7440	 11696		157%
	supervise  	  8628	 14436		167%
	svc        	  6828	 11572		169%
	svok       	  5964	 10432		174%
	svscan     	  8632	 13200		152%
	svstat     	  6356	 11248		176%
			107552	165424		153%

2. linking dynamically slows down some programs significantly. To
   measure the time, I used


   and executed sequences like

   | for i in `seq 0 4`; do
   |   for F in diet glibc; do
   |     echo $F/$i;
   |     ( time ~/tmp/rep 100000 @@@CMD@@@ ) &>res.argv0.$F.$i;
   |   done;
   | done

   which starts '@@@CMD@@@' 100000 times. This resulted into the
   following times:

   argv0 (@@@CMD@@@ = 'argv0.$F /tmp/nop foo')

	           diet     glibc	glibc/diet
	real:	15.964s	  52.879s	       331%
	user:	 0.136s	   3.557s	      2615%	
	sys:	 5.396s	  14.604s	       270%

   envuid (@@@CMD@@@ = 'envuid.$F bin /tmp/nop')

	           diet     glibc	glibc/diet
	real:   25.500s	  83.016s	       325%
	user:    1.722s	   6.920s	       401%
	sys:	 6.965s	  20.451s	       293%

3. the security aspects of dynamic linking are not interesting for the
   freedt programs:

   * argv0, envdir, envuidgid, setuidgid, softlimit

     are pure command wrappers; they are not suid and you can not gain
     additional rights with an exploit

   * anonidentd: this server imports the following symbols from the

     - getpid, write, setgroups, setgid, chdir, fcntl, exit, setuid,
       read, chroot

       these are pure syscall wrappers which are implemented correctly
       and can not be exploited

     - sleep

       simple wrapper around nanosleep(2); can not be exploited

     - strchr, strncmp, strcat, strcpy, memcpy, memchr, memmove

       trivial memory operations which are implemented correctly by
       dietlibc and can not be exploited

     - getenv

       * lib/getenv.c implementation is correct
       * optimized i386/getenv.S implementation is correct
       * read environment will be set by calling process and can not
         be influenced by client-input

     - malloc, free, realloc

       * code (incl. comments) is 202 lines and reviewable; it takes
         care about integer-overflows, and the handling of internal
         hunk lists is correct. Underlying algorithms are simple,
         possible inputs are limited so based upon my review these
         functions are unexploitable

     - getopt

       * complicated, unreviewed code. But input can not be influenced
         by client-input so its usage within anonidentd is unexploitable

   * dumplog: input reading is the only, potential exploitable code;
     there only the following functions will be used from libc

     - read, malloc, free, realloc, memcpy: see above; these functions
       are implemented correctly

   * ratelimit: ditto to 'dumplog'

   * setlock: just an 'fcntl' wrapper; not suid and you could not gain
     additionals rights with an exploit

   * supervise: only user input is coming from a fifo which reads a
     single char. This is evaluated in a 'switch {}' statement without
     using a libc function

   * svc, svok, svstat: not suid, you can not gain additional rights
     with it

   * svscan:

     - uses opendir, readdir, closedir: <20 lines of code; could not
       detect something suspicious while reviewing them; only assumption
       is that MAP_ANON zeros the mmap'ed memory which is true on linux

4. this statement is not proved with numbers for this case, but memory
   consumption of dietlibc programs is significantly lower than with
   traditional glibc

SUMMARY: linking 'freedt' against dietlibc generates significantly
         smaller and faster binaries without lowering security. Therefore,
         it would be an error to use glibc in this case.

Comment 3 Fanny Augustin 2006-11-14 20:53:20 UTC
Reassigning  bugs from gdk (old RHN engineering Manager) to tsanders (current
RHN engineering manager)

Comment 4 Kevin Fenzi 2006-12-16 19:40:10 UTC
This bug is a unassigned fedora extras review request, so it should be assigned
to 'nobody@fedoraproject.org'. Feel free to change it back if I am mistaken. 

Comment 5 Jason Tibbitts 2007-07-06 17:34:06 UTC
FESCo voted against allowing ipsvd to link statically against dietlibc in
Fedora. I don't see how the outcome could be different for this package, but if
you want it to also be voted upon, please say so.

Comment 6 Enrico Scholz 2007-07-07 08:33:47 UTC
I am tired of such non-technical, political reasoned decisions. I am revoking
this review request.

Note You need to log in before you can comment on or make changes to this bug.