On Thu, 2006-11-16 at 08:21 +0100, Kay Sievers wrote: > On 11/15/06, David Zeuthen <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] - www.novell.com _______________________________________________ utopia-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/utopia-list
