[Bug 176582] Review Request: freedt -- Reimplementation of Dan Bernstein's daemontools under the GNU GPL

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: freedt -- Reimplementation of Dan Bernstein's daemontools under the GNU GPL


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582





------- Additional Comments From enrico.scholz at informatik.tu-chemnitz.de  2006-02-26 13:00 EST -------
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

	   http://ensc.de/freedt/rep.c
	   http://ensc.de/freedt/nop.S

   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
     libc:

     - 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
       platforms



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.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.