----- Original Message ----- > From: "Martin Wege" <martin.l.wege@xxxxxxxxx> > To: "Linux NFS Mailing List" <linux-nfs@xxxxxxxxxxxxxxx> > Sent: Wednesday, 14 May, 2025 23:50:00 > Subject: Why TLS and Kerberos are not useful for NFS security Re: [PATCH nfs-utils] exportfs: make "insecure" the > default for all exports > On Wed, May 14, 2025 at 1:55 PM NeilBrown <neil@xxxxxxxxxx> wrote: >> >> On Wed, 14 May 2025, Jeff Layton wrote: >> Ignoring source ports makes no sense at all unless you enforce some other >> authentication, like krb5 or TLS, or unless you *know* that there are no >> unprivileged processes running on any client machines. > > I don't like to ruin that party, but this is NOT realistic. > > 1. Kerberos5 support is HARD to set up, and fragile because not all > distributions test it on a regular basis. Config is hard, not all > distributions support all kinds of encryption methods, and Redhat's > crusade&maintainer mobbing to promote sssd at the expense of other > solutions left users with a half broken, overcomplicated Windows > Active Directory clone called sssd, which is an insane overkill for > most scenarios. > gssproxy is also a constant source of pain - just Google for the > Debian bug reports. > > Short: Lack of test coverage in distros, not working from time to > time, sssd and gssproxy are more of a problem than a solution. > > It really only makes sense for very big sites and a support contract > which covers support and bug fixes for Kerberos5 in NFS+gssproxy. > > > 2. TLS: Wanna make NFS even slower? Then use NFS with TLS. > > NFS filesystem over TLS support then feels like working with molasses. > > Exacerbated by Linux's crazy desire to only support hyper-secure > post-quantum encryption method (so no fast arcfour, because that is > "insecure", and everyone is expected to only work with AMD > Threadripper 3995WX), lack of good threading through the TLS eye of > the needle, and LACK of support in NFS clients. > > Interoperability is also a big problem (nay, it's ZERO > interoperability), as this is basically a Linux kernel client/kernel server only > solution. dCache (a-ka nfs4j) server supports TLS, FreeBSD, ... So, it's not a Linux-only solution. Tigran. > libtirpc doesn't support TLS, Ganesha doesn't support TLS, so yeah, > this is an issue, and not a solution. > > Fazit: Supporting your argumentation with Kerberos5 or TLS is not gonna fly. > > Thanks, > Martin
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
