Use privileged group, daemon or container-management control

Needs: Effective daemon/API permission, correct rootful/rootless or privileged mode, available resources and a host-affecting operation

Shell commands

# Baseline
id
ls -l /var/run/docker.sock /run/docker.sock 2>/dev/null
docker version 2>/dev/null
lxc list 2>/dev/null

# Rootful Docker daemon with an available image
docker images
docker run --rm -it -v /:/host IMAGE chroot /host /bin/sh

# LXD/LXC with an available image alias
lxc image list
lxc init IMAGE_ALIAS privesc -c security.privileged=true
lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true
lxc start privesc
lxc exec privesc /bin/sh

Requires daemon/socket access, a rootful daemon, usable image and allowed host bind mount. Rootless mode, user namespaces, authorization plugins and SELinux can change the effect.

Requires configured daemon access, sufficient group rights, image availability and privileged-container/device support.

Verify → Distinguish host and container namespace, effective UID and the exact host operation.

If it fails → Rootless mode, user namespaces, policy or absent images can change the route. Do not equate a container prompt with host compromise. More detail ↓

If → then

A new Linux foothold or an identity/privilege change → Establish Linux state and choose an escalation candidate
Needs: A working command channel and accurate effective identity, group, mount and process context
Readable configuration, shell history, environment, process arguments or session sockets → Recover credentials from Linux user, service and process trails
Needs: Read access to the artifact; exact account/service context; session/agent access must include a usable live identity
A writable/exported filesystem or a loopback-only service with useful privileges → Exploit a permission-backed mount, NFS mapping or local service
Needs: Relevant export/mount options or service authentication; effective identity, writable path and any privileged execution consumer

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Use privileged group, daemon or container-management control

USE WHEN: Membership or socket ACLs permit controlling a rootful daemon or useful session
STARTING ACCESS: A verified Linux foothold with a known effective UID, groups and filesystem context
RESULT: A verified privileged daemon operation or host-relevant access

Recognize the clue

Inspect groups, local sockets and namespace context, then use only permitted read-only daemon inventory to identify rootful/rootless behavior.

id
ls -l /var/run/docker.sock
cat /proc/1/cgroup

SYNTHETIC EXAMPLE OUTPUT

groups include docker
Socket group: docker; group read/write
Container/host context: verify separately

Means: Effective socket access suggests daemon control; group text alone does not establish host-affecting rootful operations.

Confirm: Check API acceptance, rootful/rootless and namespace policy, available resources and the specific host operation.

After validation: A rootful daemon permits the required host-affecting operation: use that documented route.
Ruled out in this context: A rootless/user-namespaced daemon cannot grant the assumed host-root effect: reject that chain.
Still inconclusive: Socket presence without usable API permissions leaves the control claim unresolved.

Troubleshooting: Rootless mode, user namespaces, policy or absent images can change the route. Do not equate a container prompt with host compromise.

Additional prerequisite checks

id
ls -l /var/run/docker.sock
findmnt
cat /proc/1/cgroup

Group candidates include docker, lxd/lxc, disk, shadow, adm, systemd-journal and libvirt. Prove the associated resource and effective permission.

Rootful Docker daemon with an available image

Requires daemon/socket access, a rootful daemon, usable image and allowed host bind mount. Rootless mode, user namespaces, authorization plugins and SELinux can change the effect.

LXD/LXC with an available image alias

Requires configured daemon access, sufficient group rights, image availability and privileged-container/device support.

Why it works

Controlling a rootful container daemon can grant host-mount operations; root inside a restricted/rootless container is a different authority. Socket presence alone proves no API access.

Worked example · hypothetical

Observation: docker group access reaches a rootful daemon. Test: inspect its available image and mount permissions using the documented procedure. Illustrative output: a controlled container can read the intended host filesystem. Interpretation: verify host context before claiming host root.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