Bug#673112: lintian: hardening-no-stackprotector check has many false positives

[Kees Cook <kees@debian.org>]

On Tue, May 22, 2012 at 12:54:19PM +0200, Niels Thykier wrote:
> On 2012-05-21 20:25, Modestas Vainius wrote:
> For the record, I have just demoted no-stackprotector to a wild-guess
> (thus, it is now an I tag) and moved it to a separate profile
> (debian/extra-hardening) so it is no longer enabled by default.

Ah well. Too bad. Once build flags are exposed in the ELF itself, this
will just have to be the way it is.

> > On šeštadienis 19 Gegužė 2012 19:49:14 Russ Allbery wrote:
> >> Sven Joachim <svenjoac@gmx.de> writes:
> >>> Easier said then done, how should I override this warning:
> >>>
> >>> ,----
> >>>
> >>> | W: libncurses5: hardening-no-fortify-functions
> >>> | usr/lib/i386-linux-gnu/libmenu.so.5.9
> >>>
> >>> `----
> >>
> >> libncurses5 binary: hardening-no-fortify-functions usr/lib/*/libmenu.so.*
> > 
> > Well, I get this "nice" lintian output:
> > 
> > $ lintian -I amarok_2.5.0-2_amd64.changes
> > [...]
> > 
> > This is like 90 false positives in a single source package, it makes lintian
> > output unreadable. I don't know how this hardening stuff is detected but I
> > suspect this failure might be because the package is built with
> > -fvisibility=hidden. If so, all KDE packages will suffer, and badly.
> > 
> > [...]
> 
> We use hardening-check (from hardening-includes) - as I recall it
> carries a list of "unprotected functions" and checks for them (via
> readelf).  It maps them to a "safe-variant" and checks for that as well.
>  If both protected and unprotected are used or if no unprotected
> functions are used, it should mark it safe.  However,  I believe Kees
> (CC'ed) can correct me on (or confirm) the above.

Correct. If none of the functions are found, it passes. If there is a mix
of protected and unprotected, it passes. If only protected are found, it
passes. If only unprotected are found, it fails.

It is, however, still an heuristic, since it is possible to only use the
functions in ways that are compile-time verifiable, resulting in no need
for the protected wrapper.

-Kees

-- 
Kees Cook                                            @debian.org