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

John Johansen john.johansen at canonical.com
Sat Jul 11 00:20:26 UTC 2015


On 07/10/2015 05:13 PM, Steve Beattie wrote:
> On Fri, Jul 10, 2015 at 10:20:38AM -0700, John Johansen wrote:
>> v2
>> escape \ and add a couple equality tests around it
>>
>> ---
>>
>> >From 17845cc6d9fd3b167e59394ddc3f53af4c919496 Mon Sep 17 00:00:00 2001
>> From: John Johansen <john.johansen at canonical.com>
>> Date: Fri, 12 Jun 2015 10:18:37 -0700
>> Subject: [PATCH] Fix: Expansion of profile name when it contains aare
>>  characters
>>
>> 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.
>>
>> BugLink: http://bugs.launchpad.net/bugs/1317555
>>
>> equality tests by
>>   Tyler Hicks <tyhicks at canonical.com>
>>
>> Signed-off-by: John Johansen <john.johansen at canonical.com>
> 
> This is an okay improvement, so Acked-by: Steve Beattie <steve at nxnw.org>
> but we really need to rethink the whole impedance mismatch between
> wanting to regex match labels and having labels that are described
> by regexes.
> 
> If nothing else, we should probably adjust our shipped policies to use a
> name when a match pattern contains a regex.
> 
We could start by spitting out a warning, about regexs in profile names
being deprecated, and to move to specifying an attachment

beyond that there is mapping we could do. It would be a little ugly but
is feasible




More information about the AppArmor mailing list