pkg/archive: nosysFileInfo: implement tar.FileInfoNames to prevent lookups

[thaJeztah]

relates to:

• archive/tar: add FileInfoNames interface golang/go#50102
• Remove local fork of archive/tar package #43185
• Fix CVE-2019-14271 loading of nsswitch based config inside chroot under Glibc #39612

commit e9bbc41 removed our fork of pkg/archive that was in place to mitigate CVE-2019-14271. As part of that change, a nosysFileInfo type was added to prevent tar.FileInfoHeader from looking up user- and group-names.

A proposal was pending in go https://go.dev/issue/50102 to define an interface for implementing custom lookup functions to be implemented, and disable go's builtin lookup. That proposal was accepted, and is now implemented in go1.23.

Thia patch makes the nosysFileInfo implement the tar.FileInfoNames interface to prevent tar.FileInfoHeader from performing its own lookups. While the mitigation implemented in e9bbc41 should already prevent this from happening, implementing the interface does not cost us much and is complementary to the existing mitigation.

With this patch in place, we can consider removing the mitigation added in a316b10, which was discussed to be ineffective, but left in place for the time being.

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[thaJeztah]

I'm now considering if this part is accurate;

With this patch in place, we can consider removing the mitigation added in a316b10, which was discussed to be ineffective, but left in place for the time being.

Reading back some comments from @corhere in #42402 (comment) and some following that, there were still concerns about running go code inside the ("hostile") chrooted environment. The user-lookups addressed here (and patches before this) were the known cases where libraries could be loaded, but may not be comprehensive. So perhaps the init still has some value?

moby/pkg/chrootarchive/archive_unix.go

Lines 16 to 21 in 2c56497

	func init() {
	// initialize nss libraries in Glibc so that the dynamic libraries are loaded in the host
	// environment not in the chroot from untrusted files.
	_, _ = user.Lookup("docker")
	_, _ = net.LookupHost("localhost")
	}

I recall from some discussion though that there was doubt whether that init was actually effective, but I'm trying really hard to recall the details around that (maybe @corhere recalls); if not, it may be good to remove it to not give a false sense of additional security provided