Bug#650536: [new check] test for missing hardening build flags
On 2011-12-02 01:33, Kees Cook wrote:
> Hi!
>
Hey,
Kees, Jakub and I had a chat about this yesterday in #d-devel. Also, I
have CC'ed Alexander due to your/his role as our backporter and as ftp
team member (Alexander, you may want to fast-foward to "Backporting
concerns" below).
> Attached is a first-pass at the lintian support for "hardening-check".
>
> There are two more things to do, which I'd like some direction on:
>
> 1) With these build tests added, all the other internal lintian tests
> need to either:
> a) add the new warnings to their "tags" file, or
> b) have all their builds adjusted to bring in the dpkg-buildflag
> defaults.
> It looks like a pretty large change, but it should be relatively
> mechanical to accomplish. I would think that "b" above is the better
> of the two options.
>
I suspect this is mostly about updating the template rules file +
correct a few extra tests. As an added benefit it should be fairly
trivial (if we ignore architecture specificness for a moment).
> 2) In reality, the tests are arch-dependent. For example, "relro" doesn't
> exist at all on ia64 hppa avr32, and "stackprotector" doesn't exist on
> ia64 alpha mips mipsel hppa arm. I think this expectation needs to be
> built into lintian's invocation of "hardening-check", but that means
> that the "tags" file in the internal lintian tests suddenly needs to
> be generated instead of being static. (i.e. on ia64 and hppa, "no-relro"
> shouldn't show up because it can never happen.)
>
I proposed the use of the "post_test" sed script here, which hopefully
should do for the actual test.
The question is if we will need it only for the hardening test or we
need it for all the tests with C-binaries. The latter would be very
inconvient.
Alternatively we can mark the tests architecture dependent. Though in
that case I would prefer being able to determine the architecture list
at test time. If we have to manually update the architecture list of
these tests, they will most likely end up being outdated and even
inconsistent.
> Thoughts?
>
> -Kees
>
Accuracy of the checks:
=======================
In the previous versions of hardening-check, the hardening function
check were prone to false-positives. If a binary was not using
protectable-functions at all it would have been tagged as unproected
(because there no protected functions in the binary). I am very pleased
to see that appears to have been fixed in the new version.
As I understand the code, this check should no longer have
false-positives. However it may have some false-negatives - particuarly
if protected and unprotected functions are mixed, it will assume the
binary is protected (in its Lintian output at least).
This check is not architecture dependent and should be fairly trivial
to include.
The stack-protector is architecture dependent (as mentioned above).
Protected binaries will have a certain symbol (__stack_chk_fail), but
not all binaries need it[1]. In this case the symbol will be absent
without the binary is vulnerable, which currently leads to false-positives.
As I understand [1], the protection is only needed if the binaries
have an array on the stack. Can we detect the presence (or absence) of
stack arrays (beyond relying on __stack_chk_fail or analysing the binary
code)? If we can, we should be able to reduce the false-positives.
Finally the relro. This is also architecture dependent, but I do not
know anything about false-positives or false-negatives here. Kees, your
patch marks it "certain" so I presume we have a low false-positive
rating here (if we ignore architecture for a moment)?
There was some talk about including an filter (either in Lintian or in
hardening-check) based on architecture to avoid false-positives in relro
and stack-protector for architectures that do not support them.
Backporting concerns and output stability:
==========================================
Both the FTP-masters and Lintian.d.o needs everything in stable (or
stable-backports). The hardening-wrapper package appears to be small
and trivial enough to backport in itself. But there might be a concern
in terms of the hardening-includes that (if changed) may affect backport
builds.
If we can get a reliable backporter for hardening-wrapper as well,
most of my concerns here covered. On the lintian.d.o side, it means we
may have to nag DSA for an upgrade of hardening-wrapper every now and then.
Jakub Wilk also expressed some concerns with the output of Lintian
would/could (?) vary with the version of hardening-wrapper. Personally
I am not too concerned here and I do not believe we have a conflict with
our "deterministic-output"-clause[2].
Aside from possible regressions in hardening-check, I suspect the
accuracy of it will only increase if anything. My greatest concern in
this area is more that it may break our test-suite (i.e. make Lintian
FTBFS).
I /think/ this should more or less cover the chat we had, plus my view
of the situation. Kees or Jakub, did I miss something?
~Niels
[1] https://wiki.debian.org/Hardening#Validation
[2] My understanding of this clause is that Lintian must produce the
same output on the same (set of) packages(s) if (but only if):
1. Lintian nor its dependencies have not been modified/upgraded/etc..
2. The packages that are tested have not been modified.
Reply to: