Re: lircd daemon as regular user => device access problems
On Sun, Feb 12, 2017 at 4:09 PM, Alec Leamaswrote: > > > On 12/02/17 13:47, Simon McVittie wrote: > > Hi, thanks for thoughts! > > >> /lib/udev/??-mm-*.rules are probably of interest. ModemManager >> implements a whitelist (devices that are definitely modems), a blacklist >> (devices that are definitely not modems), and a greylist (devices that >> might be modems, but will only be probed by ModemManager if the >> userBastien >> explicitly requests it via some GUI or CLI frontend). > > > Following the same logic I think lircd should just implement a blacklist. > This is because lircd always works according to the greylist option - it > does not access any device unless it's selected by user on CLI or in GUI. > > /lib/udev/rules.d/77-mm-usb-device-blacklist.rules looks interesting, might > be a starting point for a blacklist. > > @Bastien: is there anything you would like to add to this list? No maybe this list could be shared ? > > > Cheers! > > --alec >
Re: lircd daemon as regular user => device access problems
On Sun, Feb 12, 2017 at 1:47 PM, Simon McVittiewrote: > On Sun, 12 Feb 2017 at 11:33:22 +0100, Alec Leamas wrote: >> On 12/02/17 11:16, Bastien Roucaries wrote: >> > Last time braille stuff break (brick) a FPGA device with a jtag adaptator >> > (serial to jtag). So i really dislike package that bind to all char device. >> > >> > Btw if you do this you need a break on braille stuff... >> >> Now, we are not talking about all character devices, it's about USB-based >> character devices. Does this address your concerns? >> >> If not, blacklisting probably is the easiest path - I'm happy to blacklist >> any USB ids if you just provide them. Or, if that's better, relevant udev >> info to make a matching rule. > > This is sounding a lot like ModemManager, which has recurring problems > with the inability to distinguish between modems and non-modem > serial-attached devices (especially since both will often use a commodity > USB/serial converter with generic device IDs, like a FTDI or PL2303 device) > without probing them by sending AT commands that could be interpreted in > unintended ways by non-modems (like Braille devices, embedded devices' > serial consoles, and Bastien's JTAG adapter). > > /lib/udev/??-mm-*.rules are probably of interest. ModemManager > implements a whitelist (devices that are definitely modems), a blacklist > (devices that are definitely not modems), and a greylist (devices that > might be modems, but will only be probed by ModemManager if the user > explicitly requests it via some GUI or CLI frontend). It is the only solution. Thanks simon to point to something sane. For FTDI/PL2303 I believe long term solution will be to install some gui (with ncurses) that will allow to custumize the description string in order to automagically whitelist (or assign some ID). Bastien > > S >
Re: lircd daemon as regular user => device access problems
On 12/02/17 13:47, Simon McVittie wrote: Hi, thanks for thoughts! /lib/udev/??-mm-*.rules are probably of interest. ModemManager implements a whitelist (devices that are definitely modems), a blacklist (devices that are definitely not modems), and a greylist (devices that might be modems, but will only be probed by ModemManager if the userBastien explicitly requests it via some GUI or CLI frontend). Following the same logic I think lircd should just implement a blacklist. This is because lircd always works according to the greylist option - it does not access any device unless it's selected by user on CLI or in GUI. /lib/udev/rules.d/77-mm-usb-device-blacklist.rules looks interesting, might be a starting point for a blacklist. @Bastien: is there anything you would like to add to this list? Cheers! --alec
Re: lircd daemon as regular user => device access problems
On Sun, 12 Feb 2017 at 11:33:22 +0100, Alec Leamas wrote: > On 12/02/17 11:16, Bastien Roucaries wrote: > > Last time braille stuff break (brick) a FPGA device with a jtag adaptator > > (serial to jtag). So i really dislike package that bind to all char device. > > > > Btw if you do this you need a break on braille stuff... > > Now, we are not talking about all character devices, it's about USB-based > character devices. Does this address your concerns? > > If not, blacklisting probably is the easiest path - I'm happy to blacklist > any USB ids if you just provide them. Or, if that's better, relevant udev > info to make a matching rule. This is sounding a lot like ModemManager, which has recurring problems with the inability to distinguish between modems and non-modem serial-attached devices (especially since both will often use a commodity USB/serial converter with generic device IDs, like a FTDI or PL2303 device) without probing them by sending AT commands that could be interpreted in unintended ways by non-modems (like Braille devices, embedded devices' serial consoles, and Bastien's JTAG adapter). /lib/udev/??-mm-*.rules are probably of interest. ModemManager implements a whitelist (devices that are definitely modems), a blacklist (devices that are definitely not modems), and a greylist (devices that might be modems, but will only be probed by ModemManager if the user explicitly requests it via some GUI or CLI frontend). S
Re: lircd daemon as regular user => device access problems
On 12/02/17 11:16, Bastien Roucaries wrote: Last time braille stuff break (brick) a FPGA device with a jtag adaptator (serial to jtag). So i really dislike package that bind to all char device. > > Btw if you do this you need a break on braille stuff... Now, we are not talking about all character devices, it's about USB-based character devices. Does this address your concerns? If not, blacklisting probably is the easiest path - I'm happy to blacklist any USB ids if you just provide them. Or, if that's better, relevant udev info to make a matching rule. Cheers! --alec
Re: lircd daemon as regular user => device access problems
Le 11 février 2017 11:46:14 GMT+01:00, Alec Leamasa écrit : > > >On 11/02/17 10:29, Bastien Roucaries wrote: >> Le 10 février 2017 16:13:15 GMT+01:00, Alec Leamas > a écrit : >>> Dear list, >[cut] >>> Proposed /dev/ permissions after installing lirc: >>> >>> - The /dev/lirc? devices are set user:group lirc:lirc and mode 660 >>> (udev rule). >>> - The lirc user is added to the input group, to access /dev/input >>> devices. >>> - The lirc user is added to the dialout group to access /dev/ttyS >>> devices. >>> - The /var/lock dir is root:root 755 in my stretch box but this is >>> seemingly #813703; assuming this will be fixed to 1777. >>> - lirc user gets read access to all USB character devices using a >udev >>> rule invoking facl(1). >>> >>> I know that getting permission is harder than to be forgiven, but >>> perhaps it makes sense to have a discussion first? >>> >>> The possibly controversial issue is the USB devices. However, >without >>> this rule a large part of lirc users will be forced to painful udev >>> rules configuration >> >> >> Can we list USB device needed (whitelist) ? > >I don't think so. The number of devices used by lircd is large, and the > >USB ids are not always well-defined... > >It might be possible to whitelist "most" devices, leaving it up to >users >of "uncommon" devices to fix it on their own. More work for both >package >maintainers and users, although more safe... > >Personally I don't think read access to character devices should be >that >sensitive. The most obvious concern are hardware login dongles. Of >those, most seems to be mass storage devices; these are *not* covered >by >the udev rule. Neither is yubikey devices. Last time braille stuff break (brick) a FPGA device with a jtag adaptator (serial to jtag). So i really dislike package that bind to all char device. Btw if you do this you need a break on braille stuff... Could we have both ? A whitelist of well know device ans a package (suggested) lirc-usb that catch all... If you need lirc-usb please film a bug ? Thanks Bastien >Also, whatever risks there are we are already taking them when running >lircd as root. > > >--alec -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
Re: lircd daemon as regular user => device access problems
On 11/02/17 10:29, Bastien Roucaries wrote: Le 10 février 2017 16:13:15 GMT+01:00, Alec Leamasa écrit : Dear list, [cut] Proposed /dev/ permissions after installing lirc: - The /dev/lirc? devices are set user:group lirc:lirc and mode 660 (udev rule). - The lirc user is added to the input group, to access /dev/input devices. - The lirc user is added to the dialout group to access /dev/ttyS devices. - The /var/lock dir is root:root 755 in my stretch box but this is seemingly #813703; assuming this will be fixed to 1777. - lirc user gets read access to all USB character devices using a udev rule invoking facl(1). I know that getting permission is harder than to be forgiven, but perhaps it makes sense to have a discussion first? The possibly controversial issue is the USB devices. However, without this rule a large part of lirc users will be forced to painful udev rules configuration Can we list USB device needed (whitelist) ? I don't think so. The number of devices used by lircd is large, and the USB ids are not always well-defined... It might be possible to whitelist "most" devices, leaving it up to users of "uncommon" devices to fix it on their own. More work for both package maintainers and users, although more safe... Personally I don't think read access to character devices should be that sensitive. The most obvious concern are hardware login dongles. Of those, most seems to be mass storage devices; these are *not* covered by the udev rule. Neither is yubikey devices. Also, whatever risks there are we are already taking them when running lircd as root. --alec
Re: lircd daemon as regular user => device access problems
Le 10 février 2017 16:13:15 GMT+01:00, Alec Leamasa écrit : >Dear list, > >After some work it seems that an updated LIRC package has landed in >stretch without any major problems. This resolves the urgent need to >update it to something recent enough to be supported by upstream. > >One remaining problem is that lircd, the main LIRC daemon, runs as >root. >This is code from the 90's, heavily user-configured. Running this as >root is just not sane, and other distros has moved to running it as a >regular user since long. I want to make this change for sid/buster. > >However, running lircd as non-root raises permissions problems related >to /dev/... devices. Since lircd is configured in all sorts of ways, >many kinds of devices are potentially used. The paranoid configuration >is to block all devices for lircd, leaving it to user to enable them as > >required. This is a breaking update for almost all users. > >The alternative is to use the Fedora strategy, outlined below. This >means changing overall permissions for several /dev/... devices. Is >this >OK, should it be discussed on this ML, or somewhere else? > >Proposed /dev/ permissions after installing lirc: > >- The /dev/lirc? devices are set user:group lirc:lirc and mode 660 >(udev rule). >- The lirc user is added to the input group, to access /dev/input >devices. >- The lirc user is added to the dialout group to access /dev/ttyS >devices. >- The /var/lock dir is root:root 755 in my stretch box but this is >seemingly #813703; assuming this will be fixed to 1777. >- lirc user gets read access to all USB character devices using a udev >rule invoking facl(1). > >I know that getting permission is harder than to be forgiven, but >perhaps it makes sense to have a discussion first? > >The possibly controversial issue is the USB devices. However, without >this rule a large part of lirc users will be forced to painful udev >rules configuration Can we list USB device needed (whitelist) ? Bastien > >Thoughts? > >--alec -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
Re: lircd daemon as regular user => device access problems
On Fri, Feb 10, 2017 at 11:13 PM, Alec Leamas wrote: > Thoughts? Your post reminds me of the uaccess and AppStream items here: https://lists.debian.org/debian-devel-announce/2016/11/msg8.html -- bye, pabs https://wiki.debian.org/PaulWise