linux-kernel - Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

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]

Date:   Tue, 20 Feb 2018 23:19:01 +0000
From:   Andy Lutomirski <luto@...nel.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Joe Konno <joe.konno@...ux.intel.com>,
        linux-efi <linux-efi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        matthew.garrett@...ula.com, Jeremy Kerr <jk@...abs.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Tony Luck <tony.luck@...el.com>
Subject: Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 7:18 PM, Andy Lutomirski <luto@...nel.org> wrote:
> On 02/15/2018 10:22 AM, Joe Konno wrote:
>>
>> From: Joe Konno <joe.konno@...el.com>
>>
>> Efivarfs nodes are created with group and world readable permissions.
>> Reading certain EFI variables trigger SMIs. So, this is a potential DoS
>> surface.
>>
>> Make permissions more restrictive-- only the owner may read or write to
>> created inodes.
>>
>> Suggested-by: Andi Kleen <ak@...ux.intel.com>
>> Reported-by: Tony Luck <tony.luck@...el.com>
>> Cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>
>> Cc: Matthew Garrett <matthew.garrett@...ula.com>
>> Cc: Jeremy Kerr <jk@...abs.org>
>> Cc: linux-efi@...r.kernel.org
>> Cc: stable@...r.kernel.org
>> Signed-off-by: Joe Konno <joe.konno@...el.com>
>
>
> The discussion in this thread has gone on too long, so:
>
> Acked-by: Andy Lutomirski <luto@...nel.org>
>
> And yes, this patch will break a couple of minor usecases, but IMO those
> usecases deserve to break.

Alternatively, a patch like this (untested but straightforward) might
be a little more effective and easier to undo in userspace for anyone
who may be adversely affected:

diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
index 5b68e4294faa..88c7163c0ac1 100644
--- a/fs/efivarfs/super.c
+++ b/fs/efivarfs/super.c
@@ -207,7 +207,7 @@ static int efivarfs_fill_super(struct super_block
*sb, void *data, int silent)
        sb->s_d_op              = &efivarfs_d_ops;
        sb->s_time_gran         = 1;

-       inode = efivarfs_get_inode(sb, NULL, S_IFDIR | 0755, 0, true);
+       inode = efivarfs_get_inode(sb, NULL, S_IFDIR | 0700, 0, true);
        if (!inode)
                return -ENOMEM;
        inode->i_op = &efivarfs_dir_inode_operations;

If you prefer that, I'd be happy to re-send it for real.

--Andy