[Feature request]: Advices to improve security when enabling access to /dev/uinput

[vemonet]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

Hi, I am trying to make simulating a Ctrl+V working on Wayland in a flatpak container

I managed to make it work with ydotool , but it requires r/w access to /dev/uinput to work

I noticed my user is in the nfsnobody group which own /dev/uinput:

crw-------. 1 nfsnobody nfsnobody 10, 223 Jun 28 12:57 /dev/uinput
uid=1000(vemonet) gid=1000(vemonet) groups=1000(vemonet),65534(nfsnobody

So I tried to simply sudo chmod g+rw /dev/uinput, but still got the permission denied (ok, not really logical, so let's bring it to the next level!)

sudo chmod a+rw /dev/uinput

And poof the permission denied disappeared! And I can finally make something out of my laptop! (also hackers can do a lot I guess)

Now, this solution is the worst from a security point of view, but at least I know it can work!

In this issue #4137 it is mentioned that we should be able to fine tune the access by defining some rules like Steam has done for their devices: https://github.com/ValveSoftware/steam-devices/blob/master/60-steam-input.rules

But I could not find no documentation about how or where to include those rules! And I couldn't find what the rule to enable keyboard access should look like (I have experience working with linux and consort, but I don't know all its arcanes)

What would be a cleaner solution to give the user access to /dev/uinput in a flatpak container? How can it be added to a flatpak manifest? Or will it need to be done manually by users outside of flatpak?

If you have any element of answers or pointers to enable to cleanly give a user access to /dev/uinput to simulate a keyboard key stroke, I would be interested! It would greatly help people to build secure packages (otherwise we need to do those dirty chmod hacks which kills all the hard work done to build a secure system)

[smcv]

This is not really a Flatpak question. The access to a particular device node that you get inside a Flatpak sandbox should always be less than or equal to the access you get outside Flatpak, otherwise that would be a serious security vulnerability (in either bubblewrap or the kernel, rather than Flatpak itself).

From the Flatpak point of view, /dev/uinput is part of --device=all. Anything beyond that is a question of system administration on your host system, not a question of how to configure Flatpak. If you configure udev to allow you access to /dev/uinput outside the Flatpak sandbox, then programs inside a Flatpak sandbox with --device=all will have that same level of access.

[smcv]

What would be a cleaner solution to give the user access to /dev/uinput in a flatpak container?

Ideally, "don't". Access to /dev/uinput is very powerful: it lets any application with access to /dev/uinput send fake keyboard and mouse input which will alter the behaviour of your real compositor. If it was completely safe, then it wouldn't be restricted to be root-only by default.

I believe the long-term answer to this is flatpak/xdg-desktop-portal#762, which proposes the addition of a portal interface that applications can use to inject input events into a compatible compositor under finer-grained control than /dev/uinput. However, this is not yet merged, and it requires your Wayland compositor to be built with support for libeis, which in practice none of them are just yet. When libeis is more stable, this will be the answer.

In the shorter term, using /dev/uinput is a necessary evil for use-cases like Steam Input - but if your application needs access to /dev/uinput, there is nothing that Flatpak can do to provide that access. flatpak run is completely unprivileged, so it cannot do anything that requires more privileges than you, the ordinary user, have, and in particular it can't install udev rules or chmod devices. (In principle if you have sudo privileges I suppose it could make use of them behind your back, but our policy is to not do that, because that makes the trust model much, much easier to describe.)

will [setup of udev rules] need to be done manually by users outside of flatpak?

Yes. Flatpak only installs and runs apps, it doesn't do system administration. Setting up udev rules is a sysadmin-level thing which must be done by installing operating-system-level packages (like steam-devices in Debian), or manually via sudo, pkexec or similar by a user with suitable privileges.

sudo chmod a+rw /dev/uinput

Certainly don't do that: that lets every user of a multi-user system fake input, including users logged in remotely via ssh, and system uids like www-data.

The least bad way to grant access to /dev/uinput is probably to give it the uaccess tag, like Valve's rule that you linked to. This will give you temporary access to /dev/uinput while you are the user logged-in on the foreground virtual console, by setting a POSIX ACL on the device node, but will revoke that access after you log out - that's also how access to audio devices and game controllers is done on modern Linux systems.

For details of how to write and install udev rules, see the udev(7) man page.

[vemonet]

Thanks a lot @smcv ! I guess this is the answer I was looking for:

if you configure udev to allow you access to /dev/uinput outside the Flatpak sandbox, then programs inside a Flatpak sandbox with --device=all will have that same level of access.

I'll just need to figure out what the rule for keyboard should look like and how to send it properly to udev

Ideally, "don't". Access to /dev/uinput is very powerful

I knew I was going to have at least one "Don't do it" thrown somewhere, classic linux! (but thanks for explaining anyway :D)

To be more clear: I don't want access to /dev/uinput, I don't care about it, I just want to be able to trigger a paste in wayland, this I care, and unfortunately uinput is the only solution. It could have been implemented in a safer way, but it was not, so I am playing with the tools that were given to me!

This feature is important to me, as it save me tons of time when writing. And is important for anyone who wants Linux desktop to be more user and developer friendly (automating stuff the way we want is why a lot of people are on linux)

And since flatpak is for packaging programs for the desktop.... It should also care about those kind of things no?

As soon as there are safer way to do those kind of thing I will implement them, but for now you got do what you got do!

Also the security "issue" due to all the laptop users can access uinput: I am the only user on my laptop (like most laptop owners I would expect, mostly only servers have multiple users, PC stands for Personal Computer). If someone is logged via SSH on it I think I have bigger problem than them faking keyboard input

[smcv]

And since flatpak is for packaging programs for the desktop.... It should also care about those kind of things no?

We cannot solve every problem for every user, some things have to be treated as out-of-scope.

I just want to be able to trigger a paste in wayland, this I care, and unfortunately uinput is the only solution

If you feel that this is a Wayland limitation, please talk to Wayland developers, not Flatpak developers. The Wayland protocol is outside Flatpak's scope. I suspect that there is probably a security reason why Wayland developers have not allowed application-triggered pasting (an obvious one is "you might have copied a password to the clipboard, and if untrusted apps could trigger a paste at any time they wanted to, then they would be able to log everything you have ever copied"); but in any case this is not a Flatpak limitation, so talking to Flatpak developers won't remove it.

As I said, the long-term solution to this is probably libeis, which isn't ready yet.

Also the security "issue" due to all the laptop users can access uinput: I am the only user on my laptop

You are the only human user, but there are multiple machine-level user IDs used for privilege-separation in system services, and those should not be able to inject fake keyboard events. For example if avahi, colord, geoclue or www-data get compromised, they should not be allowed to access /dev/uinput.

Also, the generic security model of Unix systems (including Linux) is to assume that all systems are at least potentially multi-user, so the design of generic software like Flatpak cannot assume that it will only be installed on single-user personal laptops like yours.

[vemonet]

Thanks again for all the details and explanation about it @smcv , that was really helpful to better understand the caveats and potential danger

I'll keep a note to check on libeis/xdg-portal-desktop when it will be mature enough

To be able to paste without going through /dev/uinput I also found the Virtual Keyboard protocol (unstable): https://wayland.app/protocols/virtual-keyboard-unstable-v1 , which is implemented in wtype (https://github.com/atx/wtype). But Mutter currently does not support the Virtual Keyboard protocol, so we will need to change the window composer to be able to use it

[swick]

Mutter currently does not support the Virtual Keyboard protocol

And it won't in the future because we'll be using libei.