Hi! As you fellow backporter I took a quick glance at the hardening-wrapper package, and didn't spotted any problems so far (as in: I could create a backport, install it, and can still compile stuff). However, as I'm not very familiar with it, I'll ping the maintainers for their opinion.
Also note that for Lenny there has already been a backport by Ulises Vitulli <der...@debian.org>, whom I'll have to ping before hijacking his former backport, too. Best regards, Alexander Am 03.12.2011 11:20, schrieb Niels Thykier: > 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. > -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ee07fbf.9070...@debian.org
