[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 20/08/13 17:11, Migel Wimtore wrote: > Lol: Arch. > > Yes: I'm on a laptop. > > Sorry for the top post here (k9 mail). > > Well, if I have already logged in on one or more of the other VTs then the system > is sitting wide open on resume; any naughty one could just drop to the open > console with a single keyboard command. > > I see this as a gravely series security flaw! Really, I do. Am I missing > something? > > My SSH is locked down with pub/priv keys & on a random port. It seems to me that > what is left is this gaping, local security hole. > > My, less than ideal, solution from my previous post is working pretty not to bad > though, & makes an obvious case for xtrlock: the desktop is visible on resume > (kinda cool & usefull) but inaccessible without a password - it is locked. And, > with the console switching keyboard commands disabled & SSH locked down, is part > of a working - but slightly cludgy - suspend/resume security solution. > > No matter what locker I use in Openbox, the desktop flashes up for some seconds > before going black and presenting a login screen. So having the desktop visible > (but inaccessible) doesn't really lose me much privacy either. Ah, ok, I make more sense of it now - of course, if you're running multiple jobs across different VTs on a single host, then yes, a malicious local user with access to the keyboard can ctrl+alt+Fx to your running sessions which won't be password locked. To be fair, it's relatively unusual (???) to be using features like this even for power users (???) although obviously you do, and I frequently have secondary, tertiary and even more X sessions running nested, directly or remotely from other hosts on my VTs so obviously I use it too. The vast majority of the time it's not an issue for me - normally working from home, I know random people can't breeze in and access my office. On-site I less frequently need or use multiple VTs and when I've got separate X sessions on them, I would password lock them conventionally or detach them if I was that worried about walking away from them at lunchtime. But to directly address the issues of just having multiple consoles running on your VTs, already logged in and potentially accessible via keyboard shortcuts by office infiltrators, I've never thought about this issue before because I use screen/tmux/byobou religiously rather than directly attaching VTs, which seems very clunky and primitive-UNIXy flavoured behaviour. If I want shell number 2/3/4...50/51 etc, which I very frequently do, then I use my Xorg rendered desktop as god intended - I just start another terminal instance and tile it, tuck it away on another virtual desktop, etc. Apart from extra instances on the localhost, and even then, not infrequently, if I want remote ssh access or whatever, I'll immediately spawn a screen/tmux instance as best practice (many of my boxes have two admin accounts for me for sanity/safety reasons - one a conventional /bin/sh|bash|zsh instance and the other with /bin/screen as the login shell) which then provides me with the options to detach/reattach/share my session as appropriate, even following a machine hibernating, the connection being dropped, etc. Absolutely the last thing I would do is ctrl+alt+F1, drop to a new VT, login and start working on that head as well, leaving my main X instance running on F7. Why would you do that? It's not 1995 anymore chief! Gnome3 will dynamically create an endless amount of new workspaces for me to put new terminals in, and my minimalistic DE choice Awesome comes by default with 9 "pages", which even at one fullscreen terminal instance per page still gives me 9 rapidly accessible workspaces. All other DEs I've ever worked with will also give you a *lot* of space to put all your login shells/terminals/ssh sessions/etc, easily configurable, lockable on resumption via normal X methods and with all the advantages of a modern desktop. With the exception of Windows (no virtual desktops by default, numerous 3rd party tools will enable this functionality though (badly, in my experience)), all your mainstream OS's can do this, including Mac OS (multiple virtual desktops, effectively endless space to put different sessions). I don't have the flickering momentary desktop exposure issue you have, although to be fair, I have definitely seen it before on certain distros/DEs before - I can freely admit I have no idea what that's about. Whilst I will also happily admit you have definitely come across an issue here, it's not a gaping security hole at all - it's a clear and present warning for you to update your working practices to something more sensible, particularly as you seem so worried about the security aspect. But this is simply Linux/Unix working as expected! If you switch to a VT outside of X, log in *and leave it logged in* how can you possibly be surprised that X's security screenlock, operating at a higher level, doesn't protect access to something outside of it's remit? What you are doing is raising the castle drawbridge, dropping the portcullis, and ignoring the fact that there are 4 servant entrances completely unguarded round the back *that you left there* gaping open at that. If you must insist on switching to VTs (why?), then immediately launch screen after login and work there: when you want to go away, detach the screen(s) and either lock your session or logout, leaving your work running. Of course, this is still inferior to just logging in new shell instances and switching to screen inside them, but from your main X-provided DE with all of it's unlimited screen real estate and standard security features. An unprotected VT is exactly that - it's like wondering why people can wander up to your running AS400 session in a DEC VT220, which you left logged on, and flick on the switch and start hacking. Anyway, I'd argue that you have a problem of your own creation here - which is just as well, as you have obviously managed to fix it on your own anyway so all is well with the world :] I'm still curious as to why you'd work that way in the first place. Combined with the suspend/resume paranoia, you just seem to be making problems for yourself in a shared and apparently untrusted environment. Interesting stuff though, I love it when the weirder things like this pop up on-list. Cheers * (???) because "citation needed": maybe everyone outside of my circles actually does work like this? -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq