| 2022-08-28 20:39:34 |
rdratlos |
bug |
|
|
added bug |
| 2022-08-30 01:50:29 |
Bryce Harrington |
tags |
|
server-todo |
|
| 2022-08-31 15:21:00 |
Bryce Harrington |
bug |
|
|
added subscriber Ubuntu Server |
| 2022-08-31 18:09:40 |
Sergio Durigan Junior |
bug |
|
|
added subscriber Sergio Durigan Junior |
| 2022-09-05 09:35:00 |
rdratlos |
attachment added |
|
Enable SCRAM for SASL binding https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1987992/+attachment/5613735/+files/autofs-5.1.8-support-SCRAM-for-SASL-binding.patch |
|
| 2022-09-05 12:27:02 |
Ubuntu Foundations Team Bug Bot |
tags |
server-todo |
patch server-todo |
|
| 2022-09-05 12:27:11 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2022-09-11 15:45:21 |
rdratlos |
attachment added |
|
0001-autofs-5.1.8-support-SCRAM-for-SASL-binding.patch https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1987992/+attachment/5615070/+files/0001-autofs-5.1.8-support-SCRAM-for-SASL-binding.patch |
|
| 2022-09-11 15:48:11 |
rdratlos |
attachment added |
|
0002-autofs-5.1.8-ldap_sasl_interactive_bind-needs-creden.patch https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1987992/+attachment/5615071/+files/0002-autofs-5.1.8-ldap_sasl_interactive_bind-needs-creden.patch |
|
| 2022-09-12 00:43:03 |
rdratlos |
attachment added |
|
0002-autofs-5.1.8-ldap_sasl_interactive_bind-needs-creden.patch https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1987992/+attachment/5615168/+files/0002-autofs-5.1.8-ldap_sasl_interactive_bind-needs-creden.patch |
|
| 2022-09-12 01:40:25 |
rdratlos |
bug watch added |
|
mailto:autofs@vger.kernel.org |
|
| 2022-09-12 01:40:25 |
rdratlos |
bug task added |
|
autofs |
|
| 2022-11-23 16:17:50 |
Andreas Hasenack |
autofs (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2023-05-10 16:54:27 |
Andreas Hasenack |
autofs (Ubuntu): status |
New |
Triaged |
|
| 2023-05-15 13:23:10 |
Andreas Hasenack |
autofs (Ubuntu): status |
Triaged |
In Progress |
|
| 2023-05-31 17:44:34 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/443903 |
|
| 2023-06-08 22:42:28 |
Launchpad Janitor |
autofs (Ubuntu): status |
In Progress |
Fix Released |
|
| 2023-06-12 20:54:26 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/444587 |
|
| 2023-06-12 21:03:02 |
Andreas Hasenack |
merge proposal unlinked |
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/444587 |
|
|
| 2023-06-12 21:05:06 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/444587 |
|
| 2023-06-12 21:07:02 |
Andreas Hasenack |
merge proposal unlinked |
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/444587 |
|
|
| 2023-06-13 14:37:57 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/444650 |
|
| 2023-06-13 14:42:25 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/444651 |
|
| 2023-06-13 14:42:50 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/444652 |
|
| 2023-06-13 17:53:58 |
Andreas Hasenack |
description |
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-06-13 18:23:46 |
Andreas Hasenack |
description |
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- digest-md5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text algorithms: need transport layer encryption
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but cannot be currently used in autofs.
This update adds support for SCRAM and a DEP8 test to exercise it.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-06-13 18:37:23 |
Andreas Hasenack |
description |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- digest-md5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text algorithms: need transport layer encryption
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but cannot be currently used in autofs.
This update adds support for SCRAM and a DEP8 test to exercise it.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- digest-md5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text algorithms: need transport layer encryption
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-06-13 18:38:07 |
Andreas Hasenack |
description |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- digest-md5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text algorithms: need transport layer encryption
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- digest-md5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-06-13 18:45:20 |
Andreas Hasenack |
description |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- digest-md5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- digest-md5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs
- a network filesystem to properly test autofs
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-06-13 18:46:10 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-06-13 18:46:10 |
Andreas Hasenack |
bug task added |
|
autofs (Ubuntu Jammy) |
|
| 2023-06-13 18:46:10 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Kinetic |
|
| 2023-06-13 18:46:10 |
Andreas Hasenack |
bug task added |
|
autofs (Ubuntu Kinetic) |
|
| 2023-06-13 18:46:10 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-06-13 18:46:10 |
Andreas Hasenack |
bug task added |
|
autofs (Ubuntu Lunar) |
|
| 2023-06-13 18:46:17 |
Andreas Hasenack |
autofs (Ubuntu Jammy): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2023-06-13 18:46:21 |
Andreas Hasenack |
autofs (Ubuntu Kinetic): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2023-06-13 18:46:23 |
Andreas Hasenack |
autofs (Ubuntu Lunar): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2023-06-13 18:46:26 |
Andreas Hasenack |
autofs (Ubuntu Jammy): status |
New |
In Progress |
|
| 2023-06-13 18:46:28 |
Andreas Hasenack |
autofs (Ubuntu Kinetic): status |
New |
In Progress |
|
| 2023-06-13 18:46:30 |
Andreas Hasenack |
autofs (Ubuntu Lunar): status |
New |
In Progress |
|
| 2023-06-13 18:46:57 |
Andreas Hasenack |
description |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- digest-md5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs
- a network filesystem to properly test autofs
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs
- a network filesystem to properly test autofs
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-06-13 18:53:23 |
Andreas Hasenack |
description |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs
- a network filesystem to properly test autofs
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs
- a network filesystem to properly test autofs
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
It's important to not analyse this fix here in isolation. There is another fix part of this upload which changes the way SASL authentication is handled: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1984073
It does not change how SCRAM would be enabled in autofs, but the code path becomes very different in the end.
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-06-13 19:01:36 |
Andreas Hasenack |
description |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs
- a network filesystem to properly test autofs
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
It's important to not analyse this fix here in isolation. There is another fix part of this upload which changes the way SASL authentication is handled: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1984073
It does not change how SCRAM would be enabled in autofs, but the code path becomes very different in the end.
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs
- a network filesystem to properly test autofs
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
[ Other Info ]
It's important to not analyse this fix here in isolation. There is another fix part of this upload which changes the way SASL authentication is handled: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1984073
It does not change how SCRAM would be enabled in autofs, but the code path becomes very different in the end.
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-06-13 19:02:13 |
Andreas Hasenack |
description |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs
- a network filesystem to properly test autofs
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
[ Other Info ]
It's important to not analyse this fix here in isolation. There is another fix part of this upload which changes the way SASL authentication is handled: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1984073
It does not change how SCRAM would be enabled in autofs, but the code path becomes very different in the end.
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs configured to fetch automount maps from that ldap server, using SASL authentication
- a network filesystem to properly test that autofs is using the fetched map to mount the filesystem
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
[ Other Info ]
It's important to not analyse this fix here in isolation. There is another fix part of this upload which changes the way SASL authentication is handled: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1984073
It does not change how SCRAM would be enabled in autofs, but the code path becomes very different in the end.
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-07-26 14:49:45 |
Robie Basak |
description |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs configured to fetch automount maps from that ldap server, using SASL authentication
- a network filesystem to properly test that autofs is using the fetched map to mount the filesystem
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
[ Other Info ]
It's important to not analyse this fix here in isolation. There is another fix part of this upload which changes the way SASL authentication is handled: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1984073
It does not change how SCRAM would be enabled in autofs, but the code path becomes very different in the end.
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[racb] SRU justification for what appears to be a new feature: without SCRAM support, we would have no reasonable recommended authentication left, except for Kerberos which would be an unreasonable ask for users who don't already have Kerberos infrastructure.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs configured to fetch automount maps from that ldap server, using SASL authentication
- a network filesystem to properly test that autofs is using the fetched map to mount the filesystem
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
[ Other Info ]
It's important to not analyse this fix here in isolation. There is another fix part of this upload which changes the way SASL authentication is handled: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1984073
It does not change how SCRAM would be enabled in autofs, but the code path becomes very different in the end.
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-07-26 15:43:15 |
Ubuntu Archive Robot |
bug |
|
|
added subscriber Andreas Hasenack |
| 2023-07-26 16:40:49 |
Andreas Hasenack |
description |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[racb] SRU justification for what appears to be a new feature: without SCRAM support, we would have no reasonable recommended authentication left, except for Kerberos which would be an unreasonable ask for users who don't already have Kerberos infrastructure.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs configured to fetch automount maps from that ldap server, using SASL authentication
- a network filesystem to properly test that autofs is using the fetched map to mount the filesystem
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
[ Other Info ]
It's important to not analyse this fix here in isolation. There is another fix part of this upload which changes the way SASL authentication is handled: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1984073
It does not change how SCRAM would be enabled in autofs, but the code path becomes very different in the end.
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[racb] SRU justification for what appears to be a new feature: without SCRAM support, we would have no reasonable recommended authentication left, except for Kerberos which would be an unreasonable ask for users who don't already have Kerberos infrastructure.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs configured to fetch automount maps from that ldap server, using SASL authentication
- a network filesystem to properly test that autofs is using the fetched map to mount the filesystem
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
[ Other Info ]
These two paragraphs below only applied while I was considering fixing #1984073 together with this bug here. THAT IS NO LONGER THE CASE: only this bug, SCRAM, is being fixed now, and #1984073 is marked as won't fix/opinion for the SRU case.
No longer applicable, but left here for history:
"""
It's important to not analyse this fix here in isolation. There is another fix part of this upload which changes the way SASL authentication is handled: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1984073
It does not change how SCRAM would be enabled in autofs, but the code path becomes very different in the end.
"""
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-07-26 16:42:24 |
Andreas Hasenack |
description |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[racb] SRU justification for what appears to be a new feature: without SCRAM support, we would have no reasonable recommended authentication left, except for Kerberos which would be an unreasonable ask for users who don't already have Kerberos infrastructure.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs configured to fetch automount maps from that ldap server, using SASL authentication
- a network filesystem to properly test that autofs is using the fetched map to mount the filesystem
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
[ Other Info ]
These two paragraphs below only applied while I was considering fixing #1984073 together with this bug here. THAT IS NO LONGER THE CASE: only this bug, SCRAM, is being fixed now, and #1984073 is marked as won't fix/opinion for the SRU case.
No longer applicable, but left here for history:
"""
It's important to not analyse this fix here in isolation. There is another fix part of this upload which changes the way SASL authentication is handled: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1984073
It does not change how SCRAM would be enabled in autofs, but the code path becomes very different in the end.
"""
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
[ Impact ]
autofs currently lacks support for the SCRAM SASL mechanism. The available options are:
- DIGEST-MD5: obsoleted by https://www.rfc-editor.org/rfc/rfc6331.html
- GSSAPI mechanisms: more complex to setup (kerberos-based)
- plain text mechanisms: the usual "password is sent in cleartext over the wire" mechanisms
SCRAM, defined in https://www.rfc-editor.org/rfc/rfc5802, is available in the cyrus-sasl2 library shipped in Ubuntu, but autofs lacks the fix presented here to be able to use it.
This update adds support for SCRAM and a DEP8 test to exercise this mechanism and many others.
[racb] SRU justification for what appears to be a new feature: without SCRAM support, we would have no reasonable recommended authentication left, except for Kerberos which would be an unreasonable ask for users who don't already have Kerberos infrastructure.
[ Test Plan ]
The test plan requires setting up:
- an ldap server that supports SASL SCRAM
- autofs configured to fetch automount maps from that ldap server, using SASL authentication
- a network filesystem to properly test that autofs is using the fetched map to mount the filesystem
This can be a bit involved, and I provide with this update a DEP8 test that sets up the above, and exercises SASL SCRAM and many other SASL mechanisms:
- DIGEST-MD5
- SCRAM-SHA-*
- GSSAPI and GSS-SPNEGO
- NTLM and CRAM-MD5 (see bug #2023595)
In all cases, the automount map is stored in openldap, configured via ACLs to require the specific SASL authentication to access the map information.
The verification of this bug shall be completed if all the autofs DEP8 tests succeed. This will have verified the specific fix for this bug, as well as the "normal" autofs behavior via the other tests.
[ Where problems could occur ]
In terms of behavior, what will change now is that SCRAM-* authentication will work, as long as the credentials are correct.
Some scenarios I can think of:
- credentials were always correct, but due to the bug, the authentication always failed. After the udpate, the authentication will succeed, and different ACLs might apply to the connection on the server side.
- credentials were always INCORRECT, but due to the bug, coupled with ACLs on the server that allowed anonymous searches, the user was unaware of this fact. After the update, the authentication will still fail, and searches will keep working, but now the failure is an incorrect password and the server might record this differently
[ Other Info ]
These two paragraphs below only applied while I was considering fixing #1984073 together with this bug here. THAT IS NO LONGER THE CASE: only this bug, SCRAM, is being fixed now, and #1984073 is marked as won't fix/opinion for the SRU case.
No longer applicable, but left here for history:
"""
It's important to not analyse this fix here in isolation. There is another fix part of this upload which changes the way SASL authentication is handled: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1984073
It does not change how SCRAM would be enabled in autofs, but the code path becomes very different in the end.
"""
[ Original Description ]
Most directory services now support the more secure Salted Challenge
Response Authentication Mechanismis (SCRAM) for SASL binding (RFC 5802).
But automount user cannot request use of SCRAM, as automount does not
read user and password credentials for SCRAM mechanisms.
For sys admins that do not want to implement Kerberos based authentication to their directory service using GSSAPI need to rely on DIGEST-MD5, which is regarded as insecure. |
|
| 2023-07-26 19:49:20 |
Robie Basak |
autofs (Ubuntu Lunar): status |
In Progress |
Fix Committed |
|
| 2023-07-26 19:49:21 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-07-26 19:49:22 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2023-07-26 19:49:25 |
Robie Basak |
tags |
patch server-todo |
patch server-todo verification-needed verification-needed-lunar |
|
| 2023-07-26 19:49:53 |
Robie Basak |
autofs (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2023-07-26 19:49:56 |
Robie Basak |
tags |
patch server-todo verification-needed verification-needed-lunar |
patch server-todo verification-needed verification-needed-jammy verification-needed-lunar |
|
| 2023-07-27 12:36:16 |
Andreas Hasenack |
tags |
patch server-todo verification-needed verification-needed-jammy verification-needed-lunar |
patch server-todo verification-done-jammy verification-done-lunar verification-needed |
|
| 2023-08-08 20:00:34 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2023-08-08 20:01:10 |
Launchpad Janitor |
autofs (Ubuntu Lunar): status |
Fix Committed |
Fix Released |
|
| 2023-08-08 22:48:11 |
Launchpad Janitor |
autofs (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2023-08-09 14:53:08 |
Sergio Durigan Junior |
autofs (Ubuntu Kinetic): status |
In Progress |
Won't Fix |
|
| 2024-02-26 20:12:23 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/461238 |
|
| 2024-02-27 12:25:55 |
Andreas Hasenack |
merge proposal unlinked |
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/461238 |
|
|
| 2024-02-29 14:05:30 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/461238 |
|
