SUID inventory should preserve filesystem scope and program context. Keep a mode-bit observation separate from applicability and a demonstrated privilege transition.
Sources, review date and section shortcuts
Key claims reviewed: October 19, 2026. SUID/SGID enumeration is inventory work; owner, mount and execution controls determine possible privilege transitions.
Primary documentation · Kioptrix Privilege Escalation: 5 Evidence Checks Before Testing
Go straight to: Decision check · Main workflow · Further detail
Open the SUID: Privilege inventory coverage for this guide’s task-specific fields and next action.
Report omitted filesystems as a coverage limit
The inventory example uses a filesystem boundary. Record the starting point and omitted mounts so a short result is not presented as a complete host inventory. Keep file capabilities as a separate mechanism from SUID bits. An observed mode or capability needs the relevant execution context and program behavior before it supports a stronger claim. Preserve unknowns instead of executing an unfamiliar file merely to fill a reporting field. Source and scope.
Start by recording SUID and SGID files, then check what privilege change is possible in the actual execution context. A mode bit is an inventory finding. Calling it an exploitable privilege-escalation path requires evidence about the program, reachable inputs and applicable controls. Root ownership alone does not establish that an unprivileged user can obtain a root shell.
This guide provides a documentation-based workflow for an authorized Linux review or training lab. It contains no personal exploitation account, measured time savings or demonstrated result on your host. Official references checked: October 16, 2026. The commands below are proposed inspection steps; they have not been run against your systems.
What SUID and SGID actually change
The Linux execve reference explains that executing an eligible set-user-ID program changes the effective user ID to the file owner; set-group-ID changes the effective group ID to the file’s group. The real IDs are not changed by this operation. The owner need not be root, and the program can handle privileges differently after starting.
Linux ignores set-user-ID and set-group-ID bits on interpreter scripts. SGID on a directory has a different purpose from SGID on a program; the regular-file search below excludes directories. A regular file carrying a special bit is not necessarily executable by your account. Check the actual type, execute permissions and path access.
Use two passes: inventory, then investigate
First establish what you searched, what you found and what you could not inspect. Then review individual candidates against a specific question: can this caller influence an operation performed with different privileges? Keep unknown prerequisites visible. Do not discard a candidate merely because it fails an arbitrary count of yes/no questions, and do not prioritize it solely because its name appears in an online example.
1. Build an inventory with explicit coverage
This GNU find example lists regular files with SUID or SGID set without executing them. Substitute a smaller approved starting directory when needed.
find / -xdev -type f \
-perm /6000 -lsThe GNU find manual published by Debian documents the tests: -perm /6000 matches either special bit, while -perm -6000 requires both. -xdev prevents descent onto other devices; a separate /usr filesystem can therefore be omitted. The default link behavior also affects coverage. Record approved starting points and review other filesystems separately where needed.
Keep diagnostics and the command’s exit status with the listing. Permission errors, interrupted traversal or an excluded mount mean the result is incomplete. Sending errors to /dev/null makes the display quieter without resolving those gaps. A listing is a point-in-time observation, not a guarantee that permissions stayed unchanged. Do not feed its human-readable output directly into a script that executes files.
2. Check the mount and namespace context
Replace the placeholder path with the candidate’s actual absolute path. The util-linux findmnt manual documents selecting a filesystem by a file path and requesting explicit columns. Check the installed version’s supported options.
findmnt \
--target /path/to/program \
--output TARGET,FSTYPE,OPTIONSThe execution rules can suppress the SUID/SGID transition when the filesystem is mounted nosuid or the caller is being traced. Record the relevant mount in the execution environment rather than inferring it from a familiar directory name. Do not remove a security control to make a suspected technique work.
The user-namespace reference explains UID/GID mappings and namespace-scoped privileges. A process shown as root inside a container or user namespace is not automatically host root. Record the boundary under review, relevant mappings and available evidence; an unusual path or container label alone does not resolve the question.
3. Identify the program and the claimed mechanism
Record the exact path, owner, package or local-build provenance and installed release. Compare a packaged helper with its supplier’s security advisory and configuration guidance. A well-known utility can be legitimately privileged; an unfamiliar local wrapper can also be correctly designed. Neither popularity nor rarity establishes risk.
Write a testable hypothesis with its prerequisites, such as a privileged helper consuming a caller-controlled configuration file. Confirm that the program actually reads that file in the relevant path. For version-driven concerns, the related CVE evidence workflow explains why a version match, supplier patch status and demonstrated impact are separate conclusions.
4. Inspect the file and its path components
These proposed metadata checks do not invoke the candidate program. Use the actual absolute path and retain errors. The stat manual describes file status; without -L, a symbolic-link argument is reported as a link rather than automatically dereferenced. The namei manual explains following path components and showing modes and owners.
stat -- /path/to/program
namei -l -- /path/to/programInspect relevant helper, configuration and data paths as well as the executable. Ordinary mode bits alone do not describe every access decision: ACLs, mount behavior and security policy may matter. A writable directory is a reason to investigate how the program opens or resolves a path, not automatic proof that arbitrary code runs with elevated privileges.
5. Account for loader and application behavior
The glibc dynamic-loader reference describes secure-execution mode, where some environment variables are removed, ignored or restricted. Do not assume LD_PRELOAD or LD_LIBRARY_PATH behaves as it does in an ordinary process. This documentation concerns the relevant dynamic loader, not every possible statically linked or alternative-libc program.
A command name found in strings is only a lead. It does not prove that the program calls a shell, searches PATH or reaches that code with privileges intact. Establish actual behavior through trusted source, vendor documentation or separately approved analysis. Avoid executing an unknown helper simply to discover what it does.
6. Review other privilege controls separately
The kernel’s no_new_privs documentation explains that the flag prevents new privileges through execve, including SUID/SGID transitions and file-capability gains. Its presence in one process is not proof that every other execution context uses it. It also does not block every kind of privilege change unrelated to execve.
A SUID inventory is not a complete privilege review. Linux file capabilities are a separate mechanism. The getcap manual describes inspecting a specified file’s capabilities. Evaluate relevant capabilities and applicable security policy within the agreed scope, without treating a missing SUID bit as a clean bill of health.
7. Prioritize evidence gaps and potential impact
Prioritize a plausible privilege-boundary issue when an exposed input and affected privileged operation are supported by evidence. Record the impact, current controls, uncertainty and next check. A short timebox can organize work, but no fixed minutes-per-candidate estimate proves completeness. Preserve unresolved candidates for review instead of declaring them safe because time expired.
8. Separate inspection from behavioral testing
Agree any execution test, expected effects and recovery procedure before running a candidate. Tracing can alter privileged execution behavior, so a traced run may not represent a normal invocation. The ldd security warning also explains why it should not be used on an untrusted executable: some circumstances can lead to code execution. Metadata inspection and running a program are different actions.
Do not change file ownership, add special bits, replace helper files or disable confinement as an enumeration step. If the available evidence already supports a remediation decision, a disruptive proof attempt may add little value. Record the limits of any permitted test and keep monitoring active.
9. Record the finding and verify remediation
The overview above is an investigation aid, not a vulnerability verdict. Use the record below to connect each conclusion to evidence and distinguish inventory, a plausible mechanism and any approved demonstrated impact.
Asset / authorization / collection time:
Caller identity and execution context:
Search command / starting points / errors / excluded mounts:
Candidate path / type / mode / owner / group:
Package or build / supplier advisory / patch evidence:
Relevant mount / namespace / privilege controls:
Caller-controlled input and privileged operation:
Evidence / unmet prerequisites / unresolved questions:
Permitted tests and observed result, if any:
Owner / corrective action / verification / limitations:Give the owner a specific corrective action tied to the mechanism: update an affected package, correct a configuration or path permission, or remove unnecessary privilege after checking operational requirements. Do not remove SUID/SGID from every discovered file indiscriminately. Retest intended functionality and the affected boundary after an approved change, then record what was verified.
Questions before calling a result exploitable
Does an empty result mean there is no privilege-escalation risk? No. Review scope, errors, excluded filesystems and the caller’s visibility. Capabilities, service configuration and other mechanisms are separate questions.
Must a candidate have a writable configuration file? No single input type is required for every issue. Review the specific program and claimed mechanism; arguments, standard input and other caller-controlled data may be relevant. A checklist is a prompt for investigation, not a universal exploit test.
Should you test every online technique? Check the environment’s rules and establish the prerequisites first. A named program and a special bit are insufficient. Keep unsupported hypotheses separate from observed impact.
Choose the next check from the evidence
Save one scoped inventory, document its gaps and review a candidate’s actual execution conditions. If the proposed boundary crossing remains unclear, record the missing fact and ask the responsible owner for that evidence. A useful review explains the result and its limits without requiring a root shell.
SUID: Privilege inventory coverage
Use these fields for your own task. Keep the actual conditions, evidence and unresolved questions beside the next decision.
On a small screen, scroll the table sideways to read all columns.
| Field | What to record | Your evidence / next check |
|---|---|---|
| Inventory scope | Record starting path, filesystem boundary and omitted mounts. | To complete |
| File context | Preserve owner, mode, capabilities and relevant execution controls. | To complete |
| Behavior prerequisite | Identify the input and program conditions behind a lead. | To complete |
| Disposition | Keep inventory, applicability and demonstrated transition distinct. | To complete |
Next action: Report the uninspected filesystem coverage rather than executing an unfamiliar file to fill a gap.
Related task: Use Kioptrix Level 1 Privilege Review: Sudo, SUID and Kernel Evidence for that separate part of the workflow.
Worksheet change record — October 20, 2026
Added four task-specific fields, a next action and a related guide. This is a blank editorial working aid, not a completed test or validated assessment. Existing source-review dates retain their own scope; this addition is not a new verification of every statement.