Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

[David Howells]

Ethan Zhao  wrote:

> May I ask a question here -- Is it intentionally enabling the
> read-only mode, so userspace
> tools like dmidecode could work with kernel_is_locked_down ?  while it
> was impossible to work
> with the attached patch applied. Is it a security policy change with
> secure boot ?

I removed readability on /dev/mem, /dev/kmem and /proc/kcore so that userspace
can't use this to gain access to cryptographic material in use by the kernel.

Readability was removed on /dev/port because reading from an I/O port register
might have a side effect or might allow you to snoop h/w interactions, such as
keyboard input.

I can provide an additional config option to allow /dev/mem and similar to
remain readable - but it needs to be a temporary affair.

I can also log accesses to these interfaces so that we can find out what
breaks and fix it.

Note that dmidecode doesn't necessarily use /dev/mem:

[root@andromeda ~]# strace -f -eopen dmidecode  >/dev/null
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/sys/firmware/dmi/tables/smbios_entry_point", O_RDONLY) = 3
open("/sys/firmware/dmi/tables/DMI", O_RDONLY) = 3
+++ exited with 0 +++

Indeed, my Fedora 24 test system boots without a /dev/mem file being present
(I'm not sure *why* /dev/mem isn't present, but I hadn't noticed till now).

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

[Ethan Zhao]

David，

May I ask a question here -- Is it intentionally enabling the
read-only mode, so userspace
tools like dmidecode could work with kernel_is_locked_down ?  while it
was impossible to work
with the attached patch applied. Is it a security policy change with
secure boot ?

Thanks,
Ethan

On Mon, Oct 23, 2017 at 10:34 PM, David Howells  wrote:
> I think I should replace this patch with the attached.  This will prevent
> /dev/mem, /dev/kmem and /dev/port from being *opened*, and thereby preventing
> read, write and ioctl.
>
> David
> ---
> commit e68daa2256986932b9a7d6709cf9e24b30d93583
> Author: Matthew Garrett 
> Date:   Wed May 24 14:56:02 2017 +0100
>
> Restrict /dev/{mem,kmem,port} when the kernel is locked down
>
> Allowing users to read and write to core kernel memory makes it possible
> for the kernel to be subverted, avoiding module loading restrictions, and
> also to steal cryptographic information.
>
> Disallow /dev/mem and /dev/kmem from being opened this when the kernel has
> been locked down to prevent this.
>
> Also disallow /dev/port from being opened to prevent raw ioport access and
> thus DMA from being used to accomplish the same thing.
>
> Signed-off-by: Matthew Garrett 
> Signed-off-by: David Howells 
> Reviewed-by: "Lee, Chun-Yi" 
>
> diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> index 593a8818aca9..0ce5ac0a5c6b 100644
> --- a/drivers/char/mem.c
> +++ b/drivers/char/mem.c
> @@ -762,6 +762,8 @@ static loff_t memory_lseek(struct file *file, loff_t 
> offset, int orig)
>
>  static int open_port(struct inode *inode, struct file *filp)
>  {
> +   if (kernel_is_locked_down("/dev/mem,kmem,port"))
> +   return -EPERM;
> return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
>  }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

[David Howells]

I think I should replace this patch with the attached.  This will prevent
/dev/mem, /dev/kmem and /dev/port from being *opened*, and thereby preventing
read, write and ioctl.

David
---
commit e68daa2256986932b9a7d6709cf9e24b30d93583
Author: Matthew Garrett 
Date:   Wed May 24 14:56:02 2017 +0100

Restrict /dev/{mem,kmem,port} when the kernel is locked down

Allowing users to read and write to core kernel memory makes it possible
for the kernel to be subverted, avoiding module loading restrictions, and
also to steal cryptographic information.

Disallow /dev/mem and /dev/kmem from being opened this when the kernel has
been locked down to prevent this.

Also disallow /dev/port from being opened to prevent raw ioport access and
thus DMA from being used to accomplish the same thing.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 593a8818aca9..0ce5ac0a5c6b 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -762,6 +762,8 @@ static loff_t memory_lseek(struct file *file, loff_t 
offset, int orig)
 
 static int open_port(struct inode *inode, struct file *filp)
 {
+   if (kernel_is_locked_down("/dev/mem,kmem,port"))
+   return -EPERM;
return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

[joeyli]

Hi David,

Thanks for you send out this series.

On Thu, Oct 19, 2017 at 03:51:02PM +0100, David Howells wrote:
> From: Matthew Garrett 
> 
> Allowing users to write to address space makes it possible for the kernel to
> be subverted, avoiding module loading restrictions.  Prevent this when the
> kernel has been locked down.
> 
> Signed-off-by: Matthew Garrett 
> Signed-off-by: David Howells 

I have reviewed and tested this patch. Please feel free to add:

Reviewed-by: "Lee, Chun-Yi" 

Thanks a lot!
Joey Lee

> ---
> 
>  drivers/char/mem.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> index 593a8818aca9..b7c36898b689 100644
> --- a/drivers/char/mem.c
> +++ b/drivers/char/mem.c
> @@ -179,6 +179,9 @@ static ssize_t write_mem(struct file *file, const char 
> __user *buf,
>   if (p != *ppos)
>   return -EFBIG;
>  
> + if (kernel_is_locked_down("/dev/mem"))
> + return -EPERM;
> +
>   if (!valid_phys_addr_range(p, count))
>   return -EFAULT;
>  
> @@ -540,6 +543,9 @@ static ssize_t write_kmem(struct file *file, const char 
> __user *buf,
>   char *kbuf; /* k-addr because vwrite() takes vmlist_lock rwlock */
>   int err = 0;
>  
> + if (kernel_is_locked_down("/dev/kmem"))
> + return -EPERM;
> +
>   if (p < (unsigned long) high_memory) {
>   unsigned long to_write = min_t(unsigned long, count,
>  (unsigned long)high_memory - p);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

[David Howells]

From: Matthew Garrett 

Allowing users to write to address space makes it possible for the kernel to
be subverted, avoiding module loading restrictions.  Prevent this when the
kernel has been locked down.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
---

 drivers/char/mem.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 593a8818aca9..b7c36898b689 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -179,6 +179,9 @@ static ssize_t write_mem(struct file *file, const char 
__user *buf,
if (p != *ppos)
return -EFBIG;
 
+   if (kernel_is_locked_down("/dev/mem"))
+   return -EPERM;
+
if (!valid_phys_addr_range(p, count))
return -EFAULT;
 
@@ -540,6 +543,9 @@ static ssize_t write_kmem(struct file *file, const char 
__user *buf,
char *kbuf; /* k-addr because vwrite() takes vmlist_lock rwlock */
int err = 0;
 
+   if (kernel_is_locked_down("/dev/kmem"))
+   return -EPERM;
+
if (p < (unsigned long) high_memory) {
unsigned long to_write = min_t(unsigned long, count,
   (unsigned long)high_memory - p);

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html