[apparmor] Splitting unlink from write

[Zygmunt Krynicki]

W dniu 27.11.2025 o 02:29, John Johansen pisze:
 > On 11/26/25 05:17, Zygmunt Krynicki wrote:
 >> Hello
 >>
 >> I'd like to propose splitting the textual permission "w", so that it
 >> does not imply AA_MAY_DELETE if the file is a device, fifo or socket.
 >> Profiles routinely grant "w" permission, but nobody in their right
 >> mind expects applications to delete such files.
 >>
 > this has been planned and is supported on the backend. We still need to
 > fix the frontend (long term todo that is coming)
 >
 > The question is how to deal with it in policy, there are basically two
 > ways, introduce finer permission to policy that can be used along side
 > the current.
 >
 > Or stick it behind an abi flag. The abi flag seems like a cleaner
 > solution to me

I think the ABI flag is far cleaner. The desire to allow this uncommon 
behavior is small. Porting policy should be straightforward.

How do you think this would look like in the profile text? ABI 5.1 that 
sets it by default? A flags=(...) field that one needs to use to opt 
into one or the other behavior (cond-allow-all or cond-allow-regular)?

 > Well the plan here was to actually expose fifo/socket/link/.. as a rule
 > conditional. Then you don't need a special MAY_DELETE, you just need
 > delete, and the correct conditional.
 >
 > For compatibility we map the permissions, and the conditional is just
 > defaulted to all types.
Ah, so is that what the Perms.Cond field is for?

What might the encoding look like? Each element class would get a 
distinct bit, so a rule like:

allow file type=regular /foo delete

Would grant AA_MAY_DELETE but also set, say, AA_COND_FILE_REG bit in the 
Perms.Cond field?

Then conversion from the current policy to n+1 policy would set all the 
bits to one?

 >> On the userspace side we might define new syntax such as:
 >>
 >> allow file PATH D,
 >>
 >> Where D implies delete special.
 >>
 > I was thinking more of using
 >
 >    allow file type=file /foo delete,
 >
 >    allow file type!=char /foo delete,

I like this approach much better, the type would then be a set of 
possible values, with every combination being encoded into the cond field.

Do we have any patches towards this? I think the kernel side is somewhat 
straightforward (assuming my hunch on how to use the cond field 
applies). The frontend is also rather simple. The backend I don't know 
because I spent only a fraction of time there, so far :)

Best regards
ZK