linux-kernel - Re: [PATCH v2 2/2] firmware_class: perform new LSM checks

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

Message-ID: <CACVXFVO8=naiMG-S41_KRmbyOKLBna2=t5nafmYWGar5fSt3sQ@mail.gmail.com>
Date:	Tue, 22 Jul 2014 10:19:52 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Kees Cook <keescook@...omium.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	James Morris <james.l.morris@...cle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-security-module <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] firmware_class: perform new LSM checks

On Tue, Jul 22, 2014 at 3:06 AM, Kees Cook <keescook@...omium.org> wrote:
> This attaches LSM hooks to the existing firmware loading interfaces:
> filesystem-found firmware and demand-loaded blobs.
>
> Signed-off-by: Kees Cook <keescook@...omium.org>
> Acked-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> ---
>  drivers/base/firmware_class.c |   16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index d276e33880be..7399bab71ced 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -28,6 +28,7 @@
>  #include <linux/suspend.h>
>  #include <linux/syscore_ops.h>
>  #include <linux/reboot.h>
> +#include <linux/security.h>
>
>  #include <generated/utsrelease.h>
>
> @@ -308,12 +309,17 @@ static int fw_read_file_contents(struct file *file, struct firmware_buf *fw_buf)
>         if (rc != size) {
>                 if (rc > 0)
>                         rc = -EIO;
> -               vfree(buf);
> -               return rc;
> +               goto fail;
>         }
> +       rc = security_kernel_fw_from_file(file, buf, size);
> +       if (rc)
> +               goto fail;
>         fw_buf->data = buf;
>         fw_buf->size = size;
>         return 0;
> +fail:
> +       vfree(buf);
> +       return rc;
>  }
>
>  static int fw_get_filesystem_firmware(struct device *device,
> @@ -640,6 +646,12 @@ static ssize_t firmware_loading_store(struct device *dev,
>                 break;
>         case 0:
>                 if (test_bit(FW_STATUS_LOADING, &fw_buf->status)) {
> +                       if (security_kernel_fw_from_file(NULL, fw_buf->data,
> +                                                        fw_buf->size)) {
> +                               fw_load_abort(fw_priv);
> +                               break;

It may be more friendly to return -EPERM or sort of failure
to user, otherwise it might cause userspace loader a bit confused.


Thanks,
--
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/