Re: [libvirt PATCH 0/2] docs: less docs for insecure SASL mechanisms

2021-03-08 Thread Daniel P . Berrangé
On Mon, Mar 08, 2021 at 12:00:03PM +0100, Erik Skultety wrote:
> On Mon, Mar 08, 2021 at 10:41:55AM +, Daniel P. Berrangé wrote:
> > On Fri, Mar 05, 2021 at 08:02:49AM +0100, Erik Skultety wrote:
> > > On Thu, Mar 04, 2021 at 06:10:11PM +, Daniel P. Berrangé wrote:
> > > > GSSAPI and SCRAM-SHA-256 are the only two SASL mechanisms we
> > > > especially want people to be using. Even the latter is a little
> > > > questionable due to storing passwords in cleartext on the server.
> > > 
> > > At what point of the SCRAM-SHA-256 auth process is password handled as 
> > > clear
> > > text? I mean I tried to look up the issue you mention and couldn't find
> > > anything, quite the contrary, e.g. Postgres says SCRAM-SHA-256 is the only
> > > recommended scheme for password-based auth and storing passwords in clear 
> > > text
> > > is not possible. Isn't it kind of the point that passwords are never 
> > > stored in
> > > clear text with this scheme?
> > 
> > You can clearly see the passwd in clear text in the file
> > 
> > Add a new user
> > 
> >   $ echo "fish food" | saslpasswd2 -a libvirt demo
> > 
> > Look for the password:
> > 
> >   $ strings /etc/libvirt/passwd.db  | grep fish
> >   fish food
> > 
> > The actual mechanism protocol does send in clear text over the wire.
> > The storage in clear text on the server side is simply a choice of the
> > cyrus-sasl impl of this mechanism documented here:
> > 
> >   https://www.cyrusimap.org/sasl/sasl/faqs/plaintextpasswords.html
> 
> So if this is the case, why are we even bothering promoting an insecure
> solution, why not promote only GSSAPI for the reasons given? Backcompat?

Calling it insecure is a rather absolutist view of security IMHO.

It *is* secure against network attackers, which is the primary risk
factor we're protecting against with our use of SASL.

To compromise the passwords requires the attacker to first compromise
the root account on the virt host. Anything is possible, but IMHO that
danger doesn't justify eliminating the SCRAM auth mechanism.

If we only promote GSSAPI, then the result is likely to be that people
run with no authentication at all, or make their own ill informed worse
choices.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



Re: [libvirt PATCH 0/2] docs: less docs for insecure SASL mechanisms

2021-03-08 Thread Erik Skultety
On Mon, Mar 08, 2021 at 10:41:55AM +, Daniel P. Berrangé wrote:
> On Fri, Mar 05, 2021 at 08:02:49AM +0100, Erik Skultety wrote:
> > On Thu, Mar 04, 2021 at 06:10:11PM +, Daniel P. Berrangé wrote:
> > > GSSAPI and SCRAM-SHA-256 are the only two SASL mechanisms we
> > > especially want people to be using. Even the latter is a little
> > > questionable due to storing passwords in cleartext on the server.
> > 
> > At what point of the SCRAM-SHA-256 auth process is password handled as clear
> > text? I mean I tried to look up the issue you mention and couldn't find
> > anything, quite the contrary, e.g. Postgres says SCRAM-SHA-256 is the only
> > recommended scheme for password-based auth and storing passwords in clear 
> > text
> > is not possible. Isn't it kind of the point that passwords are never stored 
> > in
> > clear text with this scheme?
> 
> You can clearly see the passwd in clear text in the file
> 
> Add a new user
> 
>   $ echo "fish food" | saslpasswd2 -a libvirt demo
> 
> Look for the password:
> 
>   $ strings /etc/libvirt/passwd.db  | grep fish
>   fish food
> 
> The actual mechanism protocol does send in clear text over the wire.
> The storage in clear text on the server side is simply a choice of the
> cyrus-sasl impl of this mechanism documented here:
> 
>   https://www.cyrusimap.org/sasl/sasl/faqs/plaintextpasswords.html

So if this is the case, why are we even bothering promoting an insecure
solution, why not promote only GSSAPI for the reasons given? Backcompat?

Erik



Re: [libvirt PATCH 0/2] docs: less docs for insecure SASL mechanisms

2021-03-08 Thread Daniel P . Berrangé
On Fri, Mar 05, 2021 at 08:02:49AM +0100, Erik Skultety wrote:
> On Thu, Mar 04, 2021 at 06:10:11PM +, Daniel P. Berrangé wrote:
> > GSSAPI and SCRAM-SHA-256 are the only two SASL mechanisms we
> > especially want people to be using. Even the latter is a little
> > questionable due to storing passwords in cleartext on the server.
> 
> At what point of the SCRAM-SHA-256 auth process is password handled as clear
> text? I mean I tried to look up the issue you mention and couldn't find
> anything, quite the contrary, e.g. Postgres says SCRAM-SHA-256 is the only
> recommended scheme for password-based auth and storing passwords in clear text
> is not possible. Isn't it kind of the point that passwords are never stored in
> clear text with this scheme?

You can clearly see the passwd in clear text in the file

Add a new user

  $ echo "fish food" | saslpasswd2 -a libvirt demo

Look for the password:

  $ strings /etc/libvirt/passwd.db  | grep fish
  fish food

The actual mechanism protocol does send in clear text over the wire.
The storage in clear text on the server side is simply a choice of the
cyrus-sasl impl of this mechanism documented here:

  https://www.cyrusimap.org/sasl/sasl/faqs/plaintextpasswords.html



Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



Re: [libvirt PATCH 0/2] docs: less docs for insecure SASL mechanisms

2021-03-04 Thread Erik Skultety
On Thu, Mar 04, 2021 at 06:10:11PM +, Daniel P. Berrangé wrote:
> GSSAPI and SCRAM-SHA-256 are the only two SASL mechanisms we
> especially want people to be using. Even the latter is a little
> questionable due to storing passwords in cleartext on the server.

At what point of the SCRAM-SHA-256 auth process is password handled as clear
text? I mean I tried to look up the issue you mention and couldn't find
anything, quite the contrary, e.g. Postgres says SCRAM-SHA-256 is the only
recommended scheme for password-based auth and storing passwords in clear text
is not possible. Isn't it kind of the point that passwords are never stored in
clear text with this scheme?

https://www.postgresql.org/docs/13/auth-password.html

Erik



[libvirt PATCH 0/2] docs: less docs for insecure SASL mechanisms

2021-03-04 Thread Daniel P . Berrangé
GSSAPI and SCRAM-SHA-256 are the only two SASL mechanisms we
especially want people to be using. Even the latter is a little
questionable due to storing passwords in cleartext on the server.

Daniel P. Berrangé (2):
  docs: convert auth page into RST format
  docs: stop mentioning insecure / broken SASL mechanisms

 docs/auth.html.in| 368 ---
 docs/auth.rst| 323 ++
 docs/meson.build |   2 +-
 src/remote/libvirtd.sasl |  11 +-
 4 files changed, 330 insertions(+), 374 deletions(-)
 delete mode 100644 docs/auth.html.in
 create mode 100644 docs/auth.rst

-- 
2.29.2