On Tue, Sep 17, 2013 at 8:01 AM, Miloslav Trmač <mitr@xxxxxxxx> wrote:
On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
> Meanwhile, in many systems today, local passwords are entirely unused.
> Authentication is done via keys or by kerberos.
>
> At the same time, we have an increased need for smaller systems. That 8MB
> starts to be a meaningful fraction of a container or an ultra-small cloud
> image
1) Is the "need for smaller systems" really such an issue? I've seen
quite a few such requests recently, and in almost all cases it seems
that just sharing the storage would solve all of these problems at
once, at a totally much lower cost than trying to shave a megabyte
here or there.
The use case for this is often IaaS/PaaS style cloud providing so you have many different clients so shjared storage probably isn't super safe, plus you have the clients creating and uploading their own images, often based off of the JEOS (Just Enough OS) images, so shared storage wouldn't help there. Fancy deduplication would help, but the blocks would need to be aligned/etc.
2) A typical "application separation container" should, IMHO, not even
have a password database used for management, let alone a login shell.
(Just launch a shell process and attach it into the container.) So,
in that case, the database should be removed, not made smaller. Right
now that would mean removing all of PAM, which is somewhat problematic
(if the application uses PAM to authenticate access to the
application.).
Well there's the world we should have, and the world we actually have. I'm still assigning a lot of CVE's for /tmp vulns, in 2013. /tmp vulns should not be a problem anymore, and yet programmers keep messing it up. Plus some people legitimately need logins/local passwords/etc, so to simply say "yeah to bad we don't support that" kind of sucks/isn't workable.
3) For both virtualization and virt-like containers that accept
authentication by "keys or kerberos", wouldn't it make most sense to
disable password authentication altogether, then?
See above answer.
If 1) is false, 2) and 3) suggest to me that this might be best solved
by packaging the "password creation/change functionality" as an
optional component (encompassing libpwquality+cracklib*+perhaps some
parts of PAM), installed by default in @core, that the ultra-small
setups could just remove (and if they were missing, creating/changing
passwords would have to fail).
How does one log into the image to make changes? not everyone will be able to easily manage/modify the JEOS images using tools, so again you just excluded a large chunk of people from using them. I think logging into an image via SSH is a pretty common feature/requirement and we should continue to support it.
As for reducing the dictionary size: Ideally, the dictionary would be
there only to protect against off-line attack when someone stole the
password file. (Note that such cases are _more_ likely in the cloud
paradigm, where all disk images are stored together.); for on-line
attacks there would be an efficient lockout mechanism, or at least
rate limiting. However we don't have either available by default due
to risk of a DoS.
Yup.
So, we _do_ rely on the strength of the password against on-line
brute-forcing. We even allow root to ssh in by default! In this
environment, allowing the user to use a slightly-obscure word that is
nevertheless certainly present in the attackers' dictionaries is
irresponsible.
At some level we need to start trusting the user to do the right thing, we can't bubble wrap the entire world. We also have to let the user do potentially dangerous things (like root logins) because again there are often legitimate requirements for this.
(Now, that might divert the topic into the separate discussion of ssh
enabled by default, but that's beside the point.)
Best as I can tell, the only reasonable practice for password use is:
* Have very few passwords that need to be remembered by a human. (For
the others, autogenerate something completely random and store them in
an encrypted keyring, within Firefox, the OS, or anywhere else.)
* Make those few passwords that need to be remembered rather strong,
with a good security margin.
Or do smart things like Google's 1 factor auth where logging in from a new device/IP triggers them to ask for additional info like your phone # you used when registering, etc. Not as easy with SSH though =(.
We don't have all the pieces to make such a password use really easy
(e.g. Firefox offering the user to generate new passwords) right now -
but making the dictionaries weaker does seem to go in the wrong
direction.
Mirek
I'm not sure having the dictionaries at all really helps, and the people using JEOS are (hopfully) a bit more clued in than the average user who pops a Linux CD into the laptop to install and see what it's all about =). I do know that having the ability to SSH in and tweak things is pretty critical.
On Fri, Sep 6, 2013 at 3:04 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
> The cracklib dicts in Fedora is 8.3M. (I'm sure some of this is my fault, as
> I've added to it over the years.) The cracklib pam module supports a
> compressed dictionary, but apparently it has a serious performance impact
> (https://bugzilla.redhat.com/show_bug.cgi?id=1004896).
>
> Meanwhile, in many systems today, local passwords are entirely unused.
> Authentication is done via keys or by kerberos.
>
> At the same time, we have an increased need for smaller systems. That 8MB
> starts to be a meaningful fraction of a container or an ultra-small cloud
> image.
>
> I do recognize the value of protecting against dictionary-based attacks when
> passwords are used. Maybe we could have a policy which requires _longer_
> passwords but uses a much smaller dictionary?
>
> --
> Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm@xxxxxxxxxxxxxxxxx>
> --
> security mailing list
> security@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/security
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
Kurt Seifried
kurt@xxxxxxxxxxxx
-- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
