Re: Diskless NFS over TLS

On Sat, Jun 24, 2023 at 6:15 AM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Sat, Jun 24, 2023 at 2:24 AM Peter Jeremy <peterj@freebsd.org> wrote:
> >
> > I have a number of aarch64 SBCs that run "diskless": U-Boot loads
> > boot.scr.uimg, loader.efi and the DTB via TFTP, EFI loads the loader
> > config and kernel via NFS and passes the NFS root details to the kernel.
> >
> > I am contemplating whether it's possible to use secure NFS for at least
> > the root mount[*].  The problem is that NFS-over-TLS relies on
> > rpc.tlsclntd to perform the STARTTLS and that needs a functional
> > userland to run it.
> At this point, I do not think the "tls" option can be added via "mount -u".
> I had assumed that users would want "on the wire encryption, etc" to
> be done right away, before any non-encrypted data travels across the
> wire.
>
> I suppose allowing "tls" to be added via "mount -u" could be added to
> the code. What do others think about this?
> (It means that the file system mount would be running insecure for a while.)
>
Btw, to make this work for your case would be non-trivial, since the
old (non-TLS)
TCP connection would need to continue to work until the TLS handshake upcall
to the daemon is completed.  And the, the TCP connection used for NFS RPCs
would need to be switched to use the new TLS/TCP connection. This is not how
the krpc works now, so I am not exactly volunteering to do this, even if others
think it is a good idea.

rick

> Can you put all the data that needs to be secured on a separate volume and
> mount that from /etc/fstab? (I'm sure you have thought of this, but...)
> Note that there is overhead in using NFS-over-TLS (mostly CPU overhead,
> assuming you do not have hardware offload), so you only want to use it
> when there is data that needs to be secured.
>
> rick
>
> >
> > Does anyone have any idea how to proceed?  Maybe something like mfsroot
> > with the real root then overlaid over it (though I haven't thought this
> > through).  (And I realise that protecting the keys is problematic).
> >
> > [*] It would be nice to secure TFTP and the kernel load but that's less
> >     feasible.
> > --
> > Peter Jeremy