FIDO Lab 4.5 — Blue/Yellow Key Privilege Separation

1. Lab Overview

In the first FIDO lab, students configured a FIDO2 authenticator for login. That is useful, but it still collapses a lot of trust into one credential. If the same key can log in and elevate privileges, then compromise, theft, or misuse of that credential may expose both the user session and the administrative path.

This follow-on lab separates those roles. The student logs in with the blue key. The system then requires the yellow key for sudo. This creates step-up authentication for privileged activity and gives students a concrete operational model:

2. Learning Objectives

3. Blue / Yellow / Red Operational Key Model

4. Target Architecture

Important design choice

This lab uses separate authorization mapping files. The blue key should not appear in the yellow sudo mapping file, and the yellow key should not be enrolled as the ordinary login key. This prevents one credential from satisfying both roles.

/etc/security/fido/
├── blue-login.u2f       # used by the initial login lab, if centrally managed
├── yellow-sudo.u2f      # used only by sudo in this lab
└── red-recovery.u2f     # optional recovery mapping for future labs

5. Preflight Safety Requirements

Assumptions

• The initial FIDO login lab has already been completed.
• The blue key can log the student into the system.
• The student account is already authorized to use sudo.
• The yellow key is a separate FIDO2 authenticator with a PIN configured.
• The lab is preferably performed in a VM with a snapshot available.

Open a recovery root shell

Open a terminal and keep this shell open until the end of the lab:

sudo -i

In the root shell, set variables used by the rest of the lab. Replace student with the actual account name.

export TARGET_USER="student"
export FIDO_DIR="/etc/security/fido"
export ORIGIN="pam://fido-lab"

Verify installed tools

dpkg -l libpam-u2f pamu2fcfg | cat
command -v pamu2fcfg
command -v visudo

If the packages are missing:

apt update
apt install -y libpam-u2f pamu2fcfg sudo

Create the central mapping directory

install -d -m 0750 -o root -g root "$FIDO_DIR"

6. Enroll the Yellow Key for sudo

In this section, students register the yellow key into a mapping file that will be used only by the sudo PAM service. Do not insert the blue key during this step.

Generate the yellow-key mapping

Run this as root from the recovery shell. Insert the yellow key when prompted and touch it when it flashes.

pamu2fcfg \
  -u "$TARGET_USER" \
  -o "$ORIGIN" \
  -i "$ORIGIN" \
  > "$FIDO_DIR/yellow-sudo.u2f"

Secure the mapping file

chown root:root "$FIDO_DIR/yellow-sudo.u2f"
chmod 0640 "$FIDO_DIR/yellow-sudo.u2f"
ls -l "$FIDO_DIR/yellow-sudo.u2f"
sed 's/:.*$/:<credential material hidden>/' "$FIDO_DIR/yellow-sudo.u2f"

Expected shape:

student:<credential material hidden>

7. Configure sudo-Specific PAM

The key trick is that Linux PAM applies policy per service. Login, screen unlock, SSH, and sudo can each have different PAM stacks. We will add a small include file and call it from /etc/pam.d/sudo.

Create a PAM include file for yellow-key sudo

cat > /etc/pam.d/fido-yellow-sudo <<EOF
#%PAM-1.0
#
# FIDO Lab 4.5 — yellow-key privilege elevation
#
# This file is included by /etc/pam.d/sudo.
# It requires the yellow FIDO key for sudo authorization.
#
# cue: prompt the user to touch the authenticator
# pinverification=1: require FIDO2 PIN verification where supported
# userpresence=1: require physical touch/presence
# origin/appid: fixed lab origin to avoid hostname drift problems

auth required pam_u2f.so \
  authfile=/etc/security/fido/yellow-sudo.u2f \
  cue \
  pinverification=1 \
  userpresence=1 \
  origin=pam://fido-lab \
  appid=pam://fido-lab
EOF

chmod 0644 /etc/pam.d/fido-yellow-sudo

Back up the existing sudo PAM file

cp -a /etc/pam.d/sudo "/etc/pam.d/sudo.backup.$(date +%Y%m%d-%H%M%S)"
cat /etc/pam.d/sudo

Edit /etc/pam.d/sudo

Open the file:

nano /etc/pam.d/sudo

Add the following line near the top of the file, before the normal @include common-auth line if that line exists:

auth include fido-yellow-sudo

The resulting file should look similar to this:

#%PAM-1.0

auth include fido-yellow-sudo

@include common-auth
@include common-account
@include common-session-noninteractive

Do not close the recovery shell

Keep the root shell open. Open a second terminal as the normal student user for testing.

