Review Rules and staticly linked packages agains dietlibc

[Enrico Scholz]

pertusus at free.fr (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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060223/88ca0517/attachment.sig>