aa-logprof crash - AARE unbalanced parenthesis

Thanks for the report!

Can you please attach your firefox profile and the log (at least the relevant log lines) that cause this crash?

I can roughly imagine where this crash comes from, but having a reproducer makes things much easier. Yes, this is python related - most aa-* tools are written in python.

BTW: Which AppArmor version do you use? (I'm using openSUSE, so I have no idea what is in Ubuntu 17.04 ;-)

I have experienced same problem on Kubuntu 16.04.

aa-logprof asked if to add ptrace for firefox:
Profile: /usr/lib/firefox/firefox{,*[^s][^h]}
Access mode: trace
Peer: /usr/lib/firefox/firefox\{,\*\[^s\]\[^h\]\}

 [1 - ptrace trace peer=/usr/lib/firefox/firefox\{,\*\[^s\]\[^h\]\},]
(A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish

I allowed, and after this line appeared in usr.bin.firefox profile:
trace trace peer=/usr/lib/firefox/firefox\{,\*\[^s\]\[^h\]\},

I get this "sre_constants.error: unbalanced parenthesis at position 59"

Attaching profile that makes aa-logprof crash.

Looks like aa-logprof add redundant reverse slashes? These line works OK:
  ptrace trace peer=@{profile_name},
or:
  ptrace trace peer=/usr/lib/firefox/firefox{,*[^s][^h]},

Vincas, as a workaround you can give the profile a much better name by using:

profile firefox /usr/lib/firefox/firefox{,*[^s][^h]} {
...
}

This will use the profile name 'firefox' is is legible and can be easily used for peer= statements.

Thanks

AFAICT there are possibly two issues with aa-logprof (not apparmor itself!) here. I'm confident that the second is a bug, I'm not sure that the first is.

1. aa-logprof _possibly_ unnecessarily† escapes the special characters (`*{[` etc.) with backslashes in the profile name in the "peer" statement. (e.g. The profile name is `xxx*xxx`, and the suggested peer statement becomes `ptrace trace peer=xxx\*xxx`)

† I haven't extensively checked apparmor's behaviour with and without escaping all of the special characters.

This is caused by `convert_expression_to_aare` (in `aare.py`) which escapes all such characters in expressions taken from logs.

To reproduce:

For instance take a profile in file `usr.bin.foo`

```
/usr/bin/foo* {
  # Arbitrary rule, so that the profile is non-empty.
  /** rw,
}
```

and a log:

```
Dec 8 18:42:06 adam kernel: [320732.937499] audit: type=1400 audit(1638985326.875:800): apparmor="DENIED" operation="ptrace" profile="/usr/bin/foo*" pid=293238 comm="foobar" requested_mask="trace" denied_mask="trace" peer="/usr/bin/foo*"
```

and call `aa-logprof -f log -d path/to/profile`.

Observed behaviour:

aa-logprof suggests this new rule:

```
  ptrace trace peer=/usr/bin/foo\*,
```

with the asterisk escaped.

2. aa-logprof doesn't consider backslashes in peer rules when processing the profiles.

`convert_regexp` (in `common.py`) converts glob characters like `*`, `**`, `{}`, `,` into appropriate regex patterns, according to special rules (e.g. `*` becomes `(((?<=/)[^/\000]+)|((?<!/)[^/\000]*))` ). This happens even if the glob character is escaped with a backslash[0]. Hence, for instance `/usr/bin/foo\*` becomes the python string

    '^/usr/bin/foo\\(((?<=/)[^/\x00]+)|((?<!/)[^/\x00]*))$'

(note that since this is a python string the `\\` represents a single backslash). The interesting part of the pattern is:

    '\\(...)'

The cause of the aa-logprof crash is that the opening parenthesis is escaped (with the `\\` backslash), while the closing one isn't (resulting in the error message "unbalanced parenthesis").

[0] https://gitlab.com/apparmor/apparmor/-/wikis/AppArmor_Core_Policy_Reference#apparmor-globbing-syntax

To reproduce:

For instance take a profile in file `usr.bin.foo` (with the peer pattern generated by aa-logprof):

```
/usr/bin/foo* {
  ptrace trace peer=/usr/bin/foo\*,
}
```

and a log:

```
Dec 8 18:42:06 adam kernel: [320732.937499] audit: type=1400 audit(1638985326.875:800): apparmor="DENIED" operation="ptrace" profile="/usr/bin/foo*" pid=293238 comm="foobar" requested_mask="trace" denied_mask="trace" peer="/usr/bin/foo*"
```

and call `aa-logprof -f log -d path/to/profile`.

Solving this issue correctly would result in a very tricky set of regular expressions, though.