linux-kernel - Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

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:   Sun, 9 Apr 2017 14:10:10 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     David Howells <dhowells@...hat.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        matthew.garrett@...ula.com, linux-efi@...r.kernel.org,
        One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        acpi4asus-user <acpi4asus-user@...ts.sourceforge.net>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        keyrings@...r.kernel.org
Subject: Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the
 kernel is locked down

On Fri, Apr 7, 2017 at 3:50 PM, David Howells <dhowells@...hat.com> wrote:
> Andy Shevchenko <andy.shevchenko@...il.com> wrote:
>
>> > From: Matthew Garrett <matthew.garrett@...ula.com>
>> >
>> > We have no way of validating what all of the Asus WMI methods do on a given
>> > machine - and there's a risk that some will allow hardware state to be
>> > manipulated in such a way that arbitrary code can be executed in the
>> > kernel, circumventing module loading restrictions.  Prevent that if the
>> > kernel is locked down.
>>
>> > +       if (kernel_is_locked_down())
>> > +               return -EPERM;
>>
>> It looks a bit fragile when responsility of whatever reasons kernel
>> can't serve become a driver burden.
>> Can we fix this in debugfs framework instead?
>
> Fix it with debugfs how?  We can't offload the decision to userspace.

I mean to do at least similar like you have done for module
parameters. So, instead of putting above code to each attribute in
question make a special (marked) attribute instead and debugfs
framework will know how to deal with that.

-- 
With Best Regards,
Andy Shevchenko