On 2010-01-26 17:31, Josselin Mouette wrote: > Le mardi 26 janvier 2010 à 16:19 +0100, Guido Günther a écrit : > > > True, but this one is trivial to exploit and is also fairly easy to > > > prevent so > > > why stick with it? > > I can only agree here. procps should at least get a: > > > > sys.kernel.sysrq = 0 > > It’s only a workaround, and it’s a bit too much to disable all SysRq > since other SysRq combinations are not a security threat. However we > could ship this in the gnome-screensaver/xscreensaver packages if there > is no other solution. This would make the obvious and immediate security > issue go away. Simultaneously, we can forward the issue upstream so that > they can work on an appropriate X11 extension as suggested by Bastian.
Another solution could be to let the screensaver set /proc/self/oom_adj to -17 to disable the possibility of this process beeing killed by the oom-killer. (linux/Documentation/filesystems/proc.txt) > > > Safest would be to make the kernel default to off though (the user can > > still reenable this via procps) since there's otherwise still a race > > until /etc/init.d/procps starts. > > I don’t think this race condition is relevant. The only thing that can > protect you from someone who has access to the console at boot time is > to encrypt your data. The screensaver’s lock is here to prevent the data > from being accessed without a reboot. > > Cheers, > -- > .''`. Josselin Mouette > : :' : > `. `' “A handshake with whitnesses is the same > `- as a signed contact.” -- Jörg Schilling > Lars Olav Dybsjord [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
