D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] Completely lock down on virtual consoles on supend

 

Interesting to hear about your setup. Though it is much more elaborate than what I feel I need (I'm just a simple home user).
However, I do think you are playing the apologist more than a bit.
So, X is locked on locking X, yeah, fair enough, obviously, but what about the other VTs that are potentially accessible? Wouldn't it be nice if the screen lock targeted the entire system, and wasn't an X lock at all, but was something lower level.
I'm asking for the key to those servants doors. I'm the one pointing out that they're open, when the portcullis is down. I'm not surprised by it.

Using the other VTs provided - as default! - with all Linux setups may seem outdated to you, but it is still the way distros come; it is simply how the Linux userland works, for now. Any other work flows, such as using Screen to manage console instances must be set up by the user, & so it is, in its stock state, that it is potentially vulnerable. Where a person might leave their computer, possibly assuming it's locked, and it may not be at all.

Having multiple consoles that are not contained in X can actually be usefull in its own right. For example, when dropping to an alternate VT to fix an X freeze, or kill a rogue graphical app that is stopping X from accepting input in a timely manner. Let's say you are sitting around today in 2013 and have killed kdm from another VT as your DE has frozen, you fire up kdm, log back in, then later suspend your machine and go away; there it sits: your computer, vulnerable, undeniably vulnerable, and here he comes - that office infiltrator.

I have considered Screen, and whilst I have not totally grocked it, believe it to be more than I need. I like my three dedicated desktops, on which certain apps open by default & to which F1/2 and 3 transport me. I don't want loads of virtual terminals on loads of virtual desktops. I have one terminal that is always running, with tabs and split screen functionality. I use a keyboard shortcut that links to a small wmctrl script, which calls the running instance of my terminal emulator to wherever I am & places it on top. Indeed nearly all my activity in X is contained to virtual desktop 1 & all the apps I use regularly have a dedicated keyboard shortcut, that links to a wmctrl script, which either moves focus to that app's location or brings that app to the current desktop. This way I hardly ever have to cycle through the alt tab menu or remember which desktop an app is on. Needles to say, if you know your shortcuts, this method is also very efficient, & rapidly facilities app switching.

I like my simple setup. It works, as does yours for you, as a way to efficiently run and manage applications & services. TBH I don't spend a lot of time in the other virtual consoles, but I am happy to be able to drop to one from time to time, which - especially given their default keyboard shortcuts - is actually quite convenient.
An alternate virtual console makes a great dedicated, say, SSH screen, with its own baked in, dedicated key command to get there (whadda you know?), all with zero setup. I see this as offering more or less equivalent functionality to your doing something similar in a Screen instance on one of your virtual desktops - just another way to make violin stings, baby. And, in my defence, the VT way is built in, requires no set up & has its own dedicated key shortcut right out of the box (though I have regrettably disabled them). I see nothing inherently old fashioned (other than it being fashioned in old) about getting things done outside X, where X isn't required. It works. Indeed this rather weird arrangement is simply how Linux currently is - given the rather tacked on nature of the X display server. And this will all be moot with Wayland (I suppose) soon anyway.

You have actually worked around the problem, protecting yourself, but the problem is there nonetheless. And some of us do use our non X consoles, and so are potentially affected by this - depending on how we secure our machines post suspend.

I would even go as far as to say, what the hell are X lockers doing filling the need for screen lockers at all, when they do such an incomplete job.
I'm not arguing that the X locks aren't functioning as X locks, I'm arguing that they are not fit for purpose as screen locks at all. And yes, that's despite the fact that you use Screen :)

In writing this I have realised that should I have an X freeze I will no longer be able to drop to another VT for fixies. Not happy with this: superior locking solutions welcome.
...maybe I'll just use Screen & stop using the VTs...

Though I shouldn't have to, dammit!

bad apple <mr.meowski@xxxxxxxx> wrote:
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