pertusus@xxxxxxx (Patrice Dumas) writes: >> Which security issues? Tools in 'ipvsd' are doing only some syscalls >> resp. the (perhaps) exploitable code sits in ipvsd and not in dynamical >> linkable libraries. The 'ipvsd' code itself is so small that it can be > > Why couldn't there be an issue with a bug in dietlibc that opens a > security hole in ipvsd? 'ipvsd' (resp. the shipped programs) are doing | socket() -> bind() -> listen() -> accept() -> [...] -> execve() The [...] part is the only place were an exploit can happen and there will be done: * DNS queries; this is indeed critically but it is done completely by 'ipvsd' without using an external library. So, dynamic linking would not increase security * environ-manipulation; this happens within 'ipvsd' too and sentence above applies too * lookup of the peer in a CDB database managed completely by internal code; ditto So, exploits opened by 'dietlibc' can be excluded for 'ipvsd'. >> No, the choice is between ??? (sorry, I do not have an idea which >> positive property would be brought in by 'glibc' linking) against >> efficiency and building 'ipvsvd' with the tools it was designed for. > > You cannot rule out security issues in the library easily as long as > the library is used, and ipvsd is a networking app, so security > matters. In another posting I gave a complete list of used *libc symbols. These were either simple syscall wrappers or well audited code (e.g. malloc()) so you will the same (or better) security as with glibc (which is much more complicated to audit than dietlibc). Enrico
Attachment:
pgpnwK8k9v7MV.pgp
Description: PGP signature
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
