Hi Chris, On Wed, Aug 21, 2019 at 03:52:44PM -0700, Chris Lamb wrote: > > I've been working on an updated patch that detects new devices and > > blocks them too. However, "grabbing" devices during the processing of > > these "device hierarchy changed" events appears to do something funny > > and actually disables all input entirely for me > > Whilst I've fixed that bit at least, the new attached patch doesn't > grab devices that are renabled via "xinput enable" although we do > successfully detect that "edge" event now.
Cool! I'm not sure whether this other edge case is important -- are
there situations where an attacker in front of a locked computer could
manage to pull this off?
Oh, and if we can detect the edge event, can't we grab the devices
somehow -- in the worst case, just by restarting xtrlock?
Another question (but that's probably being too paranoid): with
approaches that grab new devices as they show up, are there risks of a
timing attack where the attacker could be able to do some events before
xtrlock can grab the device? (Probably not as a human, but imagining a
malicious device that would regularly simulate disconnections.) The
question is, does xtrlock have any guarantee that it can grab the device
before events from the device will be processed?
> Antoine, how did you find the right /sys/bus/usb/devices/FOO directory?
> I'm only using xinput as I can't seem to locate my touchpad under
> /sys/bus.
Well, pretty clumsily. I did "lsusb -t -v". I found the touchscreen
there, with its ID (04f3:000a). Then I did something like:
cd /sys/bus/usb/devices
for a in *; do
echo $a;
cat $a/idVendor
done
... and went to the folder having the right ID -- and tried to disable
it and saw that I had found the right one.
Best,
--
Antoine Amarilli
signature.asc
Description: PGP signature
