[apparmor] [patch] aa.py: change_profile vs. changes_profile

John Johansen john.johansen at canonical.com
Mon Dec 22 14:06:55 UTC 2014


On 11/29/2014 05:18 AM, Christian Boltz wrote:
> Hello,
> 
> Am Freitag, 28. November 2014 schrieb Steve Beattie:
>> There's some really wonky behavior for view differences when doing so
>> (with or without the patch applied):
>>
>> --- /tmp/home.ubuntu.tmp.spork.sh 2014-11-28 23:07:50.769388829 -0800
>> +++ /tmp/tmpj6ytsskb    2014-11-28 23:09:56.641365708 -0800
>> @@ -13,9 +15,26 @@
>>
>>
>>    profile /bin/touch flags=(complain) {
>> +    /bin/cat rCx,
>> +    /bin/rm rix,
>> +
>>      #include <abstractions/base>
>>
>>      /bin/touch mr,
>>
>>    }
>>  }
>> +
>> +  profile /bin/cat flags=(complain) {
>> +    #include <abstractions/base>
>> +
>> +    /bin/cat mr,
>> +
>> +  }
>> +
>> +  profile /bin/touch flags=(complain) {
>> +    #include <abstractions/base>
>> +
>> +    /bin/touch mr,
>> +
>> +  }
>>
>> Note how the child profile for /bin/touch is getting re-added .
>> Furthermore, the /bin/cat and /bin/rm rules that get added to the
>> first instantiation of the /bin/touch profile belong in the parent
>> profile, not any of the children. However, the clean diff generates
>> the correct output:
>>
>> --- /tmp/tmpp9dstlgb    2014-11-28 23:37:32.193515557 -0800
>> +++ /tmp/tmpxn5pm9t8    2014-11-28 23:37:32.193515557 -0800
>> @@ -3,6 +3,8 @@
>>    capability dac_read_search,
>>
>>    /bin/bash ix,
>> +  /bin/cat rCx,
>> +  /bin/rm rix,
>>    /bin/touch rCx,
>>    /dev/pts/7 rw,
>>    /dev/tty rw,
>> @@ -11,6 +13,13 @@
>>    /tmp/spork.data a,
>>
>>
>> +  profile /bin/cat flags=(complain) {
>> +    #include <abstractions/base>
>> +
>> +    /bin/cat mr,
>> +
>> +  }
>> +
>>    profile /bin/touch flags=(complain) {
>>      #include <abstractions/base>
>>
>> which is what is written out as well.
> 
> (V)iew changes aka non-clean diff has known issues with child profiles, 
> see https://bugs.launchpad.net/apparmor/+bug/1394788
> 
> However, I'm surprised that it also mixes entries for the main profile 
> into a child profile - I didn't notice that until now.
> 
> Can you please open another bugreport? (if possible/not too difficult, 
> include a reproducer.)
> 
https://bugs.launchpad.net/apparmor/+bug/1404893

> I'm quite sure the problem is in the handling of RE_PROFILE_START in 
> serialize_profile_from_old_profile() which sets in_contained_hat = True 
> only if it finds "profile .*" (aka matches[3]), but doesn't do it 
> without the "profile" keyword. (Does your old profile contain the 
> "profile" keyword for the subprofiles?)
> 
the profile, hat or ^ symbol are required for a subprofile or the
specialized hat subprofile, the parser will reject the profile otherwise.
So knowing that and looking at the above diff output with is using
the profile keyword I would say yes.

However this does bring up and interesting point, if the profile
keyword is required by the re, how is it at handling 'hat' and '^'?

> Just a wild, untested guess (around line 3849):
> 
>             if RE_PROFILE_START.search(line):
>                 matches = RE_PROFILE_START.search(line).groups()
> -                if profile and profile == hat and matches[3]:
> +                if profile and profile == hat:
> -                   hat = matches[3]
> +                   if matches[3]:
> +                        hat = matches[3]
> +                   else:
> +                        hat = matches[1]
>                     in_contained_hat = True
>                     if write_prof_data[profile][hat]['profile']:
>                         pass
> 
> Feedback welcome ;-)
> 
sorry, I am going to stick this into the back of the queue with the
other outstanding aa.py patches




More information about the AppArmor mailing list