Re: Bigger annoyance with locking.

[Dan Mahoney, System Admin]

On Fri, 14 Nov 2008, Trent W. Buck wrote:

> "Dan Mahoney, System Admin"
> <address@hidden> writes:
>
> > The question comes up: "if I can get at your uid, why do I need your
> > screen?"
>
> In order to observe the output when I run "gpg -d" on an encrypted,
> confidential file.  Simply having my login password would not grant
> access to GPG encrypted files.
>
> In order to observe the output of commands run on a remote host via
> ssh.  Simply having my login password would not grant access to the
> remote host.
>
> If I leave ssh running inside the screen session, to actively modify the
> remote host (e.g. installing your own public identity in the remote
> authorized_keys file).

Right -- I had meant to answer those questions but the email was getting 
rather long-in-the tooth already.  By answering them for me, you've proven 
that you "get it". :)

> Similarly for other systems that require secondary passwords, such as a
> remote IMAP server or a remote web application.
>
> > Sadly, even though I am root on the systems involved -- the tweak we
> > really need here is extending screen's builtin lock to support the
> > password stored in .screenrc
>
> Clearly I don't know what you're talking about, because what I *thought*
> you were talking about works as you ask for.
>
> Namely, I run :password interactively to generate a hashed password in
> the default register.  I use C-a ] to paste it into .screenrc, as in
>
>    password ASDFASDFASDF

Yes, and it's used as a password on screen-reattach.  Not when screen is 
locked.

I would like screen's built-in-lock to use that same password.

> Later, in either the current or a new screen session, I run
> :lockscreen.  It blanks the screen, changing it to
>
>    Screen used by Trent W. Buck <twb>
>    Password:
>    Screen password:
>
> The first prompt is for my login password.  The second prompt is for my
> screen password.

Exactly, it's asking for your login password.  Probably gotten via a call 
to getpwnam.

Yes, and on my system, my passwd field in /etc/master.passwd is "*".  If I 
do a ctrl-a-x, I get:

Key:
Again:
Screen used by Dan Mahoney <dmahoney>.
Password:

This is screen's builtin.  Once I set that "key" there's no way to change 
it within that "attachment".  Nor from what I can tell is there any way to 
set it without manually trying to lock your screen and getting whatever 
one gets on a failed password read.

To confirm, I'm not calling /bin/lock, which instead looks like 
this:

%/usr/bin/lock
Key:
Again:
lock: /dev/ttyp6 on xxxxxxxxxx. timeout in 15 minutes.
time now is Fri Nov 14 00:55:22 UTC 2008
Key:

> >  -- otherwise it's a whole new pam
> > facility -- and PS, incidentally, pam doesn't have an easy way to say
> > "use the password in this file."
>
>    echo password ASDFASDFASDF >~/.screenrc.secret
>    echo source ~/.screerc.secret >>~/.screenrc

And which PAM module would that use?  Which facility, for that matter?

And Micah, we really at the point where you're thinking of linking against 
something as OS-specific as libpam (which varies widely from, say, Linux 
to BSD to Solaris)...when "just read the (or a different) password in 
.screenrc and use it for locking as well as on attachment" is a few lines 
of code that already exist?

the code already exists to generate a crypted password, and to compare it 
to the one in the file.  The only thing you'd REALLY need is a knob that 
says "use the shell password, via getpwnam -- or "use the password in 
.screenrc" for locking.  Re-attachment behavior would remain unchanged.

Given, there is a contention here -- two possibly separate passwords that 
you may have to enter twice.  I might also suggest that there be some way 
(ala pam's try_first_password) to pass the same password you've used on 
"unlock" to the reattach function -- and if it doesn't work, have the 
reattach function re-prompt, instead of existing immediately.

Given, that requires more engineering (i.e. having screen prompt for an 
attach password multiple times) and such, the rest is simple.

-Dan Mahoney

--

"It's three o'clock in the morning.  It's too late for 'oops'.  After
Locate Updates, don't even go there."

-Paul Baecker
 January 3, 2k
 Indeed, sometime after 3AM

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------