Re: [Utopia] [patch] Disable automounting when screen saver is running

[Jeffrey Stedfast <fejj novell com>]

On Thu, 2006-11-16 at 08:21 +0100, Kay Sievers wrote:
> On 11/15/06, David Zeuthen <david fubar dk> wrote:
> > One of our security dudes at Red Hat mentioned a possible attack vector.
> >
> > When the screen saver is running, the user may not be around to keep an
> > eye on their machine. There are a number of security attacks with a
> > specially crafted filesystem that can happen since the automounter
> > effectively performs mount, which is a privileged command, and reads the
> > directory contents.
> 
> Are we going to hack around people, that have physical access to the
> box and are able to add/remove hardware now? How about a corrupt
> network card and NetworkManager? Should we disable NM, when the
> screensaver is active too? Same problem with PTP cameras, and ...
> 
> I would say we should leave such "problems" to the proper
> infrastructure with console activity tracking, instead of introducing
> such weird hacks. :)

I think I tend to agree with Kay (however, I also acknowledge that I'm
not very security minded).

If the average user is anything like me, their screensaver isn't set to
go off until a minimum of 30-45 minutes have elapsed which is more than
enough time for Joe-Random-Evil-Guy to come along to exploit any
filesystem attacks (or, more likely, just install a key logger) - so
this seems kinda silly to me... 

then again, I don't use xlock... which I guess is the point of the patch
- this is more meant for users who, when leaving their
workstation, /manually start/ xlock to prevent other people from sitting
down at their console (am I seeing the correct scenario?).

In this latter case, I can see the point. Can we make the patch
understand the difference? If not, perhaps we could add an option to
g-v-m such as "ignore events while screensaver is running" (probably not
that wording, but you get the idea)?

My next suggestion might be to modify the function gvm_user_is_active()
to do the xlock screensaver check. This function was originally intended
(tho not yet implemented) to check that the user was the "active" user
on the console (when multiple users are logged in at the console). I
think that the xlock check would make sense to be included in the
is_active test (or am I wrong? I could be... the only difference I can
potentially see is that we may want to "queue up" these mount/etc events
for when the user comes back and then perhaps prompt him/her if she'd
like to actually mount them or whatever - btw, I say "events" because if
we're going to go to the trouble of blocking mounts if xlock is up, why
shouldn't we also block printer/scanner connection events? and palm
pilot connections, and...)


Make sense?

-- 
Jeffrey Stedfast
Desktop Hacker - Novell, Inc.
fejj novell com  - www.novell.com