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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
