🎯 Lab Objective

Investigate how SUID actually behaves on a modern Linux system, with a clear distinction between:

  • filesystem permission metadata
  • kernel-enforced execution rules

The goal of this lab was to validate assumptions through experimentation, focusing on real vs effective identity and understanding when privilege escalation is technically possible.

🧪 Lab Environment

  • OS: Ubuntu 24.04 (Parallels VM, ARM64)
  • User: parallels
  • Working Directory: ~/day16_suid_lab

🧩 Lab Setup

Created a dedicated lab directory to safely experiment with permissions and ownership without modifying system files.

mkdir ~/day16_suid_lab
cd ~/day16_suid_lab

Verified working directory:

pwd

Output:

/home/parallels/day16_suid_lab

📄 Script Creation & Baseline Execution

Created a simple shell script to inspect execution identity:

#!/bin/bash
whoami
id

Made the script executable:

chmod +x whoami.sh

Executed it:

./whoami.sh

Output confirmed execution as the normal user:

parallels
uid=1000(parallels) gid=1000(parallels)

🔐 Applying SUID to a Script (Test Case)

Set the SUID bit on the script:

sudo chmod u+s whoami.sh
ls -l whoami.sh

Output:

-rwsr-xr-x 1 parallels parallels whoami.sh

The filesystem correctly recorded the SUID bit.

Checked identity again:

id -u
id -ru

Output:

1000
1000

🧠 Observation

Despite the presence of the SUID bit:

  • Real UID and Effective UID remained identical
  • No privilege escalation occurred

This confirms that modern Linux kernels ignore SUID on scripts, even when filesystem metadata indicates otherwise.

⚙️ Real SUID with a Compiled Binary

To observe genuine SUID behavior, a minimal C program was created:

#include <stdio.h>
#include <unistd.h>

int main() {
    printf("Real UID: %d\n", getuid());
    printf("Effective UID: %d\n", geteuid());
    return 0;
}

Compiled into an executable binary:

gcc whoami.c -o whoami_bin

Baseline execution:

Real UID: 1000
Effective UID: 1000

Changed ownership and applied SUID:

sudo chown root:root whoami_bin
sudo chmod u+s whoami_bin

Re-executed:

Real UID: 1000
Effective UID: 0

👑 Key Findings

  • SUID does not work on scripts
  • SUID does work on compiled binaries
  • Ownership defines who you become
  • The kernel, not the filesystem, decides execution identity

🕵️ Enumeration Exercises

Enumerated SUID and SGID files using:

find / -perm -4000 2>/dev/null
find / -perm -2000 2>/dev/null

Observed a mix of expected system binaries such as:

  • passwd, sudo, pkexec
  • Xorg.wrap
  • snap-confine

These results reinforced the importance of filtering and reasoning, rather than assuming exploitability.

🧠 Cybersecurity Relevance

This lab mirrors real privilege escalation reconnaissance by:

  • validating execution context
  • identifying trust boundaries
  • distinguishing appearance from reality
  • reinforcing attacker-style enumeration discipline

Misunderstanding SUID behavior can lead to both false positives and missed attack paths.

🚧 Challenges Encountered

  • Expecting SUID to work uniformly across file types
  • Confusing filesystem metadata with kernel enforcement
  • Separating theoretical risk from practical behavior

💡 Key Takeaways

  • SUID is enforced by the kernel, not permission bits alone
  • Scripts are intentionally excluded from SUID execution
  • Effective UID is the true indicator of privilege
  • Enumeration requires judgment, not just command execution
  • Controlled experiments prevent incorrect mental models

📌 Reflection

This lab corrected several implicit assumptions about Linux privilege escalation. By testing both scripts and binaries, it became clear that security mechanisms are intentionally restrictive and context-aware. The exercise reinforced the importance of validating behavior empirically rather than relying on visual indicators such as permission bits alone.