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.
CON=console
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; <><
Hey Rick,
ReplyDeleteYour blog wanted me to authenticate to post my comment. I'd prefer to just get down to it. harumph. :)
Where I work, we've got thousands of virtual machines. The vast majority of them have interfaces directly on our internal network, and we log in to them like any non-virtual host. We don't log in to the ESXi host first, THEN log in to the guest, we log directly into the guest. Probably for 99% of our VMs, your normal off-the-street sysadmin might be a little challenged to even know if the host was a VM or not.
Do you mean that in circumstances where access to the guest is only through previously mediated access to an outer host layer, removing all authentication makes sense, or do you mean that all VMs should have no authentication regardless of how you access them?
I remember, and actually recently cited to a coworker, those days back in the early nineties at Rice when we had robust Kerberos with very broad and tall acceptance in our infrastructure. Sadly, the coworker I told about this had no idea that Kerberos could ever be anything but some minor requirement for Windows Active Directory.
I think we'll have to agree to disagree that it might ever be justifiable to remove all authentication on physical consoles in data center machine rooms. I believe that all good approaches to system security must include resource access compartmentalization and reliable identity assurance. Even the most impenetrable black vault classified workplace has people with non-equal access, if they're not all doing exactly the same work. The stakeholders for the resources on those systems need to have some way of validating who accessed them and when.
Besides... I don't see that flying with PCI, SOX, HIPPA, FERPA or other such data security standards.
Now, past all that...
yes. Passwords are an irritating piece of drivel, and not as robust as we ought to be.
I literally cringe whenever I hear an ad for a public radio piece about a show where they found some geek to say that passwords are weak and shouldn't be used and that biometrics are the bomb, man. Biometrics are only "the bomb" if you consider the volume of security failures if we rely on them completely. The iPhone thumbprint sensor was compromised within about a week of its release.
Authentication is like birth control. The best approach is to use a condom + diaphragm + spermacide + birth control pill + iud. I would disagree that abstinence is the best policy in this analogy. I do think that given the current technology, some form of biometric element with a stress-sensing capability PLUS single-use passwords or PINS from a fob PLUS physically assigned and locked to a single host crypto keys PLUS a means of access that, once you're authenticated, completely tears down the connection and calls YOU back at your claimed IP to prevent IP spoofing might be a useable gold standard.
Did you hear the one about the mainframe user whose watch was ten minutes slow compared to the system clock? He logged in at what he thought was 15:00, the system said "USER VM3456 LOGIN AT 15:10" so he logged off and logged in ten minutes later only to get a message "USER VM3456 LOGIN AT 15:20". "Damn."