https://bugs.kde.org/show_bug.cgi?id=482614
PasserBy 006.5 <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthuripswichdent01@outlook | |.com --- Comment #12 from PasserBy 006.5 <[email protected]> --- I've triggered this bug with Signal. Everything that I learned about next steps, I learned from z.ai, and attempted to confirm by playing with ffplay and fsnotifywait. I think that how hard it is depends a lot on how compromised the machine is. Here is an attempt at a taxonomy of conditions and the responses that they call for: - much better than usual (for the purposes of comparison) -- the machine is telepathic and competent. It does whatever the person wants, who last sat in front of it --- physical security of the machine; reliably wish for privacy; wish the indicator changed, to cosmetically give better information : - ) - the usual best case -- the machine only runs the operating system as manufactured and the user's choice of user-land software --- have good luck and good management chosing what to install; make no mistakes while using it --- the indicator is faulty, but the fault is not compromising - the attacker has never run software as root -- the relevant device files are all in /dev -- monitor their use and also creation (dynamically by udev, especially when a webcam is plugged in) with fsnotify (which requires a root helper), or inotify (which has race conditions) --- fsnotify comes with options to block the opening of webcams, as requested in https://bugs.kde.org/show_bug.cgi?id=447034 - the attacker has run software as root, but is not since the last reboot -- there are device files elsewhere in the filestem --- search for and remove those device files over time --- monitor access to the video device driver - the attacker is running software as root, including device drivers -- a substitute device driver is providing untraced access to a webcam and emulating the usual driver --- this one is beyond me. It probably involves shutting down the machine, mounting its firmware and filesystem on a machine that is still trustworthy, and positively accounting for all executable code, which cannot be done from the inside of an indicator applet : - ) So, someone (bags not me) gets to decide what degree of compromise the indicator should be resistant to, which affects what the next steps are. -- You are receiving this mail because: You are watching all bug changes.
