Re: xscreensaver bug?

From: Terry Lambert <tlambert2_at_mindspring.com>
Date: Thu, 13 Nov 2003 04:14:02 -0800
jqdkf_at_army.com wrote:
> I'm new in FreeBSD. I found that after I lock screen with xscreensaver,
> I can unlock it with the root's password as well as my normal user's
> password. I don't think it is a good thing. Is it a bug?

It is intentional, although you can eliminate it with a recompile
of the xscreensaver code, with the right options set.

The intent is to allow the most priviledged user on the system,
who could conceivably log in remotely and access all your data
anyway, to "kick off" students or other people, perhaps in a
large campus common xterminal lab, so that scarce shared resources
are not tied up running a screen saver when there are people
waiting to use them.

Since the root user could always pull the power plug on the
machine, reboot it, and get rid of the console user that way
(after a lngthy delay to check the disks), then log in as root
and access your data that way (again), the only thing you would
be protecting is your session state.

Note that a root user could still log on remotely, and, for
things like IRC and other things with active I/O, still load a
kernel module and take over your socket connections, etc. (in
fact, this is an excellent way to create "borgs" for Netrek on
Linux machines: just make a kernel module that can watch the
traffic and knows how to fly the ship, fire torpedos, and strip
"bork commands" out of the input stream for your "blessed"
client).

About the only thing you prevent them from getting at are your
screen contents, and those are available through kernel modules,
as well.

Absolutely worst case, the root user could log in remotely, gdb
your screen saver, type "foobar" as the password, and then hack
the authentication function return value to say "yes, that's the
correct password for "jqdkf_at_army.com", and get in without needing
to have xscreensaver accept the root password.

In other words, the default UNIX security model is inadequate to
protect things like compartmentalized data that the user "jqdkf"
has access to, but that the user "root" is not supposed to have
access to.

If it really bothers you, then recompile xscreensaver; but then
realize that if it really bothers "root", they will just work
around your laughable attempts to keep them out.


Personally, if I were running a public lab, and there was a box
with xscreensaver running on it that I wanted to log out, I'd use
the root password to stop it, and just log the user out.  Short of
seeing kiddie porn as the background, I'd probably ignore the
screen contents to the point of not remembering them 5 minutes
later.

On the other hand, if there was a box with xscreensaver running on
it that I wanted to log out, and I tried to use the root password to
stop it, and doing so failed, I would get intensely curious as to
why it was apparently broken, and do my best to perform a root cause
failure analysis for the xscreensaver program.  This would probably
make me remember a lot more, particularly the user who was logged in
at the time, and the applicaions they were running, which could have
interfered with keyboard input processing, etc..

If this is a public lab, and you are trying to avoid scrutiny (a
difficult thing in a public lab, under any circumstances), then you
painting a big red target on your back is probably not the best way
to avoid unwanted attention (IMO).

If you plan on leaving a machine unattended long enough for this to
be an issue for you, there's a 100% reliable way to avoid the
problem: log out before you walk away.  8-) 8-).

-- Terry
Received on Thu Nov 13 2003 - 03:24:38 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:28 UTC