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 (http://ensc.de/tla/{archives}/fedora) freedt--review--0 Description: 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.
The binaries appear to be statically linked. This needs to be fixed unless there's a real reason to do so.
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.
Reassigning bugs from gdk (old RHN engineering Manager) to tsanders (current RHN engineering manager)
This bug is a unassigned fedora extras review request, so it should be assigned to 'nobody'. Feel free to change it back if I am mistaken.
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.
I am tired of such non-technical, political reasoned decisions. I am revoking this review request.