Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[joeyli]

On Fri, May 26, 2017 at 01:43:12PM +0100, David Howells wrote:
> Casey Schaufler  wrote:
> 
> > You called out five distinct features in 0/5, so how about
> > a bit for each of those?
> 
> Actually, there are more than five in that list - there are three in the first
> item - and I'm not sure the remaining categories are quite as well defined as
> I made it seem.
>

Do we have a public place (e.g. wiki page) to put the list of lock-down
functions?

Thanks a lot!
Joey Lee 

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[joeyli]

On Fri, May 26, 2017 at 01:43:12PM +0100, David Howells wrote:
> Casey Schaufler  wrote:
> 
> > You called out five distinct features in 0/5, so how about
> > a bit for each of those?
> 
> Actually, there are more than five in that list - there are three in the first
> item - and I'm not sure the remaining categories are quite as well defined as
> I made it seem.
>

Do we have a public place (e.g. wiki page) to put the list of lock-down
functions?

Thanks a lot!
Joey Lee 

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[David Howells]

Casey Schaufler  wrote:

> You called out five distinct features in 0/5, so how about
> a bit for each of those?

Actually, there are more than five in that list - there are three in the first
item - and I'm not sure the remaining categories are quite as well defined as
I made it seem.

Also, that sort of categorisation might not be what we actually need: it might
end up coming down to a no-write vs no-read-or-write split instead.

> Actually, I don't care which way you go. The current code works
> for me. I am just concerned that the granularity fiends might come
> around later.

In that case, I'll leave it as is for the moment.  It doesn't introduce so
many calls that they're impossible to change.

David

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[David Howells]

Casey Schaufler  wrote:

> You called out five distinct features in 0/5, so how about
> a bit for each of those?

Actually, there are more than five in that list - there are three in the first
item - and I'm not sure the remaining categories are quite as well defined as
I made it seem.

Also, that sort of categorisation might not be what we actually need: it might
end up coming down to a no-write vs no-read-or-write split instead.

> Actually, I don't care which way you go. The current code works
> for me. I am just concerned that the granularity fiends might come
> around later.

In that case, I'll leave it as is for the moment.  It doesn't introduce so
many calls that they're impossible to change.

David

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[joeyli]

On Wed, May 24, 2017 at 03:45:45PM +0100, David Howells wrote:
> Provide a single call to allow kernel code to determine whether the system
> should be locked down, thereby disallowing various accesses that might
> allow the running kernel image to be changed including the loading of
> modules that aren't validly signed with a key we recognise, fiddling with
> MSR registers and disallowing hibernation,
> 
> Signed-off-by: David Howells 
> Acked-by: James Morris 

Reviewed-by: Joey Lee 

Regards
Joey Lee

