[apparmor] [PATCH 3/3] Fix: Expansion of profile name when it contains aare characters

[John Johansen]

On 06/19/2015 07:31 PM, Steve Beattie wrote:
> On Fri, Jun 19, 2015 at 06:34:19PM -0700, John Johansen wrote:
>> On 06/18/2015 03:52 PM, Steve Beattie wrote:
>>> On Wed, Jun 17, 2015 at 04:21:13AM -0700, John Johansen wrote:
>>>> When @{profile_name} is used within a rule matching expression any
>>>> aare expressions should be matched literally and not be interpreted as
>>>> aare.
>>>>
>>>> That is
>>>>   profile /foo/** { }
>>>>
>>>> needs /foo/** to expand into a regular expression for its attachment
>>>> but, /foo/** is also the profiles literal name.  And when trying to
>>>> match @{profile_name} in a rule, eg.
>>>>   ptrace @{profile_name},
>>>>
>>>> the variable needs to be expaned to
>>>>   ptrace /foo/\*\*,
>>>>
>>>> not
>>>>   ptrace /foo/**,
>>>>
>>>> that is currently happening.
>>>
>>> What happens if someone for example writes a profile for /usr/bin/[ ?
>>>
>> the regex conversion fails and you get a lovely error message
>> apparmor_parser: Regex grouping error: Unclosed grouping or character class, expecting close }
>> apparmor_parser: Unable to parse input line '/usr/bin/['
>> apparmor_parser: Invalid profile name '/usr/bin/[[' - bad regular expression
>> ERROR processing regexs for profile /usr/bin/[, failed to load
>>
>> if you want the regex chars to be not interpreted then you need to escape them
>>
>> so
>> /usr/bin/\[ { } results in
>> a successful compile
> 
> so if one writes:
> 
>   /usr/bin/\[ {
>     signal peer=@{profile_name},
>   }
> 
> does the patch you posted not convert that @{profile_name} into
> "/usr/bin/\\[" ?
> 
> That was the point of my insufficiently fleshed out question.
> 
> 
yeah, this is broken. v2 is in progress