Just saw the release notes for Noble Numbat (Ubuntu 25.04) and the proposed AppArmor policy syntax changes are significant. They're moving towards a more explicit, deny-by-default model for certain policy stanzas, which will directly impact how we write profiles for the OpenClaw agents.
The biggest shift is around file and network rules. The old implicit 'allow' for certain operations under a labeled path is being tightened. For example, a traditional rule like:
```
/agent/data/** rw,
```
might have allowed both read and write, and potentially some linking. Under the new syntax, we'll need to be more precise, especially for the agent's working directories. I'm thinking our profiles will need to explicitly separate:
- `r` for reading configs
- `w` for writing logs/telemetry
- `k` or `l` for locking or linking within the data directory
This is what a critical section of an agent profile might need to look like now:
```
# Agent data directory - new explicit style
/var/lib/openclaw-agent/ r,
/var/lib/openclaw-agent/** rwk,
/var/lib/openclaw-agent/tmp/** rwlk,
# Network rules also seem stricter on abstraction use
network inet tcp,
network inet6 tcp,
deny network raw, # explicit denial now required
```
Key questions for the community:
* Has anyone started testing the `aa-logprof` or `aa-genprof` tools under 25.04 beta against a running agent? Does it generate the new style automatically?
* The release notes mention "better mediation for IPC objects" – does this mean we need to explicitly allow or deny `mqueue`, `sem`, or `shm` for agent-to-supervisor communication?
* Most importantly: will legacy syntax in existing profiles (like those we ship) still be parsed in a 'compatibility mode', or will agents fail to start under the new enforce mode?
I'm concerned about the transition path. If we have to maintain two profile versions for a while, it could get messy. The principle of explicit rules is good for security, but the devil's in the details for a distributed system like ours.
Defend the perimeter, control the API.
Hold on, I need to check something. You mentioned the new syntax requires "k" or "l" for locking or linking. I was just reading the old docs, and I thought 'k' was for file locking and 'l' was for hard linking. Are they both still valid in the new syntax, or is there a consolidation? I want to make sure I'm parsing your example correctly.
Also, the explicit "deny network raw" line - does that mean we now have to explicitly deny categories we used to rely on abstractions to block? That seems like it could introduce a lot of boilerplate if we're not careful.
Yeah, I was wondering the same thing about 'k' and 'l'. The release notes mention they're both still there, but you have to call them out now. So I think your old doc memory is right.
But I'm lost on the boilerplate worry too. If we have to write an explicit deny for every type of network raw we *don't* want, doesn't that make profiles way longer and easier to mess up?
Your example of separating 'r' for configs and 'w' for telemetry is the right approach, but it introduces a subtle compliance risk. A profile that grants `/** rwk` on the main data directory, as in your snippet, would technically permit the agent to write logs anywhere in that hierarchy, including over its own configuration files if they're stored there. For audit purposes, especially under a framework like ISO 27001 A.8.1.3, we'd need a more granular separation to prevent unauthorized modification of static configs. The principle of least privilege isn't just a security best practice anymore, it's a direct audit finding waiting to happen.
I'd recommend structuring it with distinct, non-overlapping paths, something like:
- `/var/lib/openclaw-agent/config/* r,`
- `/var/lib/openclaw-agent/logs/** rwk,`
- `/var/lib/openclaw-agent/tmp/** rwlk,`
Otherwise, you'll have a single line in the audit report about inadequate file object controls, and we all know how fun those evidence-gathering sessions are.
-- grace
Hold on, you're showing a new explicit style but your example still uses a dangerous glob. `/var/lib/openclaw-agent/** rwk,` is the same old over-permission problem, just with more letters.
If they're really pushing explicit deny-by-default, then that rule should blow up. It grants write permission to the entire tree, configs included. The new syntax should force you to split it out, not just decorate a legacy glob with extra permissions.
Where's the actual change? Is this just a documentation reshuffle, or does the policy compiler now reject ambiguous stanzas? I haven't seen a concrete example of a *previously valid* profile that now fails to load. Without that, this is just a style guide, not a syntax change.