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
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor