#12 lircd should not run as root

security (2)
Alec Leamas

Having lird running as root is a needless security hazard. With the new userspace scenario, there is really nothing which requires root permissions. However, there are a lot of sharp edges to handle before we can run lird as a regular, daemon user.


Tickets: #46


  • Bengt Martensson

    Agree completely. Let me also add that it is a usecase that a normal user wants to start lircd, under his own UID, for sending receiving a few IR signals. It is a matter of permissions to files in /var/run/, like /var/run/lock (for some using "serial" stuff). Also some drivers (e.g. usb_uirt_raw IIRC) presently needs to be root.

  • Alec Leamas

    Alec Leamas - 2014-08-17

    As does some options e. g., uinput.

  • Christoph Bartelmus

    When using LIRC with home-brew transmitters, you can trivially block a machine completely by sending bad data through /dev/lirc. For that reason /dev/lirc cannot be user accessible to prevent DOS attacks. Hence lircd will need according priviledges. Access to /var/run and /dev/uinput has been mentioned before.

  • Alec Leamas

    Alec Leamas - 2014-08-18

    Basically, I guess this could be handled using group permissions or perhaps just giving the lirc daemon user access to the related devices which could be modified using a udev rule. Up to this point, this is more or less a packaging thing.

    That said, it's obvious that there will be cases when lircd needs to run as root. In those cases we should be able to drop the privileges once we have opened devices etc.

  • Alec Leamas

    Alec Leamas - 2014-10-07

    To get this moving we should ship a udev rule which sets the permissions on /dev/lirc* to 660 and make them belong to a group 'lirc'. This would open up running lircd as a non-privileged user. By providig hooks upstream it will
    hopefully be more unified between different distros.

  • Bengt Martensson

    Let me add that there is no glaring silliness in the code wrt root. In fact, Lircd runs fine as non-root if it can access all the devices and all the files it wants -- I have verified this myself.

    So the remaining issues are integration in distros. Which is not Lirc proper any more.

  • Alec Leamas

    Alec Leamas - 2014-10-08

    Thanks for input! Alas, here is still work to do:

    • In situations where we need to be root to open devices and such, we should drop privileges once the privileged stuff is done.
    • It's better if we as upstream ships and maintain a simple udev rule for changing permissions/group ownership of /dev/lirc*
  • Alec Leamas

    Alec Leamas - 2014-10-10

    Noe to self: hm... using kernel capabilities seems to be a much better choice. Adding CAP_DAC_OVERRIDE to the executable will make it possible to open any device, including /dev/uinput. Although being able read/write any file opens up for a lot of mischief, it's still limited - there are full root privileges to try to grab. Dropping the capability after curr_driver->open_func() will also decrease the attack vector.

    This is a Linux only solution(?) However, other OS:s can always run lircd as root as of today if need be.

    Current (lack of) design cannot really be made secure anyway. What we could do is try to plug the obvious leaks, though. Of course, running as a regular user is the preferred solution.

    Last edit: Alec Leamas 2014-10-10
  • Alec Leamas

    Alec Leamas - 2014-10-10
    • status: open --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks