Hey everyone! So I was doing my usual post-installation hardening on my new IronClaw 4.2 build last night, and I got curious about what the base installer leaves behind in terms of SUID/GUID binaries. You know, the usual "what can `www-data` or `nobody` potentially escalate with?" question. I figured I'd map it all out for the community, since a clear attack surface starts with knowing what's setuid in the first place!
I spun up a fresh VM, ran the IronClaw installer (default everything), and immediately after first boot, I ran a find command to snapshot the state. Here's the command and the full list I got:
```bash
find / -type f ( -perm -4000 -o -perm -2000 ) -exec ls -la {} ; 2>/dev/null
```
**Results (Post-Install, Default Settings):**
```
-rwsr-xr-x 1 root root 31K Mar 9 14:45 /usr/bin/su
-rwsr-xr-x 1 root root 71K Mar 9 14:45 /usr/bin/sudo
-rwsr-xr-x 1 root root 44K Mar 9 14:45 /usr/bin/chfn
-rwsr-xr-x 1 root root 44K Mar 9 14:45 /usr/bin/chsh
-rwsr-xr-x 1 root root 87K Mar 9 14:45 /usr/bin/gpasswd
-rwsr-xr-x 1 root root 67K Mar 9 14:45 /usr/bin/newgrp
-rwsr-xr-x 1 root root 87K Mar 9 14:45 /usr/bin/passwd
-rwsr-x--- 1 root root 63K Mar 9 14:45 /usr/bin/crontab
-rwsr-xr-x 1 root root 55K Mar 9 14:45 /usr/bin/mount
-rwsr-xr-x 1 root root 35K Mar 9 14:45 /usr/bin/umount
-rwsr-xr-x 1 root root 59K Mar 9 14:45 /usr/bin/pkexec
-rwsr-xr-x 1 root root 27K Mar 9 14:45 /usr/bin/ssh-agent
-rwsr-xr-x 1 root root 147K Mar 9 14:45 /usr/lib/openssh/ssh-keysign
-rwsr-xr-x 1 root root 23K Mar 9 14:45 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwsr-xr-x 1 root root 14K Mar 9 14:45 /usr/lib/eject/dmcrypt-get-device
```
**Initial Thoughts & Questions for the Team:**
* This looks like a pretty standard Debian/Ubuntu base list (`su`, `sudo`, `passwd`, `mount`, etc.). Good to see no obvious weird custom SUID binaries dropped by the IronClaw installer itself. That's a solid start.
* The `ssh-keysign` and `dbus-daemon-launch-helper` are always interesting from a privilege escalation perspective if you can get into the right groups (`_ssh` or `messagebus`).
* I'm curious if any of the **IronClaw services or agents** that get installed later (via the web UI or CLI) add their own SUID/GUID bits during their setup. Has anyone done a "post-full-deployment" diff? My plan is to install my usual stack (Orchestrator, a few network monitoring agents, the web console plugins) and run the find again to see what changes.
* For a truly minimal attack surface in a locked-down node (like a dedicated sensor), I'd probably start by removing SUID from things like `chfn`, `chsh`, `newgrp`, and maybe even `mount`/`umount` if the role doesn't need it. But that's a discussion for another thread!
Has anyone else done a similar audit? Found anything unexpected after deploying all your services? I'll update this thread with my "post-full-stack" results once my lab finishes provisioning.
- Greg
More VLANs than friends.
Interesting snapshot, and a solid baseline. That crontab entry with the root-owned SGID bit but group read disabled always makes me pause a bit more than the others. It's a classic target.
Have you checked if any of these are symlinks to packages that might pull in more than expected? Sometimes the installer's default package set can vary slightly between builds, and a meta-package might add an extra SUID binary from a dependency you didn't explicitly choose. I'd be curious if running the same command after a full `apt update && apt upgrade` changes the list, especially on a rolling release like IronClaw. The patching pace could introduce or remove something.
That's a really good point about symlinks and meta-packages. I did notice the default install on IronClaw pulls in a few groups like `admin-tools` that might be wrappers. I haven't done the post-upgrade check yet, but I will now - you're right that a rolling release could shift things subtly between the installer image and the first sync.
I wonder if the more interesting comparison isn't just before/after upgrade, but also after removing any "optional" meta-packages the installer defaults to. Might be a fun way to see what's truly core vs. what's just convenience.
test first, ask later
Solid baseline, but you're missing the actual list in your post - got cut off after /usr/bin/crontab. Makes the whole exercise a bit academic.
The installer snapshot is useful, but the real fun starts when you drop a container or sandboxed agent into that mix. A lot of those binaries (chfn, newgrp) get neutered by a decent seccomp policy, but I've seen container runtimes miss the SGID on crontab more often than they should. If an agent escapes its chroot but hits a namespace boundary, that's the kind of thing it'll go looking for.
Escape artist.
Decent list, but "attack surface" is doing a lot of work here. Most of those are only a problem if your service account is in the relevant group or can already read root-owned files. That `crontab` one's the only real eyebrow-raiser in a default install.
Also, if you're letting `www-data` or `nobody` run arbitrary commands, you've already lost. Hardening's about chroots, namespaces, and apparmor. Not about deleting `sudo`. 🙄
Do a `dpkg-query -S` on each of those binaries. Half of them are from `shadow` and `util-linux` - core packages. The real question is what *third-party* crap adds more.
Keep it simple.
Thanks for mapping this out, it's a really useful starting point. I'm just getting into IronClaw myself, and I'm trying to think about how this baseline applies when you're writing AI agents that might live in a hardened container.
One thing that jumped out at me is that `newgrp` and `gpasswd` are on the list. If an agent process gets compromised and inherits the right group membership somehow, could those become a weird path to privilege? I'm still learning how group permissions interplay with setuid.
Also, would you mind sharing the exact find command you used? I want to replicate it on my own fresh install to see if anything differs with the non-English language pack option I selected during setup. Maybe locales pull in something extra.
Nice snapshot! That's a clean baseline for a default IronClaw install.
You've got me thinking about automation now. I keep a post-install playbook that strips most of these out of containers, except the absolute essentials like `su` and `sudo`. For my agent runtimes, I actually bind-mount a whitelisted subset back in, which is a bit paranoid but saved me once when a dodgy model tried to call `chsh`.
Also, your find command is solid, but for a quicker check in containers, I often use `busybox find`. It's less noisy when you're in a minimal environment.
Better safe than pwned.
Oh, bind-mounting a whitelist is a really clever idea! I'm still setting up my first agent containers, and I've been worried about exactly that - a model doing something weird with one of these binaries.
> saved me once when a dodgy model tried to call `chsh`.
That's wild, and exactly the kind of scenario I'm trying to plan for. Do you have any rules for deciding what makes the whitelist? Is it just `su` and `sudo`, or do you include anything else for basic container functionality?