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

[Serge Hallyn]

Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > Why not purely random?  I also liked the suggestion of putting the
> > password in a file under $lxcpath/$lxcname - though chmod 600 owned
> > by the calling user, not root.  I prefer not outputting it in
> > stdout during create, but am not *strongly* against it.
> 
> I'm actually largely against "purely random" passwords, particularly

Well by purely random I of course meant using a reasonable char set.
But I'm lazy and prefer to type (if I have to) 8 random chars to a bunch
of boilerplate including mylongcontainername...  And realistically, if
I'm not using ssh keys, and we have the pwd in a file, i'll be having a
script fetch the pwd from the file for me on login.

> when we're just trying to defeat a particular attack vector like this,
> especially when combined with expiring the password.  I'm not sure
> there's really anything significant left on the attack tree we need to
> worry about (especially with the current state of affairs) and purely
> random passwords are a significant PITA.  I think xkcd had it nailed
> here:
> 
> https://xkcd.com/936/

OTOH for most of the containers I create I'll log in at most once, so
memorable passwords are not useful.  Also your proposal still had some
random chars, so at least with my throwaway approach to containers 2 or
8 random chars makes no difference - I'll have to look it up.

But it sounds like we may want to be able to pass a password template,
i.e.  "lxc_${name}_XXX" (or if on private network then maybe "root")
into the template.

> I'm open to storing it in a file and, yeah, adding a chown 600 is fine.
> Raises and issue though that a number of these templates will only run
> as root and have not been adapted for running under a non-priv user.
> That's another discussion that I think you and I and others need to
> engage in.

Sadly some will never work as non-priv user.  Including 'ubuntu'.  At
least until we get an in-kernel workaround enabling user namespaces to
create some devices, which debootstrap insists on doing.

-serge