[lxc-devel] Strawman proposal... Default passwords in templates...

[Michael H. Warfield]

On Thu, 2013-12-26 at 13:02 -0500, Dwight Engen wrote: 
> On Wed, 25 Dec 2013 18:54:57 -0500
> "Michael H. Warfield" <mhw at WittsEnd.com> wrote:
> 
> > [Holiday is mostly over...  Most of the family has departed to their
> > homes or other homes.  Grandpa lays back to a late nap - errr -
> > E-Mail...]
> > 
> > Ok all,
> > 
> > Serge and Stéphane know my background as a security researcher and
> > expert.  This has been something that has been bothering me for some
> > time and I think it's time for some serious discussion.
> > 
> > The current container templates create templates with horrible bad
> > passwords.  Fedora, CentOS, and others create the "root" account with
> > the password "root".  Ubuntu creates the user "ubuntu" with the
> > password "ubuntu" with su / sudo authority to superuser.  There are
> > other static conventions.  All are bad bad BAD!

> I agree that using known, weak default passwords is asking for trouble
> and I think your suggestions are a big improvement. Some of the
> usability problems could be overcome if we would standardize that all
> templates support ssh authorized_keys injection (ala what the ubuntu
> template already can do) but maybe we should look at what cloud-init
> does as well for comparison.

I think that's a good idea too and I considered it but...  I remembered
that I had to add the ssh server package into the templates and ssh may
not be the only mechanism nor might all the mechanisms be installed by
the template and be caught for modification...

What if someone adds in (gag) telnetd or any of the various ftp servers?
I restrict most of my systems (other than the honeypots) to ssh
authorized keys only but that doesn't cover the whole range,
unfortunately.  Then, from a template standpoint, we're stuck with
whatever gets installed after the container creation which we can't do
anything about.

I like the authorized_keys idea as an "in addition to" hardening the
passwords.

Someone on the users list also suggested setting the password as
expired, as well, forcing the user to change it the first time.  That's
a good idea and I'm adding that as well.

Couple of other good ideas could be to restrict remote root logins
and /etc/securetty (but then there's ubuntu/ubuntu in those
containers)...  I'm not adding those in but they're a thought.

I think the templates could also use some options to add addition users,
optionally in the admin / wheel groups but I'm still just chewing on how
I might do that.

[[ SNIP ]]

> > What I propose to do is to change the Fedora and CentOS templates to
> > conform to the following convention...  Default root password as
> > follows:

> > Root-${Container_Name}-${RANDOM}

> > Note: Contains one capital, multiple numbers, plus punctuation.

And adding setting it to be "expired."

> > Add a warning that the user should change it to a user selected
> > password.  Include instructions on how to change it from the host
> > using chroot.

> > If they fail to note it down, it can always be changed with a "chroot
> > {rootfs} ; chpasswd" so there's little loss of control.
> > 
> > Is it secure?  Not really, but security is a process, not a state.
> > 
> > Is it more secure than the current state?  Most definitely.
> > 
> > Is it more of a problem for administrators of the host system?  Yes,
> > but only trivially so.  It's a PITA to enter but is readily changed
> > from the container or the host and vastly more secure than the lame
> > passwords we're using now.
> > 
> > It's not "bad" and highly unlikely to be busted by simple brute force.
> > Without the attackers having internal knowledge of the container name,
> > their attack surface is pretty large.  With that knowledge, the
> > profile is still over a /16 surface (65536 guesses) from the
> > ${RANDOM} variable.
> > 
> > I intend to implement this in the templates I'm working on.  I would
> > love to hear comments and suggestions from everyone else.  I would
> > definitely want to see something better in 1.0.  Doesn't have to be
> > this, but someone needs to come up with something better.
> > 
> > Regards,
> > Mike

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20131226/2ebcecc3/attachment.pgp>