The kernel can be configured to verify the appended kernel module
signature, the IMA signature stored as an xattr, both types of
signatures, or none. On systems with secure boot enabled AND the IMA
architecture specific policy enabled, this patch set requires the file
to be signed.
Both methods of loading kernel modules - init_module and finit_module
syscalls - need to either verify the kernel module signature or prevent
the kernel module from being loaded.
"modprobe" first tries loading the kernel module via the finit_module
syscall and falls back to the init_module syscall, making it difficult
to test one syscall and then the other.
Mimi Zohar (1):
x86/ima: require signed kernel modules
arch/x86/kernel/ima_arch.c | 9 ++++++++-
include/linux/module.h | 7 ++++++-
kernel/module.c | 15 +++++++++++----
security/integrity/ima/ima_main.c | 2 +-
4 files changed, 26 insertions(+), 7 deletions(-)
--
2.7.5
Require signed kernel modules on systems with secure boot mode enabled.
To coordinate between appended kernel module signatures and IMA
signatures, only define an IMA MODULE_CHECK policy rule if
CONFIG_MODULE_SIG is not enabled.
This patch defines a function named set_module_sig_required() and renames
is_module_sig_enforced() to is_module_sig_enforced_or_required(). The
call to set_module_sig_required() is dependent on CONFIG_IMA_ARCH_POLICY
being enabled.
Signed-off-by: Mimi Zohar <[email protected]>
---
arch/x86/kernel/ima_arch.c | 9 ++++++++-
include/linux/module.h | 7 ++++++-
kernel/module.c | 15 +++++++++++----
security/integrity/ima/ima_main.c | 2 +-
4 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/ima_arch.c b/arch/x86/kernel/ima_arch.c
index e47cd9390ab4..96a023238a83 100644
--- a/arch/x86/kernel/ima_arch.c
+++ b/arch/x86/kernel/ima_arch.c
@@ -64,12 +64,19 @@ static const char * const sb_arch_rules[] = {
"appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig",
#endif /* CONFIG_KEXEC_VERIFY_SIG */
"measure func=KEXEC_KERNEL_CHECK",
+#if !IS_ENABLED(CONFIG_MODULE_SIG)
+ "appraise func=MODULE_CHECK appraise_type=imasig",
+#endif
+ "measure func=MODULE_CHECK",
NULL
};
const char * const *arch_get_ima_policy(void)
{
- if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot())
+ if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
+ if (IS_ENABLED(CONFIG_MODULE_SIG))
+ set_module_sig_required();
return sb_arch_rules;
+ }
return NULL;
}
diff --git a/include/linux/module.h b/include/linux/module.h
index 8fa38d3e7538..af51c8ec755f 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -659,7 +659,8 @@ static inline bool is_livepatch_module(struct module *mod)
}
#endif /* CONFIG_LIVEPATCH */
-bool is_module_sig_enforced(void);
+bool is_module_sig_enforced_or_required(void);
+void set_module_sig_required(void);
#else /* !CONFIG_MODULES... */
@@ -780,6 +781,10 @@ static inline bool is_module_sig_enforced(void)
return false;
}
+static inline void set_module_sig_required(void)
+{
+}
+
/* Dereference module function descriptor */
static inline
void *dereference_module_function_descriptor(struct module *mod, void *ptr)
diff --git a/kernel/module.c b/kernel/module.c
index 2ad1b5239910..70a9709d19eb 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -275,16 +275,23 @@ static void module_assert_mutex_or_preempt(void)
static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE);
module_param(sig_enforce, bool_enable_only, 0644);
+static bool sig_required;
/*
* Export sig_enforce kernel cmdline parameter to allow other subsystems rely
* on that instead of directly to CONFIG_MODULE_SIG_FORCE config.
*/
-bool is_module_sig_enforced(void)
+bool is_module_sig_enforced_or_required(void)
{
- return sig_enforce;
+ return sig_enforce || sig_required;
}
-EXPORT_SYMBOL(is_module_sig_enforced);
+EXPORT_SYMBOL(is_module_sig_enforced_or_required);
+
+void set_module_sig_required(void)
+{
+ sig_required = true;
+}
+EXPORT_SYMBOL(set_module_sig_required);
/* Block module loading/unloading? */
int modules_disabled = 0;
@@ -2789,7 +2796,7 @@ static int module_sig_check(struct load_info *info, int flags)
}
/* Not having a signature is only an error if we're strict. */
- if (err == -ENOKEY && !is_module_sig_enforced())
+ if (err == -ENOKEY && !is_module_sig_enforced_or_required())
err = 0;
return err;
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 357edd140c09..bbaf87f688be 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -563,7 +563,7 @@ int ima_load_data(enum kernel_load_data_id id)
}
break;
case LOADING_MODULE:
- sig_enforce = is_module_sig_enforced();
+ sig_enforce = is_module_sig_enforced_or_required();
if (ima_enforce && (!sig_enforce
&& (ima_appraise & IMA_APPRAISE_MODULES))) {
--
2.7.5
On Thu, Jan 31, 2019 at 02:18:59PM -0500, Mimi Zohar wrote:
> diff --git a/kernel/module.c b/kernel/module.c
> index 2ad1b5239910..70a9709d19eb 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -275,16 +275,23 @@ static void module_assert_mutex_or_preempt(void)
>
> static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE);
> module_param(sig_enforce, bool_enable_only, 0644);
> +static bool sig_required;
>
> /*
> * Export sig_enforce kernel cmdline parameter to allow other subsystems rely
> * on that instead of directly to CONFIG_MODULE_SIG_FORCE config.
But the docs were't updated.
> */
> -bool is_module_sig_enforced(void)
> +bool is_module_sig_enforced_or_required(void)
> {
> - return sig_enforce;
> + return sig_enforce || sig_required;
> }
> -EXPORT_SYMBOL(is_module_sig_enforced);
> +EXPORT_SYMBOL(is_module_sig_enforced_or_required);
Meh, this is getting sloppy, the module signing infrastructure should
just be LSM'ified now that we have stacked LSMs. That would
compartamentaliz that code and make this much easier to read / understand
and mantain.
Can you take a look at doing it that way instead?
> +
> +void set_module_sig_required(void)
> +{
> + sig_required = true;
> +}
> +EXPORT_SYMBOL(set_module_sig_required);
Since this is a *new* symbol, not yet used, and only used by IMA I'd
prefer this to be EXPORT_SYMBOL_GPL().
> /* Block module loading/unloading? */
> int modules_disabled = 0;
> @@ -2789,7 +2796,7 @@ static int module_sig_check(struct load_info *info, int flags)
> }
>
> /* Not having a signature is only an error if we're strict. */
> - if (err == -ENOKEY && !is_module_sig_enforced())
> + if (err == -ENOKEY && !is_module_sig_enforced_or_required())
This is where I think a proper LSM hook would make sense. I think
that these "questions" model for signing don't work well on the LSM
hook model, perhaps just:
kernel_module_signed()
Suffices, therefore if not enforced or required its signed. If its
enforced or required and really signed, then it signed.
> err = 0;
>
> return err;
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 357edd140c09..bbaf87f688be 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -563,7 +563,7 @@ int ima_load_data(enum kernel_load_data_id id)
> }
> break;
> case LOADING_MODULE:
> - sig_enforce = is_module_sig_enforced();
> + sig_enforce = is_module_sig_enforced_or_required();
Yet another user.
> if (ima_enforce && (!sig_enforce
> && (ima_appraise & IMA_APPRAISE_MODULES))) {
> --
> 2.7.5
Plus I think LSM'ifying module signing may help cleaning up some of the
#ifdery and config options around module signing. I'm suggestin this now
as this has been on my mental TODO list for a while, and just not sure
when we'd get to it, if not you, not sure when it'd get done.
Then, do we have proper unit tests for the mixture of options to ensure
we can easily ensure we don't regress?
Luis
On Mon, Feb 04, 2019 at 05:05:10PM -0500, Mimi Zohar wrote:
> On Mon, 2019-02-04 at 12:38 -0800, Luis Chamberlain wrote:
> > On Thu, Jan 31, 2019 at 02:18:59PM -0500, Mimi Zohar wrote:
> > > diff --git a/kernel/module.c b/kernel/module.c
> > > index 2ad1b5239910..70a9709d19eb 100644
> > > --- a/kernel/module.c
> > > +++ b/kernel/module.c
> > > @@ -275,16 +275,23 @@ static void module_assert_mutex_or_preempt(void)
> > >
> > > static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE);
> > > module_param(sig_enforce, bool_enable_only, 0644);
> > > +static bool sig_required;
> > >
> > > /*
> > > * Export sig_enforce kernel cmdline parameter to allow other subsystems rely
> > > * on that instead of directly to CONFIG_MODULE_SIG_FORCE config.
> >
> > But the docs were't updated.
>
> Neither "CONFIG_MODULE_SIG_FORCE" nor "module.sig_enforce" has
> changed. ?Which docs are you referring to??
You renamed is_module_sig_enforced() to is_module_sig_enforced_or_required()
and left the above doc which only justifies the enforced path.
> > > */
> > > -bool is_module_sig_enforced(void)
> > > +bool is_module_sig_enforced_or_required(void)
> > > {
> > > - return sig_enforce;
> > > + return sig_enforce || sig_required;
> > > }
> > > -EXPORT_SYMBOL(is_module_sig_enforced);
> > > +EXPORT_SYMBOL(is_module_sig_enforced_or_required);
> >
> > Meh, this is getting sloppy, the module signing infrastructure should
> > just be LSM'ified now that we have stacked LSMs. That would
> > compartamentaliz that code and make this much easier to read / understand
> > and mantain.
> >
> > Can you take a look at doing it that way instead?
>
> This patch is about coordinating the existing methods of verifying
> kernel module signatures.
I understand.
> >
> > > /* Block module loading/unloading? */
> > > int modules_disabled = 0;
> > > @@ -2789,7 +2796,7 @@ static int module_sig_check(struct load_info *info, int flags)
> > > }
> > >
> > > /* Not having a signature is only an error if we're strict. */
> > > - if (err == -ENOKEY && !is_module_sig_enforced())
> > > + if (err == -ENOKEY && !is_module_sig_enforced_or_required())
> >
> > This is where I think a proper LSM hook would make sense. I think
> > that these "questions" model for signing don't work well on the LSM
> > hook model, perhaps just:
> >
> > kernel_module_signed()
> >
> > Suffices, therefore if not enforced or required its signed. If its
> > enforced or required and really signed, then it signed.
> >
> > > err = 0;
> > >
> > > return err;
> > > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> > > index 357edd140c09..bbaf87f688be 100644
> > > --- a/security/integrity/ima/ima_main.c
> > > +++ b/security/integrity/ima/ima_main.c
> > > @@ -563,7 +563,7 @@ int ima_load_data(enum kernel_load_data_id id)
> > > }
> > > break;
> > > case LOADING_MODULE:
> > > - sig_enforce = is_module_sig_enforced();
> > > + sig_enforce = is_module_sig_enforced_or_required();
> >
> > Yet another user.
> >
> > > if (ima_enforce && (!sig_enforce
> > > && (ima_appraise & IMA_APPRAISE_MODULES))) {
> > > --
> > > 2.7.5
> >
> > Plus I think LSM'ifying module signing may help cleaning up some of the
> > #ifdery and config options around module signing. I'm suggestin this now
> > as this has been on my mental TODO list for a while, and just not sure
> > when we'd get to it, if not you, not sure when it'd get done.
> >
> > Then, do we have proper unit tests for the mixture of options to ensure
> > we can easily ensure we don't regress?
> >
>
> There are already two methods ?- appended signatures and IMA xattrs -
> for validating kernel modules.
>
> Kernel modules shouldn't be treated any differently than any other
> file.
The good 'ol kernel module signing code *does* treat it as such.
> Based on the IMA policy, the kernel module signature can be
> verified. ?Also based on the IMA policy, the file hash added to the
> measurement list, and the file hash used to extend the TPM PCR.
> ?Lastly, based on policy the file hash can be added to the audit log.
Sure...
> I don't see a need for an additional LSM just for verifying kernel
> module signatures.
But it is one, module signing was just spawned pre the boom of LSMs.
I do believe that treating the code as such would help with its reading
and long term maintenance.
Anyway, I had to try to convince you.
Luis
On Mon, 2019-02-04 at 12:38 -0800, Luis Chamberlain wrote:
> On Thu, Jan 31, 2019 at 02:18:59PM -0500, Mimi Zohar wrote:
> > diff --git a/kernel/module.c b/kernel/module.c
> > index 2ad1b5239910..70a9709d19eb 100644
> > --- a/kernel/module.c
> > +++ b/kernel/module.c
> > @@ -275,16 +275,23 @@ static void module_assert_mutex_or_preempt(void)
> >
> > static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE);
> > module_param(sig_enforce, bool_enable_only, 0644);
> > +static bool sig_required;
> >
> > /*
> > * Export sig_enforce kernel cmdline parameter to allow other subsystems rely
> > * on that instead of directly to CONFIG_MODULE_SIG_FORCE config.
>
> But the docs were't updated.
Neither "CONFIG_MODULE_SIG_FORCE" nor "module.sig_enforce" has
changed. Which docs are you referring to?
>
> > */
> > -bool is_module_sig_enforced(void)
> > +bool is_module_sig_enforced_or_required(void)
> > {
> > - return sig_enforce;
> > + return sig_enforce || sig_required;
> > }
> > -EXPORT_SYMBOL(is_module_sig_enforced);
> > +EXPORT_SYMBOL(is_module_sig_enforced_or_required);
>
> Meh, this is getting sloppy, the module signing infrastructure should
> just be LSM'ified now that we have stacked LSMs. That would
> compartamentaliz that code and make this much easier to read / understand
> and mantain.
>
> Can you take a look at doing it that way instead?
This patch is about coordinating the existing methods of verifying
kernel module signatures.
>
> > +
> > +void set_module_sig_required(void)
> > +{
> > + sig_required = true;
> > +}
> > +EXPORT_SYMBOL(set_module_sig_required);
>
> Since this is a *new* symbol, not yet used, and only used by IMA I'd
> prefer this to be EXPORT_SYMBOL_GPL().
Oops, this function shouldn't be exported.
>
> > /* Block module loading/unloading? */
> > int modules_disabled = 0;
> > @@ -2789,7 +2796,7 @@ static int module_sig_check(struct load_info *info, int flags)
> > }
> >
> > /* Not having a signature is only an error if we're strict. */
> > - if (err == -ENOKEY && !is_module_sig_enforced())
> > + if (err == -ENOKEY && !is_module_sig_enforced_or_required())
>
> This is where I think a proper LSM hook would make sense. I think
> that these "questions" model for signing don't work well on the LSM
> hook model, perhaps just:
>
> kernel_module_signed()
>
> Suffices, therefore if not enforced or required its signed. If its
> enforced or required and really signed, then it signed.
>
> > err = 0;
> >
> > return err;
> > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> > index 357edd140c09..bbaf87f688be 100644
> > --- a/security/integrity/ima/ima_main.c
> > +++ b/security/integrity/ima/ima_main.c
> > @@ -563,7 +563,7 @@ int ima_load_data(enum kernel_load_data_id id)
> > }
> > break;
> > case LOADING_MODULE:
> > - sig_enforce = is_module_sig_enforced();
> > + sig_enforce = is_module_sig_enforced_or_required();
>
> Yet another user.
>
> > if (ima_enforce && (!sig_enforce
> > && (ima_appraise & IMA_APPRAISE_MODULES))) {
> > --
> > 2.7.5
>
> Plus I think LSM'ifying module signing may help cleaning up some of the
> #ifdery and config options around module signing. I'm suggestin this now
> as this has been on my mental TODO list for a while, and just not sure
> when we'd get to it, if not you, not sure when it'd get done.
>
> Then, do we have proper unit tests for the mixture of options to ensure
> we can easily ensure we don't regress?
>
There are already two methods - appended signatures and IMA xattrs -
for validating kernel modules.
Kernel modules shouldn't be treated any differently than any other file. Based on the IMA policy, the kernel module signature can be verified. Also based on the IMA policy, the file hash added to the measurement list, and the file hash used to extend the TPM PCR. Lastly, based on policy the file hash can be added to the audit log.
I don't see a need for an additional LSM just for verifying kernel module signatures.
Mimi
On Mon, 2019-02-04 at 14:30 -0800, Luis Chamberlain wrote:
> On Mon, Feb 04, 2019 at 05:05:10PM -0500, Mimi Zohar wrote:
> > On Mon, 2019-02-04 at 12:38 -0800, Luis Chamberlain wrote:
> > I don't see a need for an additional LSM just for verifying kernel
> > module signatures.
>
> But it is one, module signing was just spawned pre the boom of LSMs.
>
> I do believe that treating the code as such would help with its reading
> and long term maintenance.
>
> Anyway, I had to try to convince you.
Perhaps, after IMA supports appended signatures (for kernel modules),
I could see making the existing kernel module appended signature
verification an LSM.
For now, other than updating the comment, would you be willing to add
your Review/Ack to this patch?
Mimi
On Thu, Jan 31, 2019 at 02:18:59PM -0500, Mimi Zohar wrote:
> Require signed kernel modules on systems with secure boot mode enabled.
>
> To coordinate between appended kernel module signatures and IMA
> signatures, only define an IMA MODULE_CHECK policy rule if
> CONFIG_MODULE_SIG is not enabled.
>
> This patch defines a function named set_module_sig_required() and renames
> is_module_sig_enforced() to is_module_sig_enforced_or_required(). The
> call to set_module_sig_required() is dependent on CONFIG_IMA_ARCH_POLICY
> being enabled.
>
> Signed-off-by: Mimi Zohar <[email protected]>
With respect to interactions with the kernel lockdown patches, this
looks better than the patches I saw previously. I don't feel like I know
enough about what's going on with IMA to ack the patch, but I feel
confident that it's at least not going to break signature enforcement
for us.
Thanks,
Seth
On 01/31/2019 02:18 PM, Mimi Zohar wrote:
> Require signed kernel modules on systems with secure boot mode enabled.
>
> To coordinate between appended kernel module signatures and IMA
> signatures, only define an IMA MODULE_CHECK policy rule if
> CONFIG_MODULE_SIG is not enabled.
>
> This patch defines a function named set_module_sig_required() and renames
> is_module_sig_enforced() to is_module_sig_enforced_or_required(). The
> call to set_module_sig_required() is dependent on CONFIG_IMA_ARCH_POLICY
> being enabled.
>
> Signed-off-by: Mimi Zohar <[email protected]>
> ---
>
Reviewed-by: Nayna Jain <[email protected]>
Thanks & Regards,
- Nayna
Hi Seth,
On Tue, 2019-02-05 at 09:18 -0600, Seth Forshee wrote:
> On Thu, Jan 31, 2019 at 02:18:59PM -0500, Mimi Zohar wrote:
> > Require signed kernel modules on systems with secure boot mode enabled.
> >
> > To coordinate between appended kernel module signatures and IMA
> > signatures, only define an IMA MODULE_CHECK policy rule if
> > CONFIG_MODULE_SIG is not enabled.
> >
> > This patch defines a function named set_module_sig_required() and renames
> > is_module_sig_enforced() to is_module_sig_enforced_or_required(). The
> > call to set_module_sig_required() is dependent on CONFIG_IMA_ARCH_POLICY
> > being enabled.
> >
> > Signed-off-by: Mimi Zohar <[email protected]>
>
> With respect to interactions with the kernel lockdown patches, this
> looks better than the patches I saw previously. I don't feel like I know
> enough about what's going on with IMA to ack the patch, but I feel
> confident that it's at least not going to break signature enforcement
> for us.
Thank you for testing! Could this be translated into a "tested-by"
"(for w/lockdown patches)"?
Mimi
On Tue, Feb 05, 2019 at 11:47:24AM -0500, Mimi Zohar wrote:
> Hi Seth,
>
> On Tue, 2019-02-05 at 09:18 -0600, Seth Forshee wrote:
> > On Thu, Jan 31, 2019 at 02:18:59PM -0500, Mimi Zohar wrote:
> > > Require signed kernel modules on systems with secure boot mode enabled.
> > >
> > > To coordinate between appended kernel module signatures and IMA
> > > signatures, only define an IMA MODULE_CHECK policy rule if
> > > CONFIG_MODULE_SIG is not enabled.
> > >
> > > This patch defines a function named set_module_sig_required() and renames
> > > is_module_sig_enforced() to is_module_sig_enforced_or_required(). The
> > > call to set_module_sig_required() is dependent on CONFIG_IMA_ARCH_POLICY
> > > being enabled.
> > >
> > > Signed-off-by: Mimi Zohar <[email protected]>
> >
> > With respect to interactions with the kernel lockdown patches, this
> > looks better than the patches I saw previously. I don't feel like I know
> > enough about what's going on with IMA to ack the patch, but I feel
> > confident that it's at least not going to break signature enforcement
> > for us.
>
> Thank you for testing! Could this be translated into a "tested-by"
> "(for w/lockdown patches)"?
Yeah, that's fine. To be clear about what I tested, I've confirmed that
it doesn't interfere with requiring signed modules under lockdown with
CONFIG_IMA_ARCH_POLICY=n and IMA appraisal enabled.
Tested-by: Seth Forshee <[email protected]>
On Tue, 2019-02-05 at 12:32 -0600, Seth Forshee wrote:
> On Tue, Feb 05, 2019 at 11:47:24AM -0500, Mimi Zohar wrote:
> > Hi Seth,
> >
> > On Tue, 2019-02-05 at 09:18 -0600, Seth Forshee wrote:
> > > On Thu, Jan 31, 2019 at 02:18:59PM -0500, Mimi Zohar wrote:
> > > > Require signed kernel modules on systems with secure boot mode enabled.
> > > >
> > > > To coordinate between appended kernel module signatures and IMA
> > > > signatures, only define an IMA MODULE_CHECK policy rule if
> > > > CONFIG_MODULE_SIG is not enabled.
> > > >
> > > > This patch defines a function named set_module_sig_required() and renames
> > > > is_module_sig_enforced() to is_module_sig_enforced_or_required(). The
> > > > call to set_module_sig_required() is dependent on CONFIG_IMA_ARCH_POLICY
> > > > being enabled.
> > > >
> > > > Signed-off-by: Mimi Zohar <[email protected]>
> > >
> > > With respect to interactions with the kernel lockdown patches, this
> > > looks better than the patches I saw previously. I don't feel like I know
> > > enough about what's going on with IMA to ack the patch, but I feel
> > > confident that it's at least not going to break signature enforcement
> > > for us.
> >
> > Thank you for testing! Could this be translated into a "tested-by"
> > "(for w/lockdown patches)"?
>
> Yeah, that's fine. To be clear about what I tested, I've confirmed that
> it doesn't interfere with requiring signed modules under lockdown with
> CONFIG_IMA_ARCH_POLICY=n and IMA appraisal enabled.
>
> Tested-by: Seth Forshee <[email protected]>
Oh! You've disabled the coordination of the two signature
verification methods. Any chance you could test with
"CONFIG_IMA_ARCH_POLICY" enabled?
Mimi
On Tue, Feb 05, 2019 at 07:24:39AM -0500, Mimi Zohar wrote:
> On Mon, 2019-02-04 at 14:30 -0800, Luis Chamberlain wrote:
> > On Mon, Feb 04, 2019 at 05:05:10PM -0500, Mimi Zohar wrote:
> > > On Mon, 2019-02-04 at 12:38 -0800, Luis Chamberlain wrote:
>
> > > I don't see a need for an additional LSM just for verifying kernel
> > > module signatures.
> >
> > But it is one, module signing was just spawned pre the boom of LSMs.
> >
> > I do believe that treating the code as such would help with its reading
> > and long term maintenance.
> >
> > Anyway, I had to try to convince you.
>
> Perhaps, after IMA supports appended signatures (for kernel modules),
> I could see making the existing kernel module appended signature
> verification an LSM.
I don't see why wait.
> For now, other than updating the comment, would you be willing to add
> your Review/Ack to this patch?
But I don't particularly like the changes, I still believe trying to
LSM'ify kernel module signing would be a better start to help with
long term maintenace on this code.
Also, do we have selftests implemented to ensure we don't regress with
your changes?
Luis
On Tue, 2019-02-05 at 13:13 -0800, Luis Chamberlain wrote:
> Also, do we have selftests implemented to ensure we don't regress with
> your changes?
We're working on a regression test. "modprobe" currently first
attempts to use finit_module, and then falls back to using
init_module. Before writing a small program to load kernel modules,
are you aware of any that allows you to specify the syscall?
Mimi
On Tue, Feb 05, 2019 at 01:52:21PM -0500, Mimi Zohar wrote:
> On Tue, 2019-02-05 at 12:32 -0600, Seth Forshee wrote:
> > On Tue, Feb 05, 2019 at 11:47:24AM -0500, Mimi Zohar wrote:
> > > Hi Seth,
> > >
> > > On Tue, 2019-02-05 at 09:18 -0600, Seth Forshee wrote:
> > > > On Thu, Jan 31, 2019 at 02:18:59PM -0500, Mimi Zohar wrote:
> > > > > Require signed kernel modules on systems with secure boot mode enabled.
> > > > >
> > > > > To coordinate between appended kernel module signatures and IMA
> > > > > signatures, only define an IMA MODULE_CHECK policy rule if
> > > > > CONFIG_MODULE_SIG is not enabled.
> > > > >
> > > > > This patch defines a function named set_module_sig_required() and renames
> > > > > is_module_sig_enforced() to is_module_sig_enforced_or_required(). The
> > > > > call to set_module_sig_required() is dependent on CONFIG_IMA_ARCH_POLICY
> > > > > being enabled.
> > > > >
> > > > > Signed-off-by: Mimi Zohar <[email protected]>
> > > >
> > > > With respect to interactions with the kernel lockdown patches, this
> > > > looks better than the patches I saw previously. I don't feel like I know
> > > > enough about what's going on with IMA to ack the patch, but I feel
> > > > confident that it's at least not going to break signature enforcement
> > > > for us.
> > >
> > > Thank you for testing! Could this be translated into a "tested-by"
> > > "(for w/lockdown patches)"?
> >
> > Yeah, that's fine. To be clear about what I tested, I've confirmed that
> > it doesn't interfere with requiring signed modules under lockdown with
> > CONFIG_IMA_ARCH_POLICY=n and IMA appraisal enabled.
> >
> > Tested-by: Seth Forshee <[email protected]>
>
> Oh! You've disabled the coordination of the two signature
> verification methods. Any chance you could test with
> "CONFIG_IMA_ARCH_POLICY" enabled?
Ok, I've tested this now and it also seems to be working. However it
does seem redundant to have CONFIG_IMA_ARCH_POLICY alongside lockdown,
as it doesn't enforce anything not already being enforced by lockdown.
Seth
[Cc'ing Bruno E. O. Meneguele]
On Fri, 2019-02-08 at 13:21 -0600, Seth Forshee wrote:
> On Tue, Feb 05, 2019 at 01:52:21PM -0500, Mimi Zohar wrote:
> > On Tue, 2019-02-05 at 12:32 -0600, Seth Forshee wrote:
> > > On Tue, Feb 05, 2019 at 11:47:24AM -0500, Mimi Zohar wrote:
> > > > Hi Seth,
> > > >
> > > > On Tue, 2019-02-05 at 09:18 -0600, Seth Forshee wrote:
> > > > > On Thu, Jan 31, 2019 at 02:18:59PM -0500, Mimi Zohar wrote:
> > > > > > Require signed kernel modules on systems with secure boot mode enabled.
> > > > > >
> > > > > > To coordinate between appended kernel module signatures and IMA
> > > > > > signatures, only define an IMA MODULE_CHECK policy rule if
> > > > > > CONFIG_MODULE_SIG is not enabled.
> > > > > >
> > > > > > This patch defines a function named set_module_sig_required() and renames
> > > > > > is_module_sig_enforced() to is_module_sig_enforced_or_required(). The
> > > > > > call to set_module_sig_required() is dependent on CONFIG_IMA_ARCH_POLICY
> > > > > > being enabled.
> > > > > >
> > > > > > Signed-off-by: Mimi Zohar <[email protected]>
> > > > >
> > > > > With respect to interactions with the kernel lockdown patches, this
> > > > > looks better than the patches I saw previously. I don't feel like I know
> > > > > enough about what's going on with IMA to ack the patch, but I feel
> > > > > confident that it's at least not going to break signature enforcement
> > > > > for us.
> > > >
> > > > Thank you for testing! Could this be translated into a "tested-by"
> > > > "(for w/lockdown patches)"?
> > >
> > > Yeah, that's fine. To be clear about what I tested, I've confirmed that
> > > it doesn't interfere with requiring signed modules under lockdown with
> > > CONFIG_IMA_ARCH_POLICY=n and IMA appraisal enabled.
> > >
> > > Tested-by: Seth Forshee <[email protected]>
> >
> > Oh! You've disabled the coordination of the two signature
> > verification methods. Any chance you could test with
> > "CONFIG_IMA_ARCH_POLICY" enabled?
>
> Ok, I've tested this now and it also seems to be working. However it
> does seem redundant to have CONFIG_IMA_ARCH_POLICY alongside lockdown,
> as it doesn't enforce anything not already being enforced by lockdown.
Ok. Based on Luis' and your comments, I'll defer this discussion to
after IMA appended signature support is upstreamed. At that point,
for the finit_module syscall, IMA-appraisal at least won't fail the
signature verification. The same appended signature will be verified
not once, but twice - once on the LSM security_kernel_read_file() hook
and then again by module_sig_check().
For the init_module() syscall, the only coordination needed will be
updating is_module_sig_enforced(), based on either the "lockdown" or
some other flag.
Mimi
+++ Mimi Zohar [31/01/19 14:18 -0500]:
>Require signed kernel modules on systems with secure boot mode enabled.
>
>To coordinate between appended kernel module signatures and IMA
>signatures, only define an IMA MODULE_CHECK policy rule if
>CONFIG_MODULE_SIG is not enabled.
>
>This patch defines a function named set_module_sig_required() and renames
>is_module_sig_enforced() to is_module_sig_enforced_or_required(). The
>call to set_module_sig_required() is dependent on CONFIG_IMA_ARCH_POLICY
>being enabled.
>
>Signed-off-by: Mimi Zohar <[email protected]>
>---
> arch/x86/kernel/ima_arch.c | 9 ++++++++-
> include/linux/module.h | 7 ++++++-
> kernel/module.c | 15 +++++++++++----
> security/integrity/ima/ima_main.c | 2 +-
> 4 files changed, 26 insertions(+), 7 deletions(-)
>
>diff --git a/arch/x86/kernel/ima_arch.c b/arch/x86/kernel/ima_arch.c
>index e47cd9390ab4..96a023238a83 100644
>--- a/arch/x86/kernel/ima_arch.c
>+++ b/arch/x86/kernel/ima_arch.c
>@@ -64,12 +64,19 @@ static const char * const sb_arch_rules[] = {
> "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig",
> #endif /* CONFIG_KEXEC_VERIFY_SIG */
> "measure func=KEXEC_KERNEL_CHECK",
>+#if !IS_ENABLED(CONFIG_MODULE_SIG)
>+ "appraise func=MODULE_CHECK appraise_type=imasig",
>+#endif
>+ "measure func=MODULE_CHECK",
> NULL
> };
>
> const char * const *arch_get_ima_policy(void)
> {
>- if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot())
>+ if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
>+ if (IS_ENABLED(CONFIG_MODULE_SIG))
>+ set_module_sig_required();
> return sb_arch_rules;
>+ }
> return NULL;
> }
>diff --git a/include/linux/module.h b/include/linux/module.h
>index 8fa38d3e7538..af51c8ec755f 100644
>--- a/include/linux/module.h
>+++ b/include/linux/module.h
>@@ -659,7 +659,8 @@ static inline bool is_livepatch_module(struct module *mod)
> }
> #endif /* CONFIG_LIVEPATCH */
>
>-bool is_module_sig_enforced(void);
>+bool is_module_sig_enforced_or_required(void);
>+void set_module_sig_required(void);
>
> #else /* !CONFIG_MODULES... */
>
>@@ -780,6 +781,10 @@ static inline bool is_module_sig_enforced(void)
> return false;
> }
>
>+static inline void set_module_sig_required(void)
>+{
>+}
>+
> /* Dereference module function descriptor */
> static inline
> void *dereference_module_function_descriptor(struct module *mod, void *ptr)
>diff --git a/kernel/module.c b/kernel/module.c
>index 2ad1b5239910..70a9709d19eb 100644
>--- a/kernel/module.c
>+++ b/kernel/module.c
>@@ -275,16 +275,23 @@ static void module_assert_mutex_or_preempt(void)
>
> static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE);
> module_param(sig_enforce, bool_enable_only, 0644);
>+static bool sig_required;
>
> /*
> * Export sig_enforce kernel cmdline parameter to allow other subsystems rely
> * on that instead of directly to CONFIG_MODULE_SIG_FORCE config.
> */
>-bool is_module_sig_enforced(void)
>+bool is_module_sig_enforced_or_required(void)
> {
>- return sig_enforce;
>+ return sig_enforce || sig_required;
> }
Hi Mimi,
Just wondering, is there any particular reason why a distinction is
made between sig_enforce and sig_required? Doesn't sig_enforce imply
that signed modules are required? In other words, why introduce
another variable instead of just using sig_enforce? It may be
confusing in the case of a user looking at /sys/module/module/parameters/sig_enforce
and it having a value of 0 yet module signatures are being required by ima.
Thanks,
Jessica
>-EXPORT_SYMBOL(is_module_sig_enforced);
>+EXPORT_SYMBOL(is_module_sig_enforced_or_required);
>+
>+void set_module_sig_required(void)
>+{
>+ sig_required = true;
>+}
>+EXPORT_SYMBOL(set_module_sig_required);
>
> /* Block module loading/unloading? */
> int modules_disabled = 0;
>@@ -2789,7 +2796,7 @@ static int module_sig_check(struct load_info *info, int flags)
> }
>
> /* Not having a signature is only an error if we're strict. */
>- if (err == -ENOKEY && !is_module_sig_enforced())
>+ if (err == -ENOKEY && !is_module_sig_enforced_or_required())
> err = 0;
>
> return err;
>diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
>index 357edd140c09..bbaf87f688be 100644
>--- a/security/integrity/ima/ima_main.c
>+++ b/security/integrity/ima/ima_main.c
>@@ -563,7 +563,7 @@ int ima_load_data(enum kernel_load_data_id id)
> }
> break;
> case LOADING_MODULE:
>- sig_enforce = is_module_sig_enforced();
>+ sig_enforce = is_module_sig_enforced_or_required();
>
> if (ima_enforce && (!sig_enforce
> && (ima_appraise & IMA_APPRAISE_MODULES))) {
>--
>2.7.5
>
On Mon, 2019-02-11 at 16:56 +0100, Jessica Yu wrote:
> +++ Mimi Zohar [31/01/19 14:18 -0500]:
> >Require signed kernel modules on systems with secure boot mode enabled.
> >
> >To coordinate between appended kernel module signatures and IMA
> >signatures, only define an IMA MODULE_CHECK policy rule if
> >CONFIG_MODULE_SIG is not enabled.
> >
> >This patch defines a function named set_module_sig_required() and renames
> >is_module_sig_enforced() to is_module_sig_enforced_or_required(). The
> >call to set_module_sig_required() is dependent on CONFIG_IMA_ARCH_POLICY
> >being enabled.
> >
> >Signed-off-by: Mimi Zohar <[email protected]>
> >---
> > arch/x86/kernel/ima_arch.c | 9 ++++++++-
> > include/linux/module.h | 7 ++++++-
> > kernel/module.c | 15 +++++++++++----
> > security/integrity/ima/ima_main.c | 2 +-
> > 4 files changed, 26 insertions(+), 7 deletions(-)
> >
> >diff --git a/arch/x86/kernel/ima_arch.c b/arch/x86/kernel/ima_arch.c
> >index e47cd9390ab4..96a023238a83 100644
> >--- a/arch/x86/kernel/ima_arch.c
> >+++ b/arch/x86/kernel/ima_arch.c
> >@@ -64,12 +64,19 @@ static const char * const sb_arch_rules[] = {
> > "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig",
> > #endif /* CONFIG_KEXEC_VERIFY_SIG */
> > "measure func=KEXEC_KERNEL_CHECK",
> >+#if !IS_ENABLED(CONFIG_MODULE_SIG)
> >+ "appraise func=MODULE_CHECK appraise_type=imasig",
> >+#endif
> >+ "measure func=MODULE_CHECK",
> > NULL
> > };
> >
> > const char * const *arch_get_ima_policy(void)
> > {
> >- if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot())
> >+ if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
> >+ if (IS_ENABLED(CONFIG_MODULE_SIG))
> >+ set_module_sig_required();
> > return sb_arch_rules;
> >+ }
> > return NULL;
> > }
> >diff --git a/include/linux/module.h b/include/linux/module.h
> >index 8fa38d3e7538..af51c8ec755f 100644
> >--- a/include/linux/module.h
> >+++ b/include/linux/module.h
> >@@ -659,7 +659,8 @@ static inline bool is_livepatch_module(struct module *mod)
> > }
> > #endif /* CONFIG_LIVEPATCH */
> >
> >-bool is_module_sig_enforced(void);
> >+bool is_module_sig_enforced_or_required(void);
> >+void set_module_sig_required(void);
> >
> > #else /* !CONFIG_MODULES... */
> >
> >@@ -780,6 +781,10 @@ static inline bool is_module_sig_enforced(void)
> > return false;
> > }
> >
> >+static inline void set_module_sig_required(void)
> >+{
> >+}
> >+
> > /* Dereference module function descriptor */
> > static inline
> > void *dereference_module_function_descriptor(struct module *mod, void *ptr)
> >diff --git a/kernel/module.c b/kernel/module.c
> >index 2ad1b5239910..70a9709d19eb 100644
> >--- a/kernel/module.c
> >+++ b/kernel/module.c
> >@@ -275,16 +275,23 @@ static void module_assert_mutex_or_preempt(void)
> >
> > static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE);
> > module_param(sig_enforce, bool_enable_only, 0644);
> >+static bool sig_required;
> >
> > /*
> > * Export sig_enforce kernel cmdline parameter to allow other subsystems rely
> > * on that instead of directly to CONFIG_MODULE_SIG_FORCE config.
> > */
> >-bool is_module_sig_enforced(void)
> >+bool is_module_sig_enforced_or_required(void)
> > {
> >- return sig_enforce;
> >+ return sig_enforce || sig_required;
> > }
>
> Hi Mimi,
>
> Just wondering, is there any particular reason why a distinction is
> made between sig_enforce and sig_required? Doesn't sig_enforce imply
> that signed modules are required? In other words, why introduce
> another variable instead of just using sig_enforce? It may be
> confusing in the case of a user looking at /sys/module/module/parameters/sig_enforce
> and it having a value of 0 yet module signatures are being required by ima.
Hi Jessica,
It would definitely be a lot better not having to differentiate
between the builtin CONFIG/module parm enforced and runtime enforced.
For some reason the "lockdown" patch doesn't directly modify
sig_enforce.
Mimi
>
> >-EXPORT_SYMBOL(is_module_sig_enforced);
> >+EXPORT_SYMBOL(is_module_sig_enforced_or_required);
> >+
> >+void set_module_sig_required(void)
> >+{
> >+ sig_required = true;
> >+}
> >+EXPORT_SYMBOL(set_module_sig_required);
> >
> > /* Block module loading/unloading? */
> > int modules_disabled = 0;
> >@@ -2789,7 +2796,7 @@ static int module_sig_check(struct load_info *info, int flags)
> > }
> >
> > /* Not having a signature is only an error if we're strict. */
> >- if (err == -ENOKEY && !is_module_sig_enforced())
> >+ if (err == -ENOKEY && !is_module_sig_enforced_or_required())
> > err = 0;
> >
> > return err;
> >diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> >index 357edd140c09..bbaf87f688be 100644
> >--- a/security/integrity/ima/ima_main.c
> >+++ b/security/integrity/ima/ima_main.c
> >@@ -563,7 +563,7 @@ int ima_load_data(enum kernel_load_data_id id)
> > }
> > break;
> > case LOADING_MODULE:
> >- sig_enforce = is_module_sig_enforced();
> >+ sig_enforce = is_module_sig_enforced_or_required();
> >
> > if (ima_enforce && (!sig_enforce
> > && (ima_appraise & IMA_APPRAISE_MODULES))) {
> >--
> >2.7.5
> >
>