Re: lircd daemon as regular user => device access problems

[Bastien ROUCARIES]

On Sun, Feb 12, 2017 at 4:09 PM, Alec Leamas  wrote:
>
>
> 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

[Bastien ROUCARIES]

On Sun, Feb 12, 2017 at 1:47 PM, Simon McVittie  wrote:
> 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

[Alec Leamas]

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

[Simon McVittie]

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

[Alec Leamas]

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

[Bastien Roucaries]

Le 11 février 2017 11:46:14 GMT+01:00, Alec Leamas  a 
é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

[Alec Leamas]

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.


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

[Bastien Roucaries]

Le 10 février 2017 16:13:15 GMT+01:00, Alec Leamas  a 
é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

[Paul Wise]

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

lircd daemon as regular user => device access problems

[Alec Leamas]

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



Thoughts?

--alec