Add "inline" deny and add rule (ideny , iadd)

[Mark Smith]

This suggestion is to add a feature for ideny , inline deny rules. An ideny rule would not override all other allow rules, instead, it only overrides allow rules which are specified before it. This allows an allow rule following an ideny to override the ideny, creating an exception to it.

Currently, apparmor executes all allow rules first, creating an allow set. The deny rules are executed second, subtracting all deny rules from the allow set. This is fine in many cases.

However, we have found this model to be lacking in many respects and we prefer to have in certain cases allow to override deny rules. What we suggest is creating an inline deny. An inline deny is run in order with any allow rules around it. The inline deny removes objects from a running allow set, however, a later allow rule can add some or all of those objects back into the running allow set.

This can be critical in many cases and we do have use cases where this feature would save us time and is badly needed.

if we have a directory called /a1 and we allow rw /a1/**. /a1 contains thousands of objects but we want rw access to most of them. But within that we have a directory, /a1/b1, that we want to deny /a1/b1/** rw, . /a1/b1 also contains thousands of objects, we want to deny most. However, within /a1/b1 we have a file, /a1/b1/c1, an we want access to that file but want all other files in /a1/b1 to be denied. allow /a1/b1/c1 rw. Because the deny on /a1/b1 cannot be override by any kind of allow, we're really screwed over. We would have to get rid of the deny on /a1/b1 and make a massive number of deny rules for the thousands of objects in /a1/b1, and other unsavory options.

It would be far easier to do this:
/a1/** rw,
ideny /a1/b1/** rw,
/a1/b1/c1 rw,

This is really far, far more readable and easy to do than any other option. it is better to follow a mechanism not policy approach, that is providing this capability we request and letting us decide whether or not to use it according to our own needs.

[Mark Smith (norstar39)]

This really is a vital feature. The absence of this feature does create major problems in many use cases, making writing rules needlessly complex and difficult. The new rule would make apparmor more flexible to the needs of system administrators. I suggested adding a new inline deny rule, ideny, particular to avoid breaking backwards compatibility by preserving the current behavior of deny. the new functionality would only be used if the new ideny rule is used, otherwise everything works the same as it does now. This feature thus preserves backwards compatibility.