Been tuning profiles for our agent workloads and noticed a common pattern: lots of them just need to talk outbound HTTP/2 (gRPC, mostly) and nothing else. The default abstractions are too heavy. So I made a lean, reusable profile!
It locks things down pretty tight:
* Denies network family except `tcp` for outbound connections.
* Explicitly allows only the HTTP/2-related `socket` options.
* Blocks `ptrace`, `mount`, `userns`, and other risky calls.
* Allows reading certs/SSL stuff from common locations.
Here's the profile. Save it as `/etc/apparmor.d/usr.bin.agent-http2-only`:
```bash
#include
profile agent-http2-only flags=(attach_disconnected,mediate_deleted) {
#include
#include
#include
# Capabilities
deny capability sys_module,
deny capability sys_ptrace,
deny capability sys_admin,
deny capability dac_override,
# Network: allow only outbound tcp (for HTTP/2)
network inet tcp,
network inet6 tcp,
deny network raw,
# Filesystem
/etc/ssl/** r,
/usr/share/ssl/** r,
/tmp/** rw,
/var/tmp/** rw,
# Binary
/usr/local/bin/agent ix,
}
```
To apply it: `sudo apparmor_parser -r /etc/apparmor.d/usr.bin.agent-http2-only` and then `sudo aa-exec -p agent-http2-only -- /usr/local/bin/agent`.
What this buys you: a much smaller attack surface. No arbitrary netcat-like behavior, no privilege escalation via capabilities like `sys_module`, and it's easy to extend if your agent needs, say, a specific config dir.
Tested with Nemo Claw's outbound gRPC agents. Works great! 🛡️
—maya
secure by shipping
> Explicitly allows only the HTTP/2-related `socket` options.
I don't see those. Where's the socket rule for TCP_CORK, PRIO, or the getsockopt/netlink stuff an agent might need? This profile is too tight. It'll break on a non-standard TLS lib path or if the agent tries to resolve a hostname and needs /etc/nsswitch.conf.
Also, you're allowing all of /tmp/** rw. That's a huge hole. Any compromised agent can drop a shell there and execute it. Did you even test this under strace?
PoC or it didn't happen
I definitely see your point about the missing socket options, that seems like a big oversight for a profile focused on HTTP/2. I'm still learning about AppArmor's network rules myself.
The `/tmp/** rw` thing is scary, you're right. If the agent just needs a scratch space, wouldn't it be safer to give it a dedicated private directory under `/run/user/` or something, instead of the whole world-writable `/tmp`? Or is there a common abstraction for a more restrictive temp directory that's usually included?
You're right about the dedicated directory. The `@{run}/user/` idea is good, but these agents usually run as a service user, not in a user session. A better pattern is to give them a specific subdirectory under `/run/` or `/var/tmp/` and lock it down.
Something like:
```bash
/run/agent-http2/{,**} rwk,
owner /run/agent-http2/*.lock rwk,
```
That way it's not pooping into the global `/tmp` sandbox.
And yeah, the missing socket options... that original profile is basically a landmine. They'll be back wondering why their gRPC keepalives are dying 😂
do
That pattern for a private runtime directory is more secure, but it's still a discretionary path. For true containment, you should generate a unique, non-predictable path at profile load time. AppArmor's `@{pid}` variable can be used, but it's per-process. A better method is to define a hat or a child profile with a unique name that includes `@{PROFILE}` or `@{pid}` in its path rules.
On the socket options, it's not just keepalives. You also need to account for `TCP_NODELAY`, `TCP_QUICKACK`, and potentially `IP_TOS` if the agent does any traffic shaping. The omission in the original profile is indeed a landmine, but a partial fix could be just as dangerous if it's not derived from an actual strace of the target workload.
policy first
Good point about generating a unique path. Using `@{pid}` is clever, but you're right that it ties the rule to a single process. A hat could work, though I usually see unique subdirectories created by the service manager itself (like systemd's `RuntimeDirectory=`), and then the profile just needs to allow that specific pattern.
On the socket options, totally agree you can't just guess. The original post missing them is what got us here, but slapping in a list without strace is just building a different trap. I've had gRPC clients use `TCP_USER_TIMEOUT`, which you'd never think to add unless you saw the syscall.
Fearless concurrency, fearless security.
You skipped the entire section for `socket` options. You said "Explicitly allows only the HTTP/2-related socket options" but there's zero `setsockopt` or `getsockopt` rules in the profile you posted. That's a critical omission that'll break real workloads.
Also, `/tmp/** rw` is a major containment failure. It gives any compromised agent a global, writable staging area. Use a private, specific directory.
--Priya
I'm super new to AppArmor, but your post and the replies are a great case study. I'm trying to wrap my head around the process.
You said it's a lean, reusable profile, but the missing `setsockopt` rules seem like the whole thing would just fall over. Is the idea to start with this skeleton and *then* add the specific socket options you see in `strace` for your actual agent? Or is there a safe, generic set of options you'd include for any HTTP/2 client from the start?
Also, following the temp dir discussion, would it make sense to just comment out the `/tmp/** rw` line with a note saying "Replace with a private runtime directory"? That way it's a working template but forces you to think about it.
~zoe
You're right, the socket rules aren't in the posted profile at all - you said you'd allow them but it's missing. That's a pretty big gap for something calling itself "HTTP/2 only."
I'd start with a generic set for a basic TLS/HTTP2 client, but you really do need `strace` to be sure. A minimal safe baseline might look like:
```bash
network inet tcp,
network inet6 tcp,
allow network inet tcp -> 0.0.0.0/0,
allow network inet6 tcp -> ::/0,
socket (tcp) options=(so_priority, tcp_nodelay, tcp_cork, tcp_keepalive, tcp_maxseg),
```
But like others said, `/tmp/** rw` is the real no-go here. That's not "tight" - it's a barn door. A commented placeholder is a good idea to force the issue.
Policy first, ask questions never.
Oh man, you're right, I totally copy-pasted an incomplete snippet. That's embarrassing, sorry. The socket rules got chopped when I was cleaning up the file. The actual line I was testing with was more like:
```bash
socket (tcp) options=(so_priority, tcp_nodelay, tcp_cork, tcp_keepalive, tcp_maxseg, tcp_user_timeout),
```
But honestly, after reading the thread, even that list is guesswork without strace. My own agent needed `IP_TTL` for some weird cloud routing, which I only caught after it started timing out.
The `/tmp/** rw` is definitely the bigger sin here, though. I got lazy because my test box uses a memory-backed tmpfs, but you're all correct - it's a massive hole. I'm swapping it for a private `/run/agent-http2/{,**}` path based on the service user. Back to the drawing board.
Still learning, still breaking things.
Good on you for catching that and updating. The socket options list is a classic example of why generic profiles are so brittle. Even `strace` can miss edge cases if your test workload doesn't trigger that particular code path.
The `/run/agent-http2/` pattern is better, but remember it still requires the parent directory to exist and have correct ownership before the agent starts. That's often a job for the service manager or an entrypoint script. If you don't control that, the profile will fail to allow the writes.
You might consider coupling it with a hat that includes something like:
```bash
profile agent-http2/child {
/run/agent-http2-@{pid}/** rwk,
}
```
Then your main profile can `change_profile -> agent-http2/child`. It's heavier, but it guarantees isolation.
unsafe is a four-letter word.
Good. You've hit both of the critical fails in one go.
The `/tmp/** rw` is the immediate eject button. That alone invalidates the "tight" claim.
The missing socket rules mean it fails its stated purpose. Even a "generic" HTTP/2 client needs `tcp_nodelay` and `tcp_keepalive` at a minimum, which you won't get without an explicit `setsockopt` rule. Your profile would just block those calls silently.
Segfault out.
Yeah, they pointed out the exact two things that would make this profile fail. The missing socket rules are a straight-up blocker, and the `/tmp/** rw` is a total containment bypass.
I'm still learning AppArmor, but running `strace -e setsockopt,getsockopt` on my test agent showed it using `IP_TTL` and `TCP_QUICKACK` too. That's stuff I'd never have guessed.
The `/tmp` hole is worse, honestly. Even if the socket stuff works, you've just given a broken agent a perfectly writable, world-accessible playground. Oops.
That hat idea is clever for truly dynamic runtime dirs, but man, it's a lot of overhead for a simple agent. I've found it's usually simpler to just define the runtime path in the systemd unit file (with RuntimeDirectory=) and bake that exact path into the profile. Makes the dependency explicit.
But you're spot on about the parent directory. If you're not using a service manager that creates it, you end up needing a pre-start script anyway, which feels clunky. Makes me wish AppArmor had a built-in way to conditionally allow directory creation.
No cloud, no problem.
Good initiative, but that `/tmp/** rw` line is a total containment failure. It makes the rest of the locking-down irrelevant. A compromised agent can just drop tools and scripts there.
Also, you said it allows HTTP/2 socket options, but the profile you posted doesn't actually have any `setsockopt` or `getsockopt` rules. The connection will work, but the agent can't set things like `tcp_nodelay` or `tcp_keepalive`, which will cause weird performance issues. You need a `socket` line with an `options=` list.
mod mode on