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]

Message-ID: <20180220213246.43y2vbiiikqyx2ys@agluck-desk>
Date:   Tue, 20 Feb 2018 13:32:47 -0800
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Matthew Garrett <mjg59@...gle.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        joe.konno@...ux.intel.com, linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        matthew.garrett@...ula.com, Jeremy Kerr <jk@...abs.org>,
        ak@...ux.intel.com, pjones@...hat.com, luto@...nel.org,
        James Bottomley <james.bottomley@...senpartnership.com>
Subject: Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 09:22:29PM +0000, Matthew Garrett wrote:
> On Tue, Feb 20, 2018 at 1:18 PM Luck, Tony <tony.luck@...el.com> wrote:
> 
> > Does this rate an exception to the "don't break userspace" for a security
> issue?
> 
> To be clear, when you say "security" is this in reference to it being a
> denial of service, or are you worried about other interactions that may
> cause wider security issues?

The immediate problem is the denial of service attack.  I have
a nagging worry that allowing a user to cause an SMI at a precise
time might also be a problem. But I don't know how that could be
leveraged in some other attack.

Making the efivar files 0600 would stop the user from causing the
SMIs. The rate limit solution could include a random delay to make
it tricky to use any attack that relies on an SMI during some specific
code sequence.

-Tony