[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 20/08/13 22:47, Migel Wimtore wrote:
> 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!
That's a good, solid reply :]
Starting at the end, I was going to cheekily add: "well, like it or not
chief you've just ended up in my camp anyway haven't you, as you've
disabled your VTs now!"
I think Simon's excellent suggestion of vlock is probably *exactly* what
you need - you can lock some or all of your VTs simultaneously and even
lock the VTs from within X with --new. Looks like a perfect fit for you.
Just to make things clear, I'm already fully aware that I usually come
across as very dictatorial and didactic but unless I specifically say
so, I never expect anyone to actually do what I say*. Read my advice,
yes, and act on it if they feel like it, but nothing more. I wouldn't
dream of dictating your workflow to you and you've obviously got a
pretty neat, very well customised setup that I'd bet you're highly
efficient on. The funny thing to me is that in this case, you're
struggling to remedy a problem of your own making. Everything in the
linux stack is working exactly as expected - you haven't customised your
VT setup through kernel config or altering /etc/inittab so as you say,
you'd expect default ctrl+alt+Fx behaviour. So far, so good. But why
would you expect higher level X to effect VT switching at all? Of course
a locked X isn't going to stop ctrl+alt+Fx - how do you think your
favourite trick of recovering a knackered X session by dropping to a
different VT would work if it was left to X to intercept your key
strokes and handle all the stuff below itself (like VT locking)?
Obviously it wouldn't. The problem is, you want to secure an unsecured
session. You can now trivially do that with vlock for example. But
otherwise the obvious fix is so, so, *soooo* simple - don't leave an
insecure VT session logged in, and then leave your machine. This is just
jaw-droppingly obvious to me, sorry. Suspend/resume is also a car crash
as far as I'm concerned - if security matters to you, don't use it.
Simple. Especially don't suspend your machine, again with unsecured VTs
running and then leave it where anyone can wake it up with keyboard
access. Duh!
I also think you're missing out by not adopting screen - you've even
looked into it. I will happily admit to using a VT myself sometimes -
normally however, I'd start one up on ctrl+alt+F1, log in *and
immediately start screen*. Then, as you say, I've got a pretty handy
spare full screen terminal I can switch to for watching wget/rsync
progress, compile jobs, ssh sessions. The advantage is I can recover
crashed sessions, configure a .screenrc full of awesome shortcuts
(analogous to your wmscript), cycle between multiple running screens
remotely and locally on the same head, etc, etc. Of course, I can also
do this in a normal desktop terminal window, and usually do. The killer
function is the detach/reattach behaviour and that's lower level than
your VT recovery technique. A box can completely lock up it's gfx stack,
stop responding to any keyboard input except SysRq and even drop the
monitor output, but very frequently it will still be running and ssh
will still be up. ssh in, reattach your still running screen with all
your jobs in it, exit gracefully, reboot and fix. Ta dah.
Screen is also super-simple, available on literally every OS version
ever and doesn't require any other setup on Linux particularly except
installing it via apt/yum/zypper/whatever. That's it. You'll need very
few of it's complex options - spawning new screen instances (ctrl+a, c),
switching through them (ctrl+a, n), detaching (ctrl+a, d) and attaching
(launch with screen -x) are all you need really. Oh, on a host you've
just signed into you'd scan for any running screen instances with
"screen -list", and then attach the one you want. That really is it.
What I will grant you is that for the definite power users (like you),
an optionally installable component would be a nice addition: it would
monitor for active VTs, and then depending on whether you'd echoed 1 or
0 to either an /etc config file or a /proc entry, also locked any and
all active VTs, vlock style. The first time this situation occurs, X
could even prompt you with a brief description of the issue and an offer
to initially enable/disable it. This would prevent it being yet another
confusing option presented to basic users ("wtf is a VT? Mum! Help!" and
only being shown to advanced users who were both tampering with VTs and
who had installed the optional 'super-locker'.
Can you code at all? Maybe you should write it! I'd certainly test it.
Regards
* Sometimes I really am just laying down the law, but that's unusual and
has to be confined to when I know full well I'm 100% right - and that's
not nearly as often as I'd like
--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq