[apparmor] deny and selectively allow in AppArmor?

[Christian Boltz]

Hello,

Am Freitag, 7. August 2020, 19:07:41 CEST schrieb Jonas Große Sundrup:
> I have one question left, when we're at it: If I do have conflicting
> directives, such as
> 
>     /my/directory r,
>     /my/directory rw,
> 
> which one takes precedence? the first, the last, the stricter or the
> broader?

They get added up - so in your example, you'll get rw.

As another example,

  /foo rwl,
  /foo wk,

will effectively give you   /foo rwlk,

> In case of nested I'd suspect that AppArmor will just nest the
> policies accordingly, no matter in which order they occur, right?

The rule order doesn't matter.


> On 2020-08-06, Christian Boltz wrote:
> > You could do some trickery with regexes. Annoying, but still better
> > than having to deny each and every file separately. Something like
> >
> >this:
> > deny owner @{HOME}/,  # deny directory listing of the home directory
> > deny owner @{HOME}/[^.]**,
> > deny owner @{HOME}/[^.][^m]**,
> > deny owner @{HOME}/[^.][^m][^o]**,
> > deny owner @{HOME}/[^.][^m][^o][^z]**,

Looking at this again, I noticed a bug - it needs to be

deny owner @{HOME}/[^.]**,
deny owner @{HOME}/.[^m]**,
deny owner @{HOME}/.m[^o]**,
deny owner @{HOME}/.mo[^z]**,

> I thank you kindly for the proposal, but I think I'll avoid this
> approach. ;)

Good decision ;-)


Regards,

Christian Boltz
-- 
<jdstrand> [after 4 bugreports] that should be all of them
<cboltz> well, at least until there's an openSUSE kernel with stacking
         available ;-)
<jjohansen> cboltz: no, no, no, see this is why we can't upstream,
            cboltz will break everything
[from #apparmor]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20200807/c423d9d6/attachment.sig>