I am writing a library that accesses the kernel module, uinput which allows you to create or take control of devices in /dev/input/event#, and insert events into them.

A simple usecase would allow someone to write a script that would move a mouse cursor to the center of your display, and perform a left click.

As such, it needs root priveleges in order for it to function, and I am not sure what tangible risks I am taking here, and exactly what precautions I need to employ.

I asked about this in ##kernel, and one response I got was:

I do a lot of security-related stuff - and I also write a lot of code that I don't bother doing too much security checking on because an attacker can't get at it unless he's already pwned the box - in other words, zero real risk of privilege escalation.


  1. Is what he says true, that my library will be fine to the extent that my system is not "pwned"?
  2. To that, how do I know my library will not become a vector for my system to be "pwned"? I am not a hacker so I would not know what exposes my library to such a thing.
  3. I want my code to be presentable to potential employers, so even if it is true that I need not worry, what security practices should I employ just to demonstrate that I am astute and conscious of potential security risks?
  4. Would a best practice in this case involve me creating a user with a special permission group that limits his exposure to the system?


  • 1
    I can't read the image due to firewall issues where I am right now. In the future it would help, copy and paste as a quote. Feb 13, 2018 at 20:32
  • 2
    If you need root permissions to use this, how to you expect this functionality to be executed?
    – JimmyJames
    Feb 13, 2018 at 20:59
  • @JimmyJames Prompting the user for permissions, or perhaps upon installation, create a special user with the minimal permissions requisite to run the program, and having the program run as that user.
    – Anon
    Feb 13, 2018 at 21:19
  • 1
    @akiva, if your project is only a library you can't do that. It's the running process that defines what permissions are available. If your project has a service that is wrapped with a library you can. There are risks, but it is possible. Feb 13, 2018 at 21:25
  • So is this something for 3rd parties to use or just the user/admin/owner of the machine?
    – JimmyJames
    Feb 13, 2018 at 22:21

1 Answer 1


The first thing you'll have to understand about the risks introduced by this design you have to consider what root can do that normal users can't.

A user in the root group can do a great number of things that normal users cannot:

  • Delete all files in the operating system--including the kernel itself: rm -rf /
  • Reformat and repartition drives
  • Start and stop services
  • Install and uninstall applications--including malware
  • Access all files in user home directories (i.e. violate privacy)

Granted, modern installations of Linux do require you to sudo to escalate privileges to root if you are in that group. That prevents stupid mistakes from completely destroying your machine.

That said, if your library requires escalated privileges, so does any application that uses it. If the process using your library doesn't have root privileges, then your library won't have access to uinput. Essentially it will look like your library is broken. I am unaware of a way to have escalated privileges for a library but not for the application calling it.

The only way around the elevated privileges for the process I know of is to separate your library into a service that runs with the appropriate privileges and the piece that makes calls to that service. This approach will at least allow you to grant access to uinput but not necessarily anything else. That allows you to control one vector for privilege escalation.

I have worked with some gray hat hackers, who essentially know how to "pwn" a box that isn't currently "pwned". Even if your service only has access to uinput, they could still have a field day since they can have control over the mouse and keyboard to indirectly control your system.

I would take that user's response with a very large grain of salt. While the likelihood of a hack may be low, it is not zero. That user is probably lucky.

Best Practices:

  • Try to find any other means of providing the same functionality without requiring elevated privilege possible. If not, continue on the list.
  • Exercise the principle of least privilege. In other words make sure you only grant access to what you need and actively deny everything else.
  • Separate the code that needs elevated privileges to run in its own process under its own user
  • Minimize time in escalated code as much as possible
  • Audit and test code that calls privileged APIs more rigorously than unprivileged code
  • 3
    Sounds like what he needs to write is a device driver, not a library. Device drivers clearly run with elevated privileges, while the users that employ them do not. Feb 13, 2018 at 22:00
  • @RobertHarvey This sounds like the most appropriate solution. Create a device driver, and interact with it using an API which operates on a signature system, which beyond requiring an encrypted signature, would also limit the access to the API. Say for example, the time of day it is allowed to run, what keypresses are enabled/disabled, etc. – Sound about right?
    – Anon
    Feb 14, 2018 at 1:44
  • 2
    It doesn't sound like that user was lucky. Rather, it sounds like he interpreted the question the way I do: "My library needs root privileges to run, what security risks does that present?" If I can use your library to write a script, then I need this script to run with root privileges. If my script runs with root privileges, I already can do whatever I want, and nothing your library can do will make it worse. (cont) Feb 14, 2018 at 10:36
  • 3
    It's only a security risk if your code offers a limited service to less-privileged users, e.g. a kernel module offering world-accessible control files, or a setuid executable, or a daemon with some world-accessible IPC interface. Those are possible privilege escalation attack vectors. A library like the OP is writing might be likely to be included in such a service, though, so that's where the real danger comes from. Bugs in the library could be exploitable unless the service around it correctly sanitizes all inputs so as to not trigger those bugs (and has no bugs in the sanitation). Feb 14, 2018 at 10:39
  • 1
    @SebastianRedl, my experience with real hackers who are paid to do penetration testing leads me to believe that if there are vulnerabilities in a library or process, they can be exploited to gain the privilege of the user it is running under. Feb 14, 2018 at 13:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.