linux-kernel - design of screen-locks for text-mode sessions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <d4f1333a0609110240n3904e5a9g4359c338004008ae@mail.gmail.com>
Date:	Mon, 11 Sep 2006 04:40:03 -0500
From:	"Travis H." <solinym@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: design of screen-locks for text-mode sessions

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/