Malice is not actually required here. Anything which can overload X to the point of (possibly temporary) lockup can cause the same set of problems. In an Xmir environment, you can break out to a VT to try to examine/fix a problem, which could be an actual 'need to bounce X', and you could have sent your login credentials and $deity knows what else to, say, IM, which you would not necessarily know until you checked your logs, assuming you keep IM logs. And with the lag involved between the action and the realization, you can be compromised by an external actor, and have no real way of knowing.
The only way around this would be to log in remotely via ssh or something similar, which requires having another system available and up and ready. Lacking that, the only way to bounce the system without compromising security is to pull a system reset at the box, which poses filesystem damage concerns.
Anything that makes me choose between security and possibly completely hosing my system (admittedly unlikely, but it could happen) is not getting installed on any box I control. And any distro which defaults to it is going on my blacklist.
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
Re: malicious xscreensaver getting your passwd, vs malicious mir-hog getting your passwd
Date: 2013-10-03 05:56 pm (UTC)The only way around this would be to log in remotely via ssh or something similar, which requires having another system available and up and ready. Lacking that, the only way to bounce the system without compromising security is to pull a system reset at the box, which poses filesystem damage concerns.
Anything that makes me choose between security and possibly completely hosing my system (admittedly unlikely, but it could happen) is not getting installed on any box I control. And any distro which defaults to it is going on my blacklist.