[apparmor] Deprecating attachment based profile names for apparmor 3

[John Johansen]

On 08/29/2018 06:35 AM, Simon McVittie wrote:
> On Tue, 28 Aug 2018 at 14:27:05 -0700, John Johansen wrote:
>> To avoid the warning profiles can be rewritten to use a name separate from the
>> attachment.
>>
>> profile ping /bin/ping {
>>   ...
>> }
>>
>> This transform should work on any apparmor release in the last 10 years (2.3
>> 2.13).
> 
> Is there a conventional name and filename for a profile with a name that
> does not reflect its attachment?
> 
generally the base name or the name its normally referenced by.


> For instance, in Debian's ioquake3 package I have:
> 
> # /etc/apparmor.d/usr.lib.ioquake3.ioquake3
> /usr/lib/ioquake3/ioquake3 flags=(complain) {
> ...
> }
> 
So I would probably go with

profile ioquake3 /usr/lib/ioquake3/ioquake3 flags=(complain) {
  ...
}

> Should I rename the file to /etc/apparmor.d/ioquake3 or something?
> Is the name meant to reflect the distro package, or the executable name,
> or something else?
> 
Generally in the past we have based it on the profile name with profile
names that are file based being transformed to loose the leading /
and internal / being replaced by . etc.

so usr.lib.ioquake3.ioquake3 from your example above. For profile names
that were not a file path, we have had a mix. Originally the tools
would create a file based on the word profile and the profile name,
so using the suggested transform

  profile.ioquake3

However while this has been the default for the tools to create, the
tools don't require it and will just read files if they exist and
associate the profiles inside to the file. There have been several
profiles that have received this transform, but kept the original
file name. eg. my firefox profile looks like

profile firefox /usr/lib/firefox/firefox{,*[^s][^h]} {

but its file name is /etc/apparmor.d/usr.bin.firefox

Basically it has been expedient not to change them.

> Similarly, should the name of the new profile reflect the distro package,
> or the executable name, or something else?
> 
Ideally it would be the best unique name to represent what the profile
is for. I know that is rather vague and different people or distros
may have different ideas.

But I can add a few rules
1. Try to be cross distro
2. Try to avoid collisions
3. It needs to be something the user can identify.
4. For application profiles it should use an applications name. This
   could be different from the executable. It could include other
   info.

However we do see profiles don't fit this pattern
   eg. snappy is using a naming scheme for its profiles with a "snap."
       prefix and the yaml app name appended.

       profile snap.meshlab.meshlab {

       with a file name of
       /var/lib/snapd/apparmor/profiles/snap.meshlab.meshlab

       its naming convention is consistent and snappy is doing most
       of the management for its profiles.

Another exception would be user confinement or role based profiles
where names like user_jj, role.log_admin or similar would be preferred

> (Note that in Debian- and Ubuntu-land, removing or renaming conffiles
> requires special maintainer action to preserve sysadmin changes, so we
> should preferably minimize the number of times we rename profiles.)
> 
agreed. For the moment I am not even proposing renaming profiles. We
certainly need to look into this but it can be done separate from
doing the profile name transition. And is something I would like more
feedback on from people who are more involved with packaging than
I am.