linux-kernel - Re: [GIT PULL] Security subsystem updates for 4.14

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: <CA+55aFw8wgA+jhBOhnY-TSdbPgiYcrFiipCV=rsS1=GQEN+JgQ@mail.gmail.com>
Date:   Thu, 7 Sep 2017 11:19:34 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     James Morris <jmorris@...ei.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [GIT PULL] Security subsystem updates for 4.14

On Mon, Sep 4, 2017 at 3:29 AM, James Morris <jmorris@...ei.org> wrote:
>
> IMA:
>   - A new integrity_read file operation method, avoids races when
>     calculating file hashes

Honestly, this seems really odd.

It documents that it needs to be called with i_rwsem held exclusively,
and even has a lockdep assert to that effect (well, not really: the
code claims "exclusive", but the lockdep assert does not), but I'm not
actually seeing anybody doing it.

Quite the reverse, I just see integrity_read_file() doing filp_open()
on the pathname and passing it to integrity_kernel_read() with no
locking.

It really looks like just pure garbage to me. I pulled, and I'm not
unpulling the whole thing. I don't think it's been tested, and I don't
think it can be right.

Tell me why I'm wrong, or tell me why that garbage made it in in the
first place?

                 Linus