lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 20 Apr 2017 20:13:32 -0300
From:   Henrique de Moraes Holschuh <hmh@....eng.br>
To:     Mehmet Kayaalp <mkayaalp@...ux.vnet.ibm.com>
Cc:     David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>,
        keyrings <keyrings@...r.kernel.org>,
        LSM <linux-security-module@...r.kernel.org>,
        kernel <linux-kernel@...r.kernel.org>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>,
        George Wilson <gcwilson@...ibm.com>
Subject: Re: [PATCH v4 1/4] KEYS: Insert incompressible bytes to reserve
 space in bzImage

On Thu, 20 Apr 2017, Mehmet Kayaalp wrote:
> Include a random filled binary in vmlinux at the space reserved with
> CONFIG_SYSTEM_EXTRA_CERTIFICATE. This results in an uncompressed reserved

Random data is not always going to be completely incompressible.  And
just how much it could be compressed also depends on the compression
engine.

Failures here would be quite annoying, even if they would be rare (not
just due to the randomness factor, but also depending on just how
overprovisioned the space reserved for the extra certificate was when
compared with the real certificate size).

Maybe it would be safer if you test it for incompressability once you
generated the random data (using the same compression engine that the
image will use)?  If it fails, add some overprovisioning and retry...

Alternatively, you could ship a static file with random data that has
been tested to be uncompressible "enough" for every currently supported
compression engine, maybe with a bit of a safety margin just in case a
future compression engine does somewhat better...

-- 
  Henrique Holschuh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