[Unbound-users] Unbound release 1.4.12

[Gábor Lénárt]

On Tue, Jul 19, 2011 at 09:31:58AM +0200, Carsten Strotmann wrote:
> On 7/18/11 10:26 PM, Gábor Lénárt wrote:
> >> PIC-related slowdown is about 5% (or less) on x86 on my test
> >> including both multimedia and crypto operations.
> > And if I compile it "by hand" anyway, it can be
> > called nice to eliminate this, even if it only gives 5% or even just
> > 0.1% :)
> 
> There is a 'performance' vs. 'security' trade-off here. PIC/PIE
> compiling has been introduced for a reason, it usually increases the
> resilience against the damage done by certain attacks on security
> vulnerabilities in code:

I don't think it was the original idea behind this (but surely it can have
benefits you mention too): shared libraries are introduced because of the
need to shared (that's why the same: .so=shared object) common code which is
used by multiple running processes, thus it's a good idea not to have linked
the same functionality statically into each of them, etc.  Also it can be
useful to upgrade only the library but not the code itself which uses it,
which indeed can be useful.  From this point of view, I only use ldns with
unbound, so it's not a major win for me.  Also, if I would upgrade only ldns
or unbound I still recompile them together, getting the freshest copies of
each (now, because ldns is not shipped with unbound anymore), so I can't see
problem here.

> > PIE stands for 'Position Independent Executable' and describes a
> > function where the operating system can load certain parts of the
> > application at random positions inside the computers address space.
> > In some attacks the attacker needs to know beforehand on which memory
> > location a datastructure will be loaded (e.g. to jump into code that
> > has been written using a buffer overflow). By having the operating
> > system load the program code into different locations every time, the
> > attacker cannot predict the memory location, which makes it harder to
> > write a successful exploit.
> 
> http://blog.atariwiki.strotmann.de/roller/dnsworkshop/date/20110703
> 
> If you run Unbound in an untrusted network (e.g. Internet), having
> Unbound PIC/PIE compiled might be a good idea from a security point of view.

Surely, security can be increased even to a level where it goes unusable :)
Ok it was more like a joke and a general wishdom, what I meant that of
course there is always a balance between security and usability and
sometimes it's hard to find the "good way" between the two borders.

However I think all of you replied me here missed one point: as I've written
even in my first (or second?) mail, I don't think that unbound team "has no
right" to make the decision not to ship ldns "built-in" anymore, of course!
I only wrote because the explanation of the change was strange for me: that
distro maintrainers also asked for this move. However unbound configure
mechanism can be made in a way (if it was not before? I can't remember) to
only build and link against the built-in ldns _only_ if it was requested. So
then there is no problem, as it can't happen "by mistake": using built-in
ldns must be requested and never happen "automatically". That was the only
intent of my mail originally. Surely, we can discuss and mention more
advantages and/or disadvantages of this scheme but it's already another
question then.

The fact that I'd like to link against ldns statically is another topic, and
I don't want make others to beleive it's better or the opposite: it's just
my taste, nothing more or less. However what I mentioned was only the _real_
problem that --enable-static-exe should work, but it does not work for me,
which is a real issue (I think) regardless of arguing about the advantages
and disadvantages of my way to build unbound :)

- Gábor