[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