Is there a corresponding mechanism to secure apt for FreeBSD

aptfreebsdintegritySecurity

Coming from more of a linux background I looked into FreeBSD and I have read most of the FreeBSD Handbook, which is good and provides lots of insights also about Security (Chapter 13). Even though lots of security related information was laid out I fail to find/understand how the integrity of the sources to FreeBSD is accomplished (and to the ports and binary package system also).

As stated before I am used to way of some linux distros, Debian more specifically, where a mechanism or tool called secure apt is used where the original trust root is via a public key ("Debian Archive Automatic Signing Key") which gpg signs a cascade of Hash lists that eventyually cover all files in packages.

When dealing with how to acquire FreeBSD securily it mentions the option of using the FreeBSD subversion repo where it states then

HTTPS is the preferred protocol, providing protection against another
computer pretending to be the FreeBSD mirror (commonly known as a “man
in the middle” attack) or otherwise trying to send bad content to the
end user.
( Source: https://www.freebsd.org/doc/handbook/svn.html )

and while I agree completely to the usefullness of TLS/SSL I was wondering if that is all the protection available? Does the FreeBSD community besides a "secure channel" HTTPS (some CAs seem state actors), use some sort of other signing WOT alternative to check for the integrity of the sources acquired?

What I ask hence is there something similar to secure-apt of Debian?

update:

I have checked that package signing via a web of trust (WOT) approach from some other Linux Distro, Arch Linux is as young as 2012 (see https://pierre-schmitz.com/trust-the-master-keys/), while for gentoo similar seems to exist, yet I cannot tell when it was introduced.
https://wiki.gentoo.org/wiki/Integrity/Concepts

In any way it seems that there have been efforts in Linux distros to address package/source integrity, so I am very positive that something similar exists in the securtiy and order famouse realm of BSDs, right?

Best Answer

Packages

I publish a signed package repository, and here's how it works.

The system administrator configures repositories by adding a configuration file such as /usr/local/etc/pkg/repos/JdeBP.conf. As part of doing so, xe tells the package manager the public key that is to be used to check the signatures on the repository. Xe obtains this key from me in some suitably trusted fashion, and saves it in a file somewhere like /usr/local/etc/pkg/keys/JdeBP.pub. Xe then names that as the public key file in /usr/local/etc/pkg/repos/JdeBP.conf.

I sign the package repository with the private key that only I have using the command pkg repo . /elsewhere/package_signing_key. This creates signed information about the repository and the packages in three files, meta.txz, digests.txz, and packagesite.txz. Each of those archives has two files, one being a signature file for the other. The digests and packagesite archives contain hashes of each of the package archive files. The meta archive just contains the names of the other two and some versioning of the pkg-ng tool information.

So this is very much like Secure APT. There are some differences:

  • Instead of Release giving the checksums for Packages and Packages then giving the hashes for the actual package archives, pkg-ng has just one level. packagesite.yaml gives the hashes of the actual package archives directly.
  • Instead of things being split into separately downloadable Release and Release.gpg files, and then further Packages and Sources files, the packagesite.yaml file (covering the entire repository) and its signature are downloaded as a unit in one fetch operation (and one HTTP/FTP transaction) as the packagesite.txz file.

But the idea is much the same. A system administrator trusts that the packagesite.yaml file came from me because its accompanying signature can be checked against the locally stored, trusted, copy of my public key. A system administrator trusts that the redo-1.3.txz file came from me because its hash matches the hashes from the (now) trusted packagesite.yaml.

Ports

Ports are a very different kettle of fish. Debian's Secure APT treats source packages as just more packages. FreeBSD/TrueOS ports are not source packages in the Debian sense, but are rather automated ways of obtaining and building source packages that are published by someone else. A port is in essence a makefile with some instructions on where to fetch source from. It has a list of the hash(es) of whatever is to be fetched.

The port itself comes from the FreeBSD or TrueOS repository, using either Subversion (if FreeBSD) or git (if TrueOS or FreeNAS). The standard ideas for trusting Subversion or git thus apply. On TrueOS, for example, the "remote" URL used when fetching the ports (themselves) with git is an HTTPS url for a GitHub repository that iXsystems vouches (in the TrueOS Handbook) is one that it owns.

So a system administrator trusts a port because xe has obtained it using a Subversion or git fetch that xe trusts. Xe trusts the source archive fetched by the port because it matches the hash listed in the (now) trusted port.

Notes

Debian's Release.gz and Packages.gz are pretty much in effect just ways to compress the HTTP transport. I've glossed over some other things that aren't to do with security, such as differences in how one is expected to handle multiple operating system releases.

Debian has moved towards how FreeBSD works over the years, and doesn't work like that wiki page says any more. Nowadays one has the hashes and the signature all in one, more like a FreeBSD repository, in an InRelease file. This prevents a "tearing" problem that occurs when one downloads Release and then Release.gpg and the repository owner has updated the repository in between the two downloads, causing a signature mis-match.

(Debian only did things this way originally because it grew these things in stages over the years, each built upon the preceding mechanisms without changing them: first the Package system, then the Release mechanism on top of that, then the Release.gpg mechanism on top of that.)

Also: FreeBSD has another, different, way of doing this which involves "fingerprints" and a signed digests file (in the digests.txz archive).

I've also glossed over the security considerations for the signing key, as that isn't really relevant to an answer that is discussing how this is like/unlike Secure APT. The requirements of private key security are general to the whole notion of signing things with public/private keys, and are independent of repository structures.

Further reading

Related Question