> ---
> 
>  include/linux/kernel.h   |9 +
>  include/linux/security.h |   11 +++
>  security/Kconfig |   15 +++
>  security/Makefile|3 +++
>  security/lock_down.c |   46 
> ++
>  5 files changed, 84 insertions(+)
>  create mode 100644 security/lock_down.c
> 
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 13bc08aba704..282a1684d6e8 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -276,6 +276,15 @@ extern int oops_may_print(void);
>  void do_exit(long error_code) __noreturn;
>  void complete_and_exit(struct completion *, long) __noreturn;
>  
> +#ifdef CONFIG_LOCK_DOWN_KERNEL
> +extern bool kernel_is_locked_down(void);
> +#else
> +static inline bool kernel_is_locked_down(void)
> +{
> + return false;
> +}
> +#endif
> +
>  /* Internal, do not use. */
>  int __must_check _kstrtoul(const char *s, unsigned int base, unsigned long 
> *res);
>  int __must_check _kstrtol(const char *s, unsigned int base, long *res);
> diff --git a/include/linux/security.h b/include/linux/security.h
> index af675b576645..8db2d886aa90 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -1698,5 +1698,16 @@ static inline void free_secdata(void *secdata)
>  { }
>  #endif /* CONFIG_SECURITY */
>  
> +#ifdef CONFIG_LOCK_DOWN_KERNEL
> +extern void __init lock_kernel_down(void);
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +extern void lift_kernel_lockdown(void);
> +#endif
> +#else
> +static inline void lock_kernel_down(void)
> +{
> +}
> +#endif
> +
>  #endif /* ! __LINUX_SECURITY_H */
>  
> diff --git a/security/Kconfig b/security/Kconfig
> index 93027fdf47d1..4baac4aab277 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -189,6 +189,21 @@ config STATIC_USERMODEHELPER_PATH
> If you wish for all usermode helper programs to be disabled,
> specify an empty string here (i.e. "").
>  
> +config LOCK_DOWN_KERNEL
> + bool "Allow the kernel to be 'locked down'"
> + help
> +   Allow the kernel to be locked down under certain circumstances, for
> +   instance if UEFI secure boot is enabled.  Locking down the kernel
> +   turns off various features that might otherwise allow access to the
> +   kernel image (eg. setting MSR registers).
> +
> +config ALLOW_LOCKDOWN_LIFT
> + bool
> + help
> +   Allow the lockdown on a kernel to be lifted, thereby restoring the
> +   ability of userspace to access the kernel image (eg. by SysRq+x under
> +   x86).
> +
>  source security/selinux/Kconfig
>  source security/smack/Kconfig
>  source security/tomoyo/Kconfig
> diff --git a/security/Makefile b/security/Makefile
> index f2d71cdb8e19..8c4a43e3d4e0 100644
> --- a/security/Makefile
> +++ b/security/Makefile
> @@ -29,3 +29,6 @@ obj-$(CONFIG_CGROUP_DEVICE) += device_cgroup.o
>  # Object integrity file lists
>  subdir-$(CONFIG_INTEGRITY)   += integrity
>  obj-$(CONFIG_INTEGRITY)  += integrity/
> +
> +# Allow the kernel to be locked down
> +obj-$(CONFIG_LOCK_DOWN_KERNEL)   += lock_down.o
> diff --git a/security/lock_down.c b/security/lock_down.c
> new file mode 100644
> index ..dd98422fbda7
> --- /dev/null
> +++ b/security/lock_down.c
> @@ -0,0 +1,46 @@
> +/* Lock down the kernel
> + *
> + * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowe...@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +static __read_mostly bool kernel_locked_down;
> +#else
> +static __ro_after_init bool kernel_locked_down;
> +#endif
> +
> +/*
> + * Put the kernel into lock-down mode.
> + */
> +void __init lock_kernel_down(void)
> +{
> + kernel_locked_down = true;
> +}
> +
> +/*
> + * Take the kernel out of lockdown mode.
> + */
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +void lift_kernel_lockdown(void)
> +{
> + kernel_locked_down = false;
> +}
> +#endif
> +
> +/**
> + * kernel_is_locked_down - Find out if the kernel is locked down
> + */
> +bool kernel_is_locked_down(void)
> +{
> +  

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[joeyli]

On Wed, May 24, 2017 at 03:45:45PM +0100, David Howells wrote:
> Provide a single call to allow kernel code to determine whether the system
> should be locked down, thereby disallowing various accesses that might
> allow the running kernel image to be changed including the loading of
> modules that aren't validly signed with a key we recognise, fiddling with
> MSR registers and disallowing hibernation,
> 
> Signed-off-by: David Howells 
> Acked-by: James Morris 

Reviewed-by: Joey Lee 

Regards
Joey Lee

> ---
> 
>  include/linux/kernel.h   |9 +
>  include/linux/security.h |   11 +++
>  security/Kconfig |   15 +++
>  security/Makefile|3 +++
>  security/lock_down.c |   46 
> ++
>  5 files changed, 84 insertions(+)
>  create mode 100644 security/lock_down.c
> 
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 13bc08aba704..282a1684d6e8 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -276,6 +276,15 @@ extern int oops_may_print(void);
>  void do_exit(long error_code) __noreturn;
>  void complete_and_exit(struct completion *, long) __noreturn;
>  
> +#ifdef CONFIG_LOCK_DOWN_KERNEL
> +extern bool kernel_is_locked_down(void);
> +#else
> +static inline bool kernel_is_locked_down(void)
> +{
> + return false;
> +}
> +#endif
> +
>  /* Internal, do not use. */
>  int __must_check _kstrtoul(const char *s, unsigned int base, unsigned long 
> *res);
>  int __must_check _kstrtol(const char *s, unsigned int base, long *res);
> diff --git a/include/linux/security.h b/include/linux/security.h
> index af675b576645..8db2d886aa90 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -1698,5 +1698,16 @@ static inline void free_secdata(void *secdata)
>  { }
>  #endif /* CONFIG_SECURITY */
>  
> +#ifdef CONFIG_LOCK_DOWN_KERNEL
> +extern void __init lock_kernel_down(void);
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +extern void lift_kernel_lockdown(void);
> +#endif
> +#else
> +static inline void lock_kernel_down(void)
> +{
> +}
> +#endif
> +
>  #endif /* ! __LINUX_SECURITY_H */
>  
> diff --git a/security/Kconfig b/security/Kconfig
> index 93027fdf47d1..4baac4aab277 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -189,6 +189,21 @@ config STATIC_USERMODEHELPER_PATH
> If you wish for all usermode helper programs to be disabled,
> specify an empty string here (i.e. "").
>  
> +config LOCK_DOWN_KERNEL
> + bool "Allow the kernel to be 'locked down'"
> + help
> +   Allow the kernel to be locked down under certain circumstances, for
> +   instance if UEFI secure boot is enabled.  Locking down the kernel
> +   turns off various features that might otherwise allow access to the
> +   kernel image (eg. setting MSR registers).
> +
> +config ALLOW_LOCKDOWN_LIFT
> + bool
> + help
> +   Allow the lockdown on a kernel to be lifted, thereby restoring the
> +   ability of userspace to access the kernel image (eg. by SysRq+x under
> +   x86).
> +
>  source security/selinux/Kconfig
>  source security/smack/Kconfig
>  source security/tomoyo/Kconfig
> diff --git a/security/Makefile b/security/Makefile
> index f2d71cdb8e19..8c4a43e3d4e0 100644
> --- a/security/Makefile
> +++ b/security/Makefile
> @@ -29,3 +29,6 @@ obj-$(CONFIG_CGROUP_DEVICE) += device_cgroup.o
>  # Object integrity file lists
>  subdir-$(CONFIG_INTEGRITY)   += integrity
>  obj-$(CONFIG_INTEGRITY)  += integrity/
> +
> +# Allow the kernel to be locked down
> +obj-$(CONFIG_LOCK_DOWN_KERNEL)   += lock_down.o
> diff --git a/security/lock_down.c b/security/lock_down.c
> new file mode 100644
> index ..dd98422fbda7
> --- /dev/null
> +++ b/security/lock_down.c
> @@ -0,0 +1,46 @@
> +/* Lock down the kernel
> + *
> + * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowe...@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +static __read_mostly bool kernel_locked_down;
> +#else
> +static __ro_after_init bool kernel_locked_down;
> +#endif
> +
> +/*
> + * Put the kernel into lock-down mode.
> + */
> +void __init lock_kernel_down(void)
> +{
> + kernel_locked_down = true;
> +}
> +
> +/*
> + * Take the kernel out of lockdown mode.
> + */
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +void lift_kernel_lockdown(void)
> +{
> + kernel_locked_down = false;
> +}
> +#endif
> +
> +/**
> + * kernel_is_locked_down - Find out if the kernel is locked down
> + */
> +bool kernel_is_locked_down(void)
> +{
> + return kernel_locked_down;
> +}
> 

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[Casey Schaufler]

On 5/24/2017 11:53 PM, David Howells wrote:
> Casey Schaufler  wrote:
>
>>> +#ifdef CONFIG_LOCK_DOWN_KERNEL
>>> +extern bool kernel_is_locked_down(void);
>>> +#else
>>> +static inline bool kernel_is_locked_down(void)
>> Should this be a bool or an int? I can imagine that someone is going to want
>> various different degrees of lock down for kernels. As an int you could
>> return a bitmap indicating which features were locked. This would allow
>> additional things to be locked down without changing the interface.
> At the moment it makes no difference, since the return value is only ever
> passed directly to an if-statement.
>
> Also, do you have an idea as to how is should be divided up?

You called out five distinct features in 0/5, so how about
a bit for each of those?

Actually, I don't care which way you go. The current code works
for me. I am just concerned that the granularity fiends might come
around later.


>
> There aren't so many cases, at least not yet, that they can't be fixed up,
> perhaps with a coccinelle script.
>
> David
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[Casey Schaufler]

On 5/24/2017 11:53 PM, David Howells wrote:
> Casey Schaufler  wrote:
>
>>> +#ifdef CONFIG_LOCK_DOWN_KERNEL
>>> +extern bool kernel_is_locked_down(void);
>>> +#else
>>> +static inline bool kernel_is_locked_down(void)
>> Should this be a bool or an int? I can imagine that someone is going to want
>> various different degrees of lock down for kernels. As an int you could
>> return a bitmap indicating which features were locked. This would allow
>> additional things to be locked down without changing the interface.
> At the moment it makes no difference, since the return value is only ever
> passed directly to an if-statement.
>
> Also, do you have an idea as to how is should be divided up?

You called out five distinct features in 0/5, so how about
a bit for each of those?

Actually, I don't care which way you go. The current code works
for me. I am just concerned that the granularity fiends might come
around later.


>
> There aren't so many cases, at least not yet, that they can't be fixed up,
> perhaps with a coccinelle script.
>
> David
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[David Howells]

Casey Schaufler  wrote:

> > +#ifdef CONFIG_LOCK_DOWN_KERNEL
> > +extern bool kernel_is_locked_down(void);
> > +#else
> > +static inline bool kernel_is_locked_down(void)
> 
> Should this be a bool or an int? I can imagine that someone is going to want
> various different degrees of lock down for kernels. As an int you could
> return a bitmap indicating which features were locked. This would allow
> additional things to be locked down without changing the interface.

At the moment it makes no difference, since the return value is only ever
passed directly to an if-statement.

Also, do you have an idea as to how is should be divided up?

There aren't so many cases, at least not yet, that they can't be fixed up,
perhaps with a coccinelle script.

David

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[David Howells]

Casey Schaufler  wrote:

> > +#ifdef CONFIG_LOCK_DOWN_KERNEL
> > +extern bool kernel_is_locked_down(void);
> > +#else
> > +static inline bool kernel_is_locked_down(void)
> 
> Should this be a bool or an int? I can imagine that someone is going to want
> various different degrees of lock down for kernels. As an int you could
> return a bitmap indicating which features were locked. This would allow
> additional things to be locked down without changing the interface.

At the moment it makes no difference, since the return value is only ever
passed directly to an if-statement.

Also, do you have an idea as to how is should be divided up?

There aren't so many cases, at least not yet, that they can't be fixed up,
perhaps with a coccinelle script.

David

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[Casey Schaufler]

On 5/24/2017 7:45 AM, David Howells wrote:
> Provide a single call to allow kernel code to determine whether the system
> should be locked down, thereby disallowing various accesses that might
> allow the running kernel image to be changed including the loading of
> modules that aren't validly signed with a key we recognise, fiddling with
> MSR registers and disallowing hibernation,
>
> Signed-off-by: David Howells 
> Acked-by: James Morris 
> ---
>
>  include/linux/kernel.h   |9 +
>  include/linux/security.h |   11 +++
>  security/Kconfig |   15 +++
>  security/Makefile|3 +++
>  security/lock_down.c |   46 
> ++
>  5 files changed, 84 insertions(+)
>  create mode 100644 security/lock_down.c
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 13bc08aba704..282a1684d6e8 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -276,6 +276,15 @@ extern int oops_may_print(void);
>  void do_exit(long error_code) __noreturn;
>  void complete_and_exit(struct completion *, long) __noreturn;
>  
> +#ifdef CONFIG_LOCK_DOWN_KERNEL
> +extern bool kernel_is_locked_down(void);
> +#else
> +static inline bool kernel_is_locked_down(void)

Should this be a bool or an int? I can imagine that
someone is going to want various different degrees
of lock down for kernels. As an int you could return
a bitmap indicating which features were locked. This
would allow additional things to be locked down
without changing the interface.

> +{
> + return false;
> +}
> +#endif
> +
>  /* Internal, do not use. */
>  int __must_check _kstrtoul(const char *s, unsigned int base, unsigned long 
> *res);
>  int __must_check _kstrtol(const char *s, unsigned int base, long *res);
> diff --git a/include/linux/security.h b/include/linux/security.h
> index af675b576645..8db2d886aa90 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -1698,5 +1698,16 @@ static inline void free_secdata(void *secdata)
>  { }
>  #endif /* CONFIG_SECURITY */
>  
> +#ifdef CONFIG_LOCK_DOWN_KERNEL
> +extern void __init lock_kernel_down(void);
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +extern void lift_kernel_lockdown(void);
> +#endif
> +#else
> +static inline void lock_kernel_down(void)
> +{
> +}
> +#endif
> +
>  #endif /* ! __LINUX_SECURITY_H */
>  
> diff --git a/security/Kconfig b/security/Kconfig
> index 93027fdf47d1..4baac4aab277 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -189,6 +189,21 @@ config STATIC_USERMODEHELPER_PATH
> If you wish for all usermode helper programs to be disabled,
> specify an empty string here (i.e. "").
>  
> +config LOCK_DOWN_KERNEL
> + bool "Allow the kernel to be 'locked down'"
> + help
> +   Allow the kernel to be locked down under certain circumstances, for
> +   instance if UEFI secure boot is enabled.  Locking down the kernel
> +   turns off various features that might otherwise allow access to the
> +   kernel image (eg. setting MSR registers).
> +
> +config ALLOW_LOCKDOWN_LIFT
> + bool
> + help
> +   Allow the lockdown on a kernel to be lifted, thereby restoring the
> +   ability of userspace to access the kernel image (eg. by SysRq+x under
> +   x86).
> +
>  source security/selinux/Kconfig
>  source security/smack/Kconfig
>  source security/tomoyo/Kconfig
> diff --git a/security/Makefile b/security/Makefile
> index f2d71cdb8e19..8c4a43e3d4e0 100644
> --- a/security/Makefile
> +++ b/security/Makefile
> @@ -29,3 +29,6 @@ obj-$(CONFIG_CGROUP_DEVICE) += device_cgroup.o
>  # Object integrity file lists
>  subdir-$(CONFIG_INTEGRITY)   += integrity
>  obj-$(CONFIG_INTEGRITY)  += integrity/
> +
> +# Allow the kernel to be locked down
> +obj-$(CONFIG_LOCK_DOWN_KERNEL)   += lock_down.o
> diff --git a/security/lock_down.c b/security/lock_down.c
> new file mode 100644
> index ..dd98422fbda7
> --- /dev/null
> +++ b/security/lock_down.c
> @@ -0,0 +1,46 @@
> +/* Lock down the kernel
> + *
> + * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowe...@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +static __read_mostly bool kernel_locked_down;
> +#else
> +static __ro_after_init bool kernel_locked_down;
> +#endif
> +
> +/*
> + * Put the kernel into lock-down mode.
> + */
> +void __init lock_kernel_down(void)
> +{
> + kernel_locked_down = true;
> +}
> +
> +/*
> + * Take the kernel out of lockdown mode.
> + */
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +void 

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[Casey Schaufler]

On 5/24/2017 7:45 AM, David Howells wrote:
> Provide a single call to allow kernel code to determine whether the system
> should be locked down, thereby disallowing various accesses that might
> allow the running kernel image to be changed including the loading of
> modules that aren't validly signed with a key we recognise, fiddling with
> MSR registers and disallowing hibernation,
>
> Signed-off-by: David Howells 
> Acked-by: James Morris 
> ---
>
>  include/linux/kernel.h   |9 +
>  include/linux/security.h |   11 +++
>  security/Kconfig |   15 +++
>  security/Makefile|3 +++
>  security/lock_down.c |   46 
> ++
>  5 files changed, 84 insertions(+)
>  create mode 100644 security/lock_down.c
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 13bc08aba704..282a1684d6e8 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -276,6 +276,15 @@ extern int oops_may_print(void);
>  void do_exit(long error_code) __noreturn;
>  void complete_and_exit(struct completion *, long) __noreturn;
>  
> +#ifdef CONFIG_LOCK_DOWN_KERNEL
> +extern bool kernel_is_locked_down(void);
> +#else
> +static inline bool kernel_is_locked_down(void)

Should this be a bool or an int? I can imagine that
someone is going to want various different degrees
of lock down for kernels. As an int you could return
a bitmap indicating which features were locked. This
would allow additional things to be locked down
without changing the interface.

> +{
> + return false;
> +}
> +#endif
> +
>  /* Internal, do not use. */
>  int __must_check _kstrtoul(const char *s, unsigned int base, unsigned long 
> *res);
>  int __must_check _kstrtol(const char *s, unsigned int base, long *res);
> diff --git a/include/linux/security.h b/include/linux/security.h
> index af675b576645..8db2d886aa90 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -1698,5 +1698,16 @@ static inline void free_secdata(void *secdata)
>  { }
>  #endif /* CONFIG_SECURITY */
>  
> +#ifdef CONFIG_LOCK_DOWN_KERNEL
> +extern void __init lock_kernel_down(void);
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +extern void lift_kernel_lockdown(void);
> +#endif
> +#else
> +static inline void lock_kernel_down(void)
> +{
> +}
> +#endif
> +
>  #endif /* ! __LINUX_SECURITY_H */
>  
> diff --git a/security/Kconfig b/security/Kconfig
> index 93027fdf47d1..4baac4aab277 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -189,6 +189,21 @@ config STATIC_USERMODEHELPER_PATH
> If you wish for all usermode helper programs to be disabled,
> specify an empty string here (i.e. "").
>  
> +config LOCK_DOWN_KERNEL
> + bool "Allow the kernel to be 'locked down'"
> + help
> +   Allow the kernel to be locked down under certain circumstances, for
> +   instance if UEFI secure boot is enabled.  Locking down the kernel
> +   turns off various features that might otherwise allow access to the
> +   kernel image (eg. setting MSR registers).
> +
> +config ALLOW_LOCKDOWN_LIFT
> + bool
> + help
> +   Allow the lockdown on a kernel to be lifted, thereby restoring the
> +   ability of userspace to access the kernel image (eg. by SysRq+x under
> +   x86).
> +
>  source security/selinux/Kconfig
>  source security/smack/Kconfig
>  source security/tomoyo/Kconfig
> diff --git a/security/Makefile b/security/Makefile
> index f2d71cdb8e19..8c4a43e3d4e0 100644
> --- a/security/Makefile
> +++ b/security/Makefile
> @@ -29,3 +29,6 @@ obj-$(CONFIG_CGROUP_DEVICE) += device_cgroup.o
>  # Object integrity file lists
>  subdir-$(CONFIG_INTEGRITY)   += integrity
>  obj-$(CONFIG_INTEGRITY)  += integrity/
> +
> +# Allow the kernel to be locked down
> +obj-$(CONFIG_LOCK_DOWN_KERNEL)   += lock_down.o
> diff --git a/security/lock_down.c b/security/lock_down.c
> new file mode 100644
> index ..dd98422fbda7
> --- /dev/null
> +++ b/security/lock_down.c
> @@ -0,0 +1,46 @@
> +/* Lock down the kernel
> + *
> + * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowe...@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +static __read_mostly bool kernel_locked_down;
> +#else
> +static __ro_after_init bool kernel_locked_down;
> +#endif
> +
> +/*
> + * Put the kernel into lock-down mode.
> + */
> +void __init lock_kernel_down(void)
> +{
> + kernel_locked_down = true;
> +}
> +
> +/*
> + * Take the kernel out of lockdown mode.
> + */
> +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
> +void lift_kernel_lockdown(void)
> +{
> + 

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[James Morris]

On Thu, 6 Apr 2017, David Howells wrote:

> Provide a single call to allow kernel code to determine whether the system
> should be locked down, thereby disallowing various accesses that might
> allow the running kernel image to be changed including the loading of
> modules that aren't validly signed with a key we recognise, fiddling with
> MSR registers and disallowing hibernation,
> 
> Signed-off-by: David Howells 

Acked-by: James Morris 

-- 
James Morris

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

[James Morris]

On Thu, 6 Apr 2017, David Howells wrote:

> Provide a single call to allow kernel code to determine whether the system
> should be locked down, thereby disallowing various accesses that might
> allow the running kernel image to be changed including the loading of
> modules that aren't validly signed with a key we recognise, fiddling with
> MSR registers and disallowing hibernation,
> 
> Signed-off-by: David Howells 

Acked-by: James Morris 

-- 
James Morris