linux-kernel - Re: [PATCH v2 00/15] ima: digest list feature

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]

Message-ID: <CACdnJut0-4k97m0TM-Zd4jLPTraBe6_JoE-eznFYKwbPEmNS0Q@mail.gmail.com>
Date:   Wed, 8 Nov 2017 10:48:56 -0500
From:   Matthew Garrett <mjg59@...gle.com>
To:     Roberto Sassu <roberto.sassu@...wei.com>
Cc:     linux-integrity <linux-integrity@...r.kernel.org>,
        linux-security-module@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, silviu.vlasceanu@...wei.com
Subject: Re: [PATCH v2 00/15] ima: digest list feature

On Wed, Nov 8, 2017 at 7:00 AM, Roberto Sassu <roberto.sassu@...wei.com> wrote:
> On 11/7/2017 7:06 PM, Matthew Garrett wrote:
>> But we're still left in a state where the kernel has to end up
>> supporting a number of very niche formats, and userland agility is
>> tied to the kernel. I think it makes significantly more sense to push
>> the problem out to userland.
>
>
> At least for appraisal, digest lists must be parsed by the kernel. If
> the parser is moved to userspace, I don't know if we are able to provide
> the same guarantee, that the correct set of digests has been uploaded to
> IMA. A new measurement can be added, when IMA receives the digests, but
> a verifier has to verify the signature of the original file, perform
> format conversion, calculate the digest and compare it with that in the
> new IMA measurement. If digest lists are parsed directly by the kernel,
> then the signature can be verified directly.

The code doing the parsing is in the initramfs, which has already been
measured at boot time. You can guarantee that it's being done by
trusted code.

>> Isn't failing to upload the expected digest list just a DoS? We
>> already expect to load keys from initramfs, so it seems fine to parse
>> stuff there - what's the problem with extracting information from
>> RPMs, translating them to the generic format and pushing that into the
>> kernel?
>
>
> The main problem is that the digest list measurement, performed when the
> parser accesses the file containing the RPM header, might not reflect
> what IMA uses for digest lookup.

Why not?