What security practices do I employ when building a library that requires low level root access to certain devices and files?

Question

Backstory

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:

Questions

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?

Thanks.

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