Re: RFC: pam: dropping support for NIS/NIS+?
On Fri, Apr 22, 2022 at 01:41:50PM -0700, Steve Langasek wrote: >... > On Fri, Apr 22, 2022 at 10:07:52PM +0200, la...@debian.org wrote: > > I'm using NIS since 20+ years in a small network with about 60 computers. > > Since I manage all computers and the physical network can be seen as secure > > (I know it's not perfect secure) I do not need the additional crypto > > features of NIS+ or LDAP, which would be overkill. All my users use > > yppasswd on the NIS master for changing their password. I guess I > > still need pam support for this because I set things like this in > > pam.d/common-password: > > > passwordrequisite pam_cracklib.so retry=3 > > difok=3 minlen=14 > > > Yes, I surely would miss the NIS support. > > If your users are using yppasswd on the NIS master for changing passwords, > then evidently you are not relying on support for NIS in PAM. (yppasswd > doesn't even link against libpam.) Could you add this information to NEWS.Debian and/or the release notes? People administrating networks tend to be the people who actually read the release notes before planning an upgrade to a new release. Thanks Adrian
Re: RFC: pam: dropping support for NIS/NIS+?
> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek > said: > If your users are using yppasswd on the NIS master for changing passwords, > then evidently you are not relying on support for NIS in PAM. (yppasswd > doesn't even link against libpam.) Thanks for clarifying this. -- regards Thomas
Re: RFC: pam: dropping support for NIS/NIS+?
> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek > said: > NIS also dates from a period when rsh was considered acceptable, and unless > I'm mistaken, has a comparable level of security. Allowing access to > password hashes for users based on the IP of the machine you are querying > from is not a sane security policy, and I don't think we should indefinitely > make Debian worse for all other users (bigger minimal system == worse) to > cater to users of these obsolete, insecure systems. A normal user does not see the password hashes, only processes which can use a port < 1024 see the password hash in the NIS map. So I do not see a problem giving machines of a subnet (based on their IP) access to the NIS data, when I can make sure only permitted computers can access the network. This does not give all users of this machine access to the password hashes. -- regards Thomas
Re: RFC: pam: dropping support for NIS/NIS+?
> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek > said: > If your users are using yppasswd on the NIS master for changing passwords, > then evidently you are not relying on support for NIS in PAM. (yppasswd > doesn't even link against libpam.) Thanks for clarifying this. -- regards Thomas
Re: RFC: pam: dropping support for NIS/NIS+?
Hi Thomas, On Fri, Apr 22, 2022 at 10:07:52PM +0200, la...@debian.org wrote: > I'm using NIS since 20+ years in a small network with about 60 computers. > Since I manage all computers and the physical network can be seen as secure > (I know it's not perfect secure) I do not need the additional crypto > features of NIS+ or LDAP, which would be overkill. All my users use > yppasswd on the NIS master for changing their password. I guess I > still need pam support for this because I set things like this in > pam.d/common-password: > passwordrequisite pam_cracklib.so retry=3 > difok=3 minlen=14 > Yes, I surely would miss the NIS support. If your users are using yppasswd on the NIS master for changing passwords, then evidently you are not relying on support for NIS in PAM. (yppasswd doesn't even link against libpam.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: RFC: pam: dropping support for NIS/NIS+?
Hi, I'm using NIS since 20+ years in a small network with about 60 computers. Since I manage all computers and the physical network can be seen as secure (I know it's not perfect secure) I do not need the additional crypto features of NIS+ or LDAP, which would be overkill. All my users use yppasswd on the NIS master for changing their password. I guess I still need pam support for this because I set things like this in pam.d/common-password: passwordrequisite pam_cracklib.so retry=3 difok=3 minlen=14 Yes, I surely would miss the NIS support. -- regards Thomas
Re: RFC: pam: dropping support for NIS/NIS+?
On Thu, Apr 21, 2022 at 03:30:55PM +0300, Dmitry Baryshkov wrote: > > > Before any discussion takes place, I would like to point out a previous > > > attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please > > > check out > > > the LWN article at https://lwn.net/Articles/874174/ , which would > > > definitely > > > be helpful for the condition in Debian. > > That discussion seems to be about removing NIS/NIS+ support from the > > entire distribution. This thread is about removing NIS support from PAM. > > That's an important distinction, because in practice, NIS/NIS+ support > > mostly means the NSS modules, and the tools/servers in the case of NIS. > > Dropping NIS support from PAM would mean losing only the ability to > > change the passwords of users coming from NIS. It would not affect user > > lookups, and password change would still be possible using yppasswd. > > There does not even seem to be any NIS+ support in PAM - nothing seems > > to include . > > Personlly, I think bundling NIS password changing capability in pam_unix > > was a design mistake. It should always have been a distinct module. > Can we provide a separately packaged pam_unix_nis which can be used > instead of pam_unix in cases where this functionality is still > required? Yes, that is technically possible and something I've already considered. I wasn't going to offer it up as a solution without some evidence of demand (which I would say this thread hasn't yet established), since it would require additional work on the package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: RFC: pam: dropping support for NIS/NIS+?
On Wed, Apr 20, 2022 at 10:23:06PM +0200, Gabor Gombas wrote: > Doing a quick check, PAM only seems to rely on the RPC libraries for > changing NIS passwords. Personally, I think losing that would not be a > big deal. While I can still see NIS being useful in some corners of the > world, I cannot imagine such an environment wanting to enforce password > expiration. And if you don't expire passwords, then you don't need PAM > to be able to change passwords - running yppasswd should be fine for > voluntary password changes. Thanks, that's an important nuance that I'd forgotten about (or I would have mentioned it). Indeed, dropping support in PAM for NIS won't make the NSS modules go away - so a properly-configured /etc/nsswitch.conf will still give you user/group lookups via NIS or NIS+, and there are other ways to handle password changes. IMHO this further raises the bar for keeping support for these (insecure, obsolete) backends in pam. On Wed, Apr 20, 2022 at 04:26:02PM -0400, Boyuan Yang wrote: > Before any discussion takes place, I would like to point out a previous > attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please > check out the LWN article at https://lwn.net/Articles/874174/ , which > would definitely be helpful for the condition in Debian. Thanks for the pointer. I think that's useful in terms of understanding the landscape in the abstract, but shouldn't be taken as a definitive answer because it doesn't really address whether any Debian users depend on this functionality today. NIS also dates from a period when rsh was considered acceptable, and unless I'm mistaken, has a comparable level of security. Allowing access to password hashes for users based on the IP of the machine you are querying from is not a sane security policy, and I don't think we should indefinitely make Debian worse for all other users (bigger minimal system == worse) to cater to users of these obsolete, insecure systems. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: RFC: pam: dropping support for NIS/NIS+?
чт, 21 апр. 2022 г. в 11:04, Gabor Gombas : > > Hi, > > On Wed, Apr 20, 2022 at 04:26:02PM -0400, Boyuan Yang wrote: > > > Before any discussion takes place, I would like to point out a previous > > attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please check > > out > > the LWN article at https://lwn.net/Articles/874174/ , which would definitely > > be helpful for the condition in Debian. > > That discussion seems to be about removing NIS/NIS+ support from the > entire distribution. This thread is about removing NIS support from PAM. > That's an important distinction, because in practice, NIS/NIS+ support > mostly means the NSS modules, and the tools/servers in the case of NIS. > > Dropping NIS support from PAM would mean losing only the ability to > change the passwords of users coming from NIS. It would not affect user > lookups, and password change would still be possible using yppasswd. > There does not even seem to be any NIS+ support in PAM - nothing seems > to include . > > Personlly, I think bundling NIS password changing capability in pam_unix > was a design mistake. It should always have been a distinct module. Can we provide a separately packaged pam_unix_nis which can be used instead of pam_unix in cases where this functionality is still required? -- With best wishes Dmitry
Re: RFC: pam: dropping support for NIS/NIS+?
Hi, On Wed, Apr 20, 2022 at 04:26:02PM -0400, Boyuan Yang wrote: > Before any discussion takes place, I would like to point out a previous > attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please check out > the LWN article at https://lwn.net/Articles/874174/ , which would definitely > be helpful for the condition in Debian. That discussion seems to be about removing NIS/NIS+ support from the entire distribution. This thread is about removing NIS support from PAM. That's an important distinction, because in practice, NIS/NIS+ support mostly means the NSS modules, and the tools/servers in the case of NIS. Dropping NIS support from PAM would mean losing only the ability to change the passwords of users coming from NIS. It would not affect user lookups, and password change would still be possible using yppasswd. There does not even seem to be any NIS+ support in PAM - nothing seems to include . Personlly, I think bundling NIS password changing capability in pam_unix was a design mistake. It should always have been a distinct module. Regards, Gabor
Re: RFC: pam: dropping support for NIS/NIS+?
Hi, On Wed, Apr 20, 2022 at 10:57:58AM -0700, Steve Langasek wrote: > So I'd like to take a step back and challenge an underlying assumption by > asking: do any of our users actually *need* this functionality? The RPC > functionality is only used for NIS and NIS+. NIS is historically quite > insecure, and I'm not aware of any efforts to improve its security (AFAIK > the linkage of the crypto libraries doesn't fix the fundamentally insecure > interfaces of NIS). NIS+ is intended to be a more secure version of NIS, > but to my knowledge there has never been a free implementation in the > archive; this was a Sun-specific technology, which Sun deprecated two > decades ago[1]. > > If we dropped support for NIS and NIS+ in the next Debian release, would > anybody miss it? Or has everyone moved on to LDAP / AD by now? NIS still has uses in small, closed environments where setting up LDAP would be overkill, or if you have to interface with some ancient systems. NIS+ was a nice idea in its own time, and it allowed making NFS more secure before RPCSEC_GSS took over. However, the strength of the crypto used by NIS+ probably does not worth much today anymore, so I'd be surprised if anyone still used it on Linux. Doing a quick check, PAM only seems to rely on the RPC libraries for changing NIS passwords. Personally, I think losing that would not be a big deal. While I can still see NIS being useful in some corners of the world, I cannot imagine such an environment wanting to enforce password expiration. And if you don't expire passwords, then you don't need PAM to be able to change passwords - running yppasswd should be fine for voluntary password changes. Regards, Gabor
Re: RFC: pam: dropping support for NIS/NIS+?
Hi, 在 2022-04-20星期三的 10:57 -0700，Steve Langasek写道： > Hi folks, > > As of glibc 2.32, upstream has split out RPC support; if you want RPC > functionality, you now need to link against libtirpc instead, which is a > superior, more featureful implementation. > > This is a good thing architecturally, but one of the side effects for us is > that, via PAM, we are now pulling a large number of crypto libraries into > the transitively-essential set, because pam_unix links against libtirpc for > NIS / NIS+ support. > > Sam Hartman made a valiant attempt to make this an optional dynamic > dependency, but ultimately abandoned the effort. > > So I'd like to take a step back and challenge an underlying assumption by > asking: do any of our users actually *need* this functionality? The RPC > functionality is only used for NIS and NIS+. NIS is historically quite > insecure, and I'm not aware of any efforts to improve its security (AFAIK > the linkage of the crypto libraries doesn't fix the fundamentally insecure > interfaces of NIS). NIS+ is intended to be a more secure version of NIS, > but to my knowledge there has never been a free implementation in the > archive; this was a Sun-specific technology, which Sun deprecated two > decades ago[1]. > > If we dropped support for NIS and NIS+ in the next Debian release, would > anybody miss it? Or has everyone moved on to LDAP / AD by now? Before any discussion takes place, I would like to point out a previous attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please check out the LWN article at https://lwn.net/Articles/874174/ , which would definitely be helpful for the condition in Debian. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
RFC: pam: dropping support for NIS/NIS+?
Hi folks, As of glibc 2.32, upstream has split out RPC support; if you want RPC functionality, you now need to link against libtirpc instead, which is a superior, more featureful implementation. This is a good thing architecturally, but one of the side effects for us is that, via PAM, we are now pulling a large number of crypto libraries into the transitively-essential set, because pam_unix links against libtirpc for NIS / NIS+ support. Sam Hartman made a valiant attempt to make this an optional dynamic dependency, but ultimately abandoned the effort. So I'd like to take a step back and challenge an underlying assumption by asking: do any of our users actually *need* this functionality? The RPC functionality is only used for NIS and NIS+. NIS is historically quite insecure, and I'm not aware of any efforts to improve its security (AFAIK the linkage of the crypto libraries doesn't fix the fundamentally insecure interfaces of NIS). NIS+ is intended to be a more secure version of NIS, but to my knowledge there has never been a free implementation in the archive; this was a Sun-specific technology, which Sun deprecated two decades ago[1]. If we dropped support for NIS and NIS+ in the next Debian release, would anybody miss it? Or has everyone moved on to LDAP / AD by now? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] "Prior to the release of Solaris 9 in 2002, Sun announced its intent to remove NIS+ from Solaris in a future release and now recommends that customers instead use an LDAP-based lookup scheme." https://en.wikipedia.org/wiki/NIS+ signature.asc Description: PGP signature
