Skip to content

Blog

  • 3 min read

Serving FreeBSD Packages with Flavors

I have a FreeIPA instance that provides authentication and authorization services to a number of hosts in my homelab, a few of which run FreeBSD. Unfortunately, while FreeIPA is well integrated with tools like sudo on Linux, it's more of a hassle to get working properly on FreeBSD. The issue mainly comes down to FreeBSD binary packages not being compiled with the correct settings for use with FreeIPA by default. The solution is to recompile the relevant packages from the FreeBSD ports collection, which is sort of a hassle in and of itself. This is fine for a single host, but with multiple hosts in a network, this quickly becomes a tedious task.

The distribution problem can be solved using the excellent Poudriere build system that comes with FreeBSD. There is an entire article on setting up a Poudriere server to compile the ports needed to get FreeBSD working with FreeIPA here. This is the guide I followed when I first set up FreeBSD with FreeIPA in my homelab.

After a recent package build on the Poudriere server and subsequent package updates on one of the FreeBSD hosts, I suddenly found myself locked out. I could SSH into the host as a regular user just fine, but escalating privileges through sudo or even su wasn't happening. Even logging in as root from the host's console threw an error with reference to PAM.

/var/log/messages logged the following:

1
2
3
4
5
Mar 27 18:06:27 web01 su[9993]: BAD SU **username** to root on /dev/pts/0
Mar 27 18:06:32 web01 sssd_be[27666]: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0))
...
Mar 27 18:08:20 web01 sshd[19399]: fatal: Access denied for user **username** by PAM account configuration [preauth]
Mar 27 18:09:09 web01 sssd_be[27666]: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_0))

Seeing the references to PAM in the log made diagnosing the problem pretty straight forward. The host is configured to use FreeIPA for authentication and privilege escalation, and if sudo or login for some reason can't reach it, they fail. It's obvious some port had changed somehow since the last Poudriere build.

Some quick checking of the three main ports in this build (cyrus-sasl2-gssapi, openldap26-client and security/sudo) quickly revealed that the latter had undergone some changes recently. The change was simple enough: The SSSD option had been made into a flavor.

Now, what exactly is a flavor?

Turns out, the FreeBSD Handbook is pretty light on detail when it comes to port flavors. There is a section on how to configure flavors for a particular port and how to build a port flavor, but nothing on how to actually use a package built as a flavor.

Fair enough, at least I finally knew how to rebuild sudo with the now missing SSSD support:

1
2
3
4
5
6
root@poudriere:~ # cat /usr/local/etc/poudriere.d/idm
security/krb5
security/sudo@sssd
security/sssd2
security/cyrus-sasl2
...

The build only pulled in the sudo port and rebuilt it.

At first I assumed it had simply rebuilt sudo with SSSD support, but pkg refused to update sudo stating it was already at the latest version.

Turns out, having a port with a flavor builds a completely new package with a different name:

1
2
3
4
# pkg search sudo
...
sudo-1.9.16p2_1                Allow others to run commands as root
sudo-sssd-1.9.16p2_1           Allow others to run commands as root

Installing sudo-sssd uninstalls the regular sudo and installs the flavor with SSSD support:

1
2
$ sudo --version | grep sssd
Configure options: ... --with-tty-tickets --with-sssd --with-bsm-audit ...

Finally, logins and privilege escalations work as they should again.