Wednesday, November 6, 2013

Console - Lose the Password, Reap Better Security

Console - Lose the Password, Reap Better Security

Often, that which seems contrary to what we want is really the best way to get it. 

No More Passwords

You may have heard talk about being more secure by not using passwords.  Specifically, if we use means other than traditional password access then the target systems and services may be better defended.  In English, using a PKI certificate, an SSH key, or some other form of credentials is typically more secure than ye olde username/password pair.

I agree with this view. 
For many of my systems, there is no password. 
I don't mean simply that the password is unknown.  I certainly don't mean that the password is blank.  What I'm saying is that there is no usable password.  Anything typed in will fail.  To access these boxes, the user (typically moi) must take one of the other routes. 
It works. 

Unusable Passwords

A quick way to render root's password unusable is to code an asterisk in the password field (either /etc/passwd then 'pwconv' or /etc/shadow directly).  This is the norm for service accounts (bin, daemon, mail, nobody, ftp).  Best practice is to employ 'sudo' for all root work.  Sign on as yourself (with SSH or whatever), then 'sudo' as needed.  There's an audit trail.  How novel. 

So ... you don't really need a root password anyway, now do you? 

But I propose something even more radical. 

I wear the sysadmin hat daily.  Whether for development or for hobby and home, I get to play "root".  (Some of us actually enjoy this, in small doses.) 

Virtualization is virtually everywhere.  Cool! 
But one of the most annoying things about virtualization is the double-signon effect.  In my sysadmin mode, I get confronted with this regularly.  I'm signed onto the host, but the guest throws a password prompt.  [sigh]  Not surprising; makes sense; but is in the way of real work. 

It's worse than "in the way", more than a hassle.  For the guest to process your secondary sign-on, it must have ... drum roll ... a password.  Now wait just a minute.  We're trying to do away with passwords!!  Those of us trying to evolve beyond passwords find this situation positively primordial.  (a prime ordeal)  What to do?? 

No More Login

The modest proposal:  throw a shell on the guest console directly. 

Shocked?  You should be.  (Unless you've heard it before.) 

It's not a new idea.  Some of us have been recommending this for several years.  Do this in concert with unusable passwords.  Replace 'getty' with a shell.  (The security guys usually don't "get it" about the nature of 'getty' so they throw a hissy fit and we sysadmins are forced to acquiesce.)  But it's a good idea, and in the long run more secure (for virtual consoles) than a login prompt. 

With an operational shell, not a login prompt, you get immediately to work.  There is no fumbling around at the guest console.  There is no password to be concerned about.

I wish the security guys (or any objectors) would follow this line of reasoning.  Someone accessing a virtual console has already been vetted by the host.  Someone with control of a guest (even if a password prompt is in effect) can do so much more, whether good or bad.  So if they #1 have been verified and #2 are in a position to completely re-image the guest, then a no-login-required shell is perfectly reasonable.  Combine that with the unusable passwords trick and your virtual systems are hardened on one more front. 

Depending on the physical security of your data center, this crazy concept might be a good idea for physical consoles too.  The security issue is the same: you're sitting in front of a physical machine with full ability to reboot, re-image, anything.  We presume that your data center is not the public library, where password-protected consoles still make sense even though operators freely Ctrl-Alt-Del.  Results not typical.  Use with caution.  Your mileage may vary.  Do not fold, spindle or mutilate.  And I am not a lawyer.

If your shop is small, then you may *be* the security guy.  You could schedule a meeting with yourself, discuss the pros and cons, and convince yourself that this is in fact a good idea.  (But talking to yourself is a red flag for anyone in that role.) 

For Example

For most of my guest systems, I replace 'getty' with a no-login-required script of some sort.  The contents of /sbin/conshell are roughly as follows. 

if [ ! -z "$1" ] ; then CON="$1" ; fi
if [ "$CON" = `basename $CON` ] ; then CON=/dev/$CON ; fi
PS1='\$ ' ; export PS1
exec sh -i 0<$CON 1>$CON 2>$CON

Yeah yeah ... there are spiffier ways to code the conditionals.  (Where is Jon Miller when I need him?)  I've left this as-is because it works on a wide range of shells.

Thanks for reading.  Stay safe.

-- R; <><