The TTY's SUID Adventure

The TTY announced they'd "optimized the backup workflow."

The Revelation

At 09:47 on a Thursday morning—suspiciously early for initiative—the TTY appeared at my terminal with what I can only describe as misplaced pride.

TTY: "I wrote a custom backup script. Made it way more efficient. Users can back up their own files now without bothering us."

I felt a disturbance in the datacenter. Not the Force. Something worse. User empowerment without proper planning.

OPERATOR: "Show me."

I was already preparing documentation for what I suspected would be educational.

The TTY demonstrated. Users could indeed run the backup script. From their regular accounts. The script wrote to protected directories. Created archives in /var/backups. A location requiring root privileges.

OPERATOR: "How are users running commands that need root access?"

I asked with strategic calm.

The TTY beamed.

TTY: "I set the SUID bit! It runs as root automatically!"

The datacenter didn't explode. It should have, but infrastructure has a sense of dramatic timing.

The Teaching Moment

I took a breath. Then another. Coffee was required, but education came first.

OPERATOR: "Let's do an exercise. A practical demonstration of security auditing."

I pulled up a terminal on the projector—the TTY's education benefits from visual aids—and typed the sacred incantation for finding security nightmares:

$ find / -perm -4000 -type f 2>/dev/null
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/pkexec
/usr/local/bin/backup-script.sh

OPERATOR: "Notice anything interesting?"

The TTY squinted at the screen.

TTY: "That's... that's my script."

OPERATOR: "Indeed. Listed alongside passwd, sudo, and pkexec—programs written by people who understand security. And your script. Which, I'm guessing, doesn't sanitize input."

I opened the TTY's creation. Examined the code. Found exactly what I expected: no input validation, no path sanitization, direct execution of user-supplied filenames. A masterclass in what not to do.

#!/bin/bash
# backup-script.sh - Created by TTY
# DO NOT MODIFY WITHOUT TESTING

BACKUP_FILE=$1
tar -czf /var/backups/$(basename $BACKUP_FILE).tar.gz $BACKUP_FILE

OPERATOR: "The principle of least privilege suggests that programs should run with the minimum permissions necessary. Your script runs as root—maximum privilege—and accepts arbitrary input from users. This is what security professionals call 'a really bad idea.'"

I explained while documenting.

The Demonstration

OPERATOR: "Let me show you something educational."

I switched to a test account.

I created a file called /tmp/test.txt. Then I ran the TTY's script with a slight modification to the argument:

$ /usr/local/bin/backup-script.sh "/tmp/test.txt; cat /etc/shadow"

The script dutifully backed up my test file. Then, running with root privileges, it executed my second command. The contents of /etc/shadow—containing password hashes for every account—appeared on screen.

The TTY's face went through several interesting color transitions.

TTY: "But... but I only wanted to help with backups!"

OPERATOR: "And you created a root shell with extra steps. This is why we have security reviews. And testing. And the principle of not giving root access to things that don't need it."

I replied, not unkindly.

The Proper Solution

I pulled up a proper implementation. No SUID bit. No root privileges. Just a simple script that backed up to user-writable locations with proper error handling.

OPERATOR: "Alternative approach. Users back up to their home directories. A cron job running as root—with proper input validation—moves verified backups to protected storage. Separation of privileges. Defense in depth. Basic security architecture."

I removed the SUID bit from the TTY's script:

# chmod u-s /usr/local/bin/backup-script.sh

TTY: "But now users can't run it!"

OPERATOR: "Correct. Which is excellent news for system security."

I implemented the proper solution. Took approximately twelve minutes—eight of which were explaining each decision to the TTY. The principle of least privilege. Input validation. Path sanitization. The importance of assuming all user input is hostile.

OPERATOR: "Security isn't about preventing people from doing their jobs. It's about preventing them from accidentally—or intentionally—doing everyone else's jobs too. Especially root's job."

The Operator's Notes

The TTY's script was removed from production. The proper backup system was implemented with appropriate privilege separation. No users complained about the change, primarily because no users had actually discovered the original script before I found it.

The moral: SUID binaries are security-critical. Custom SUID binaries are security nightmares waiting to happen. The TTY now understands the difference between "works" and "works securely."

They're improving. Slowly. With substantial documentation along the way.

Such is education.