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@xxxxxxxxxxxxxxxxxxxxxxxxx 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. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
