linux-kernel - Re: [PATCH v2] HID: uhid: forbid UHID_CREATE under KERNEL

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: <A3AEDFEA-7810-4200-BBB9-055285062266@amacapital.net>
Date:   Thu, 15 Nov 2018 06:50:05 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     David Herrmann <dh.herrmann@...il.com>
Cc:     Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Dmitry Torokhov <dtor@...gle.com>, ebiggers@...nel.org,
        jannh@...gle.com, Jiri Kosina <jikos@...nel.org>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        syzkaller-bugs@...glegroups.com,
        Dmitry Vyukov <dvyukov@...gle.com>,
        syzbot+72473edc9bf4eb1c6556@...kaller.appspotmail.com,
        stable <stable@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH v2] HID: uhid: forbid UHID_CREATE under KERNEL_DS or elevated privileges



> On Nov 15, 2018, at 4:06 AM, David Herrmann <dh.herrmann@...il.com> wrote:
> 
> Hey
> 
> On Thu, Nov 15, 2018 at 9:14 AM Benjamin Tissoires
> <benjamin.tissoires@...hat.com> wrote:
>> 
>> On Thu, Nov 15, 2018 at 12:20 AM Dmitry Torokhov <dtor@...gle.com> wrote:
>>>> I think it's best not to make
>>>> assumptions about how the interface will be used and to be consistent with how
>>>> other ->write() methods in the kernel handle the misfeature where a __user
>>>> pointer in the write() or read() payload is dereferenced.
>>> 
>>> I can see that you might want to check credentials, etc, if interface
>>> can be accessed by unprivileged process, however is it a big no no for
>>> uhid/userio/uinput devices.
>> 
>> Yep, any sane distribution would restrict the permissions of
>> uhid/userio/uinput to only be accessed by root. If that ever changes,
>> there is already an issue with the system and it was compromised
>> either by a terribly dizzy sysadmin.
> 
> UHID is safe to be used by a non-root user. This does not imply that
> you should open up access to the world, but you are free to have a
> dedicated group or user with access to uhid. I agree that in most
> common desktop-scenarios you should not grant world-access to it,
> though.
> 
>>> 
>>>> Temporarily switching
>>>> to USER_DS would only avoid one of the two problems.
>>> 
>>> So because of the above there is only one problem. If your system
>>> opened access to uhid to random processes you have much bigger
>>> problems than exposing some data from a suid binary. You can spam "rm
>>> -rf .; rm -rf /" though uhid if there is interactive session
>>> somewhere.
>>> 
>>>> 
>>>> Do you think the proposed restrictions would actually break anything?
>>> 
>>> It would break if someone uses UHID_CREATE with sendpage. I do not
>>> know if anyone does. If we were certain there are no users we'd simply
>>> removed UHID_CREATE altogether.
>> 
>> AFAICT, there are 2 users of uhid:
>> - bluez for BLE devices (using HID over GATT)
>> - hid-replay for debugging.
> 
> There are several more (eg., android bt-broadcom), and UHID_CREATE is
> actively used. Dropping support for it will break these use-cases.
> 
> 

Is the support story for these programs such that we could add a big scary warning and remove UHID_CREATE in a couple months?