https://fedoraproject.org/wiki/Changes/drop_NIS_support_from_PAM
== Summary ==
This change is about dropping user-authentication using NIS(+) from PAM.
== Owner ==
* Name: [[User:besser82 | Björn Esser]] * Email: besser82@fedoraproject.org * Name: [[User:ipedrosa | Iker Pedrosa]] * Email: ipedrosa@redhat.com
== Detailed Description == NIS(+) was introduced by Sun/Oracle to easily share files and system users between UNIX-alike systems within the same network, and has been around for some decades. Its simplicity though opens a variety of possible security issues, like not being able the verify whether the shared information is actually correct and/or trustworthy. That said, and with several more secure options (LDAP, Kerberos, Samba, etc.) to achieve the same goal, we should at least remove support for NIS for user authentication.
== Feedback == There was some discussion on [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... the fedora-devel mailing-list]. Some people are reluctant about the removal of NIS(+) support from PAM, while most are okay with it as there are more secure alternatives (LDAP, FreeIPA, etc.) available.
== Benefit to Fedora == With this change we start directing our users and developers to move away from NIS(+) to secure alternatives like LDAP and/or FreeIPA.
== Scope == * Proposal owners: ** Adapt the pam spec file to build without support for NIS(+). ** Communicate the removal of the PAM configuration for user-authentication using NIS with the authselect maintainers; also offer assistance to implement the needed changes. * Other developers: ** Apply the pull-request to the authselect package. ** Test this change. * Release engineering: [https://pagure.io/releng/issue/10351 #10351] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A
== Upgrade/compatibility impact == Users that were relying on support for NIS(+) will need to move to secure alternatives like LDAP and/or FreeIPA.
== How To Test == There is no need to test, as when configure switch is removed, support is dropped.
== User Experience == For some users this change may be a bit disruptive and it may require some learning curve for switching to alternative solutions.
== Dependencies == * The authselect package needs to be updated to drop its PAM configuration for user-authentication using NIS. * Apart from that there are actually no rpms, that directly depend on the change of the functionality of the affected PAM module.
== Contingency Plan == * Contingency mechanism: Revert the changes made to the affected packages and rebuild them. * Contingency deadline: At beta freeze. * Blocks release? Yes.
== Documentation == The documentation about sharing system users and files over NIS should be dropped, if there even is any.
== Release Notes == Support for NIS(+) has been dropped from PAM. Users, who are currently using NIS(+) to share UNIX users / groups within a network, should migrate their setups to use LDAP or some other secure service providing comparable functionalities before updating to Fedora 36.
Hi -
== Upgrade/compatibility impact == Users that were relying on support for NIS(+) will need to move to secure alternatives like LDAP and/or FreeIPA. [...] == User Experience == For some users this change may be a bit disruptive and it may require some learning curve for switching to alternative solutions. [...] == Documentation == The documentation about sharing system users and files over NIS should be dropped, if there even is any.
There really ought to be tested migration scripts or at least instructions supplied. On a test server machine, I'm playing along with docs snippets
https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-gu...
and finding contradictions ("avoid editing LDIF files within /etc/openldap/slapd.d" then edit "/etc/openldap/slapd.d/cn=config.ldif") and migrationtools scripts are failing this way and that.
Could the Change proponents commit to producing transition instructions for servers & clients?
- FChE
Hi -
There really ought to be tested migration scripts or at least instructions supplied. [...] Could the Change proponents commit to producing transition instructions for servers & clients?
Recalling that such commitments were made as a part of the FESCO approval of this change (and its sibling - the dropping of YP servers), is this done yet?
- FChE
On Wed, Feb 16, 2022 at 4:47 PM Frank Ch. Eigler fche@redhat.com wrote:
Recalling that such commitments were made as a part of the FESCO approval of this change (and its sibling - the dropping of YP servers), is this done yet?
Not as far as I know, but this Change was deferred to F37 today.
On Thu, Oct 21, 2021 at 04:37:18PM -0400, Ben Cotton wrote:
== User Experience == For some users this change may be a bit disruptive and it may require some learning curve for switching to alternative solutions.
I've spoken with some of my sysadmin friends and universities, and they suggest that the above is enough of an understatement to feel insulting.
They would like, at least, more time than F36 to adjust to this, and broader communication that we plan to drop it.
On Wed, 2021-10-27 at 13:40 -0400, Matthew Miller wrote:
On Thu, Oct 21, 2021 at 04:37:18PM -0400, Ben Cotton wrote:
== User Experience == For some users this change may be a bit disruptive and it may require some learning curve for switching to alternative solutions.
I've spoken with some of my sysadmin friends and universities, and they suggest that the above is enough of an understatement to feel insulting.
They would like, at least, more time than F36 to adjust to this, and broader communication that we plan to drop it.
Remind me, why is NIS support being dropped?
Personally I thought it was a bad idea from the first I heard of it and never saw any actual valid reasons to do so. I was simply told to drop it from my package which I did.
Ian
On Wed, 27 Oct 2021 at 23:47, Ian Kent raven@themaw.net wrote:
On Wed, 2021-10-27 at 13:40 -0400, Matthew Miller wrote:
On Thu, Oct 21, 2021 at 04:37:18PM -0400, Ben Cotton wrote:
== User Experience == For some users this change may be a bit disruptive and it may require some learning curve for switching to alternative solutions.
I've spoken with some of my sysadmin friends and universities, and they suggest that the above is enough of an understatement to feel insulting.
They would like, at least, more time than F36 to adjust to this, and broader communication that we plan to drop it.
Remind me, why is NIS support being dropped?
Personally I thought it was a bad idea from the first I heard of it and never saw any actual valid reasons to do so. I was simply told to drop it from my package which I did.
Ian
Mainly because it is the authentication service equivalent of telnet**. Very simple to set up, very simple to use, and very easy to steal all the information about logins, users, and setups. You can secure it up to a point, but many of its faults like unencrypted text are designed into its 35 year old structure. It is a service which gets flagged on many security scans as a 'incredibly' high and is beginning to be flagged as a 'this should not even be shipped to us' by various sites (mainly because they have had major security breakins and their insurance company will no longer cover them unless they get serious.).
** And like telnet, it will only be dragged out of various infrastructures on the retirement of a generation of sysadmins.
Stephen John Smoogen smooge@gmail.com writes:
Mainly because it is the authentication service equivalent of telnet**. Very simple to set up, very simple to use, and very easy to steal all the information about logins, users, and setups. [...]
... well, compared to what? LDAP commonly distributes crypttext passwords and databases with about the same amount of discernment and theft-enablement as ypserv. Plaintext as in telnet makes an appearance nowhere but with yppasswd, AFAIK, which is nonessential.
- FChE
On Thu, 2021-10-28 at 10:28 -0400, Frank Ch. Eigler wrote:
Stephen John Smoogen smooge@gmail.com writes:
Mainly because it is the authentication service equivalent of telnet**. Very simple to set up, very simple to use, and very easy to steal all the information about logins, users, and setups. [...]
... well, compared to what? LDAP commonly distributes crypttext passwords and databases with about the same amount of discernment and theft-enablement as ypserv. Plaintext as in telnet makes an appearance nowhere but with yppasswd, AFAIK, which is nonessential.
LDAP is normally deployed on a secure channel (TLS or GSSAPI), that the client can cryptographically check.
NIS is a clear text protocol that can be trivially MitMed to provide arbitrary information to the target system.
Also generally LDAP *does not* in fact distribute passwords, most systems use the LDAP Bind operation to test a password and the LDAP server does *not* provide access to password hashes.
I thin k it is legitimate to question whether it is yet time to drop this obsolete protocol (NIS) on backwards compatibility grounds. But on security grounds it is indefensible, don't go there.
Simo.
On Thu, 2021-10-28 at 10:41 -0400, Simo Sorce wrote:
On Thu, 2021-10-28 at 10:28 -0400, Frank Ch. Eigler wrote:
Stephen John Smoogen smooge@gmail.com writes:
Mainly because it is the authentication service equivalent of telnet**. Very simple to set up, very simple to use, and very easy to steal all the information about logins, users, and setups. [...]
... well, compared to what? LDAP commonly distributes crypttext passwords and databases with about the same amount of discernment and theft-enablement as ypserv. Plaintext as in telnet makes an appearance nowhere but with yppasswd, AFAIK, which is nonessential.
LDAP is normally deployed on a secure channel (TLS or GSSAPI), that the client can cryptographically check.
NIS is a clear text protocol that can be trivially MitMed to provide arbitrary information to the target system.
Also generally LDAP *does not* in fact distribute passwords, most systems use the LDAP Bind operation to test a password and the LDAP server does *not* provide access to password hashes.
I thin k it is legitimate to question whether it is yet time to drop this obsolete protocol (NIS) on backwards compatibility grounds. But on security grounds it is indefensible, don't go there.
There's no question NIS has poor security, as bad a using a local password plus shadow file anyway. People that use it must know that. The valid use is company internal only, on systems whose data is freely available to company personnel and where accounts and groups info. isn't security critical.
It's been that way for many, many years ... it's no secret.
It's a pity NIS+ was such a pain to setup and use ... a bridge to far IMHO ...
Ian
On Fri, 29 Oct 2021 at 01:53, Ian Kent raven@themaw.net wrote:
On Thu, 2021-10-28 at 10:41 -0400, Simo Sorce wrote:
On Thu, 2021-10-28 at 10:28 -0400, Frank Ch. Eigler wrote:
Stephen John Smoogen smooge@gmail.com writes:
Mainly because it is the authentication service equivalent of telnet**. Very simple to set up, very simple to use, and very easy to steal all the information about logins, users, and setups. [...]
... well, compared to what? LDAP commonly distributes crypttext passwords and databases with about the same amount of discernment and theft-enablement as ypserv. Plaintext as in telnet makes an appearance nowhere but with yppasswd, AFAIK, which is nonessential.
LDAP is normally deployed on a secure channel (TLS or GSSAPI), that the client can cryptographically check.
NIS is a clear text protocol that can be trivially MitMed to provide arbitrary information to the target system.
Also generally LDAP *does not* in fact distribute passwords, most systems use the LDAP Bind operation to test a password and the LDAP server does *not* provide access to password hashes.
I thin k it is legitimate to question whether it is yet time to drop this obsolete protocol (NIS) on backwards compatibility grounds. But on security grounds it is indefensible, don't go there.
There's no question NIS has poor security, as bad a using a local password plus shadow file anyway. People that use it must know
As bad as using a local password and shadow file with file permissions of 0644 (or even 0666 depending on how badly it has been set up).
that. The valid use is company internal only, on systems whose data is freely available to company personnel and where accounts and groups info. isn't security critical.
Company internal only is a rarity these days with cloud deployments and people putting Alexa's and similar devices on the company internet. That 'smart fridge' in the company workroom or 'smart tv' in the executive lounge is both an internal and external device. That 'smart speaker' someone stuck on the wireless to play their music is just as likely to be able to send all that company data out as it is able to get Conway Twitty into the workplace.
It's been that way for many, many years ... it's no secret.
It's a pity NIS+ was such a pain to setup and use ... a bridge to far IMHO ...
Ian _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, Oct 29, 2021 at 8:00 AM Stephen John Smoogen smooge@gmail.com wrote:
Company internal only is a rarity these days with cloud deployments and people putting Alexa's and similar devices on the company internet. That 'smart fridge' in the company workroom or 'smart tv' in the executive lounge is both an internal and external device. That 'smart speaker' someone stuck on the wireless to play their music is just as likely to be able to send all that company data out as it is able to get Conway Twitty into the workplace.
You'd probably be surprised at the number of companies, and especially NAT'ed internal networks.
devel@lists.stg.fedoraproject.org
-
Ben Cotton -
Frank Ch. Eigler -
Ian Kent -
Matthew Miller -
Nico Kadel-Garcia -
Simo Sorce -
Stephen John Smoogen