linux-kernel - Re: [GIT PULL] Security subsystem changes for 4.3

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] [day] [month] [year] [list]

Date:	Tue, 8 Sep 2015 13:32:48 -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 changes for 4.3

On Mon, Aug 31, 2015 at 5:00 PM, James Morris <jmorris@...ei.org> wrote:
> Highlights:
>   o PKCS#7 support added to support signed kexec, also utilized for module
>     signing.

So when testing this, I realized that when somebody tries to load a
module with an invalid key, there doesn't seem to be any logs left
about that.

I don't think this is new, it's just that the certificate generation
changes made me test loading a module with the wrong cert, and while
module loading itself failed gracefully and correctly with ENOKEY
("Required key not available"), I also ended up checking dmesg,
because I - clearly incorrectly - thought that we'd warn the sysadmin
about this too).

So I think that module loading failures due to lack of keys really
should raise a few flags. Maybe the system is secure from some
attacks, but you'd still want to know that somebody tried to do
something fishy.

We *do* end up warning ("module verification failed") and tainting the
kernel if we end up loading the module despite the key failing, but
the situation I'm talking about is the "sig_enforce" case, which just
causes a module loading failure with no system warning.

                    Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/