design of screen-locks for text-mode sessions

design of screen-locks for text-mode sessions

[Travis H.]

Howdy!

This may diverge away from kernelspace, and if so I'll take the discussion
off-list with interested parties.  In the meantime, I was wondering what people
thought about the best design for locking text-mode console sessions.  It's a
checkbox on some regulatory compliance list, I think for the PCI specs (that's
credit cards, not the bus) and I'm sort of surprised there isn't an easy-to-find
package for this.

If you think this belongs somewhere else, please recommend the location
to me.  One public response will be sufficient to let me know this is
inappropriate.
I know all the solutions might not be in kernelspace, but there are
some system-level interactions that require a deeper understanding of
kernel tty handling and login sequence than most lists can offer.

I'm thinking that the easiest solution might be an expect script that
sits between
mingetty and login, so it can learn the username and password, and later on
has a timeout that stops passing data to the spawned login/shell.  However,
what I worry about is the vagaries of signal handling and other tricks that
might be required to ensure that this solution isn't bypassed.  It
also is somewhat
unfriendly to non-conventional login methods (I assume there are many options
with PAM other than username/password).

Am I correct in assuming that login execs the shell, as opposed to
hanging around
after authentication?

To my mind, the solution would have these requirements:
Can detect keyboard inactivity in that console more than a configurable minimum.
Can't be bypassed.
Can require re-authentication after the inactivity timeout.

Nice-to-have:
Works with any authentication method.
Portable.
Userspace > LKM > kernel recompile
Few changes to a stock RHEL install required to make it happen.
-- 
"If you're not part of the solution, you're part of the precipitate."
Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

Re: design of screen-locks for text-mode sessions

[Alan Cox]

Ar Llu, 2006-09-11 am 04:40 -0500, ysgrifennodd Travis H.:
> off-list with interested parties.  In the meantime, I was wondering what people
> thought about the best design for locking text-mode console sessions.  It's a
> checkbox on some regulatory compliance list, I think for the PCI specs (that's
> credit cards, not the bus) and I'm sort of surprised there isn't an easy-to-find
> package for this.

We should have everything you need in kernel to do this. You can lock
the console switching and monitor the keyboard just fine. 

See "lockvt.c" (ask google to find it). It's tiny and it shows how to
use the lockswitch functionality. Then just add your timing junk.


Alan

Re: design of screen-locks for text-mode sessions

[Jan Engelhardt]

>
> This may diverge away from kernelspace, and if so I'll take the discussion
> off-list with interested parties.  In the meantime, I was wondering what people
> thought about the best design for locking text-mode console sessions.  It's a
> checkbox on some regulatory compliance list, I think for the PCI specs (that's
> credit cards, not the bus) and I'm sort of surprised there isn't an
> easy-to-find
> package for this.

screen. Start it. Hit ^A^X. Does not support autolocking though.

> Am I correct in assuming that login execs the shell, as opposed to
> hanging around
> after authentication?

Login waits for its subprocess to terminate. However, not every 'system' 
uses login, e.g. ssh.


Jan Engelhardt
-- 

Re: design of screen-locks for text-mode sessions

[Oleg Verych]

Hallo, Jan Engelhardt
who wrote:
> 
> screen. Start it. Hit ^A^X. Does not support autolocking though.
>
Wrong:

"idle N lockscreen" in your ~/.screenrc or in cmdline (C-a, C-z i have)

-- 
   5 years ago TT and WTC7 were assassinated.
   Official version violates Laws of Nature.
   <http://911research.com>

Re: design of screen-locks for text-mode sessions

[Jan Engelhardt]

>
> Hallo, Jan Engelhardt
> who wrote:
>> 
>> screen. Start it. Hit ^A^X. Does not support autolocking though.
>> 
> Wrong:
>
> "idle N lockscreen" in your ~/.screenrc or in cmdline (C-a, C-z i have)

But what password will it use if you have not set one before?


Jan Engelhardt
--