Re: Another Mac OS X ScreenSaver Security Issue (after Security Update 2003-07-14)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



If anything I'd call this a security consideration of Escape Pod. Perhaps Escape Pod should try to talk to the process it's about to kill, and get its 'permission' for killing, and failing a timely response (2 secs?), drop the program. ScreenSaverEngine would have to be tailored to respond to such a request.

On Linux, doesn't xscreensaver run as root? Wouldn't this be another option here (I'm admittedly unfamiliar with Mac OS X), preventing Escape Pod from even being capable of terminating the screensaver process? Or does Escape Pod also run as root?

If you ask me, Escape Pod owes it to their users to develop the product in such a way so to not nullify reasonable security measures on the part of the OS, even if that's an option to never terminate processes named ScreenSaverEngine.

-MightyE

Alaric B Snell wrote:

Rizwan Jiwan wrote:

I wouldn't consider this a bug. It is like me writing a script that kills
any process named "ScreenSaverEngine". If I run it with my privileges it
should allow me to kill the process (assuming I own ScreenSaverEngine).
Escape Pod does what it is meant to. OS X does what it is meant to--that is
unless you are suggesting that the operating system not allow the user to
kill the screen saver process which is just stupid because I have had my
screen saver crash on me.


Yes. But either way, it looks as if a side effect of Escape Pod is that it nullifies the security of the screen saver.

It sounds like the real issue is that the screensaver - which is meant to lock the keyboard, mouse, and display device to prevent tampering by passers-by (who do not have the option of taking the machine home and mounting the disk in another machine et al). The flaw seems to be in that the OS is still passing keyboard events to the likes of Escape Pod when the screensaver has asked to lock the keyboard. Maybe it's the screen saver's fault, in that it's not properly locking the keyboard, but it's more likely to be that the code in the GUI that handles locking the console should disable 'hotkey' processing too.


-Riz



ABS




[Index of Archives]     [Linux Security]     [Netfilter]     [PHP]     [Yosemite News]     [Linux Kernel]

  Powered by Linux