8. Configure sudo Credential Caching

By default, sudo caches successful authentication for a short period. That is convenient, but it weakens the lesson. In this lab, every privileged action should require fresh yellow-key authorization.

Create a lab-specific sudoers drop-in

cat > /etc/sudoers.d/90-fido-yellow-stepup <<EOF
# FIDO Lab 4.5 — require fresh sudo authorization
#
# timestamp_timeout=0 means sudo prompts every time.
# This makes privilege elevation a deliberate step-up event.
Defaults timestamp_timeout=0
EOF

chmod 0440 /etc/sudoers.d/90-fido-yellow-stepup
visudo -cf /etc/sudoers.d/90-fido-yellow-stepup
visudo -c

9. Test Plan

Test 1 — Confirm normal user context

In a normal student terminal:

whoami
id
groups

Expected result: the shell belongs to the student user, not root.

Test 2 — Attempt sudo with no yellow key

Remove the yellow key. Leave the blue key available if the student normally uses it.

sudo -k
sudo whoami

Expected result: sudo should fail because the yellow key is unavailable.

Test 3 — Attempt sudo with blue key only

Insert only the blue key.

sudo -k
sudo whoami

Expected result: sudo should still fail. The blue key is a login credential, not a privilege credential.

Test 4 — Attempt sudo with yellow key

Insert the yellow key.

sudo -k
sudo whoami

Expected result:

root

Test 5 — Confirm fresh authorization is required

sudo whoami
sudo whoami

Expected result: both commands should require authentication because timestamp_timeout=0 disables the normal convenience window.

Test 6 — Verify login still works

Log out or switch to a TTY and verify that normal login still uses the blue-key path from the first lab. Do this only after sudo testing passes and the root recovery shell remains available.

10. Rollback and Recovery

Fast rollback from the open root shell

# Remove the sudo PAM include line
sed -i '/auth include fido-yellow-sudo/d' /etc/pam.d/sudo

# Disable the lab sudoers drop-in
mv /etc/sudoers.d/90-fido-yellow-stepup /root/90-fido-yellow-stepup.disabled 2>/dev/null || true

# Validate sudoers
visudo -c

Restore a known-good sudo PAM file

List backups:

ls -1 /etc/pam.d/sudo.backup.*

Restore the selected backup:

cp -a /etc/pam.d/sudo.backup.YYYYMMDD-HHMMSS /etc/pam.d/sudo

VM recovery

If the system is a VM and the auth stack is badly damaged, revert to the snapshot taken before this lab. Label recommended snapshots:

01-known-good-after-fido-login
02-before-yellow-sudo-lab
03-yellow-sudo-working

11. Troubleshooting

12. Operational Discussion

Authentication is not authorization

Login proves that the user is allowed to start a session. It does not automatically mean the user should be allowed to modify system state. Privilege elevation should be a separate, deliberate event.

Why the yellow key matters

The yellow key resists several common operational failures: unattended sessions, stolen laptop access, hijacked terminals, misused SSH sessions, and over-broad daily credentials. It creates a second decision point before the system crosses into administrative authority.

Why recovery matters

Security mechanisms that cannot be recovered safely become availability failures. The red-key or break-glass concept teaches students that resilient security includes recovery design, documented custody, and tested procedures.

Lab questions

1. What failure does a blue-only FIDO design still permit?
2. What changes when sudo requires the yellow key?
3. Should the yellow key be held by the same person as the blue key in a production environment?
4. What logs would you review after unauthorized sudo attempts?
5. What would a red-key procedure look like in a classroom, server room, or enterprise environment?

13. Instructor Notes

14. Appendix: Optional Hardening Extensions

Limit persistent root shells

The lab teaches one-command privilege elevation. Persistent root shells are useful for recovery but can weaken the operational model. For future labs, consider discussing policies that limit sudo -i, sudo su -, or unrestricted shell escapes.

Separate admin accounts

A production-style extension is to use one account for ordinary login and a separate admin account for elevated maintenance. The blue key authenticates the ordinary user; the yellow key authorizes the admin path.

SSH follow-on

A later lab can use a FIDO-backed SSH key for remote login while still requiring the yellow key for local sudo. This reinforces the idea that remote access and privilege elevation are different control points.

LUKS and Secure Boot follow-on

A later recovery-focused lab can introduce the red key as part of LUKS enrollment, Secure Boot recovery, or instructor-held break-glass access.

15. References

• Yubico pam-u2f project documentation
• pam_u2f(8) manual page
• sudoers(5) Linux manual page
• sudoers_timestamp(5) Linux manual page