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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
As does some options e. g., uinput.
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.
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.
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.
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.
Thanks for input! Alas, here is still work to do:
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
Fixed in [4968c5] and [591445]. There are still a lot of security problems with lircd, but closing this bug for now.
Related
Commit: [4968c5]
Commit: [591445]