From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: [PATCH V40 04/29] lockdown: Enforce module signatures if the kernel is locked down Date: Wed, 4 Sep 2019 09:57:52 -0700 Message-ID: References: <20190820001805.241928-1-matthewgarrett@google.com> <20190820001805.241928-5-matthewgarrett@google.com> <3638.1567182673@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <3638.1567182673@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org To: David Howells Cc: James Morris , LSM List , Linux Kernel Mailing List , Linux API , Kees Cook , Jessica Yu List-Id: linux-api@vger.kernel.org On Fri, Aug 30, 2019 at 9:31 AM David Howells wrote: > > Matthew Garrett wrote: > > > enum lockdown_reason { > > LOCKDOWN_NONE, > > + LOCKDOWN_MODULE_SIGNATURE, > > LOCKDOWN_INTEGRITY_MAX, > > LOCKDOWN_CONFIDENTIALITY_MAX, > > }; > > Aren't you mixing disjoint sets? The goal is to be able to check whether any given lockdown reason is a matter of integrity or confidentiality in a straightforward way. > > + [LOCKDOWN_MODULE_SIGNATURE] = "unsigned module loading", > > Wouldn't it be better to pass this string as a parameter to > security_locked_down()? I thought about that, but it's not how any other LSM hooks behave. I think it's probably easier to revisit that when we see how other LSMs want to make use of the data.