[apparmor] Deprecating attachment based profile names for apparmor 3

[John Johansen]

On 08/29/2018 01:51 PM, Christian Boltz wrote:
> Hello,
> 
> let me play devil's advocate ;-)
> 
> Am Mittwoch, 29. August 2018, 17:22:47 CEST schrieb John Johansen:
>> 1. It tends to result in shorter profile names, which is good for
>> display in the above mentioned utilities, and even more so when
>> stacking and delegation are taken into consideration.
> 
> This also means that it's easier to create a name collision (same 
> profile name for two profiles for different attachments / programs).
> 
true, but its also not hard to differentiate them either

>> 2. It makes for more cross distro profile names. As programs my be
>> stored in different locations. Several rule types allow specifying a
>> target label which means updating policy for a location change also
>> means updating all policy rules that reference the profile name as a
>> label.
> 
> Right, but we still need to cover the attachment path (and possibly 
> paths inside the profile) with variables or alternations, so the main 
> thing we win is a "readable" profile name.
> 
yes, attachment paths within rules still need to be used

> Just as a _completely crazy_ idea - a "magic" variable like
>     @{attachment_of ping} Px,
> which would "expand" to
>     /{usr/,}bin/ping Px,
> could in theory help, but that probably means that parsing a profile 
> needs reading _all_ profiles, and I can imagine that this will open a 
> very big can of worms ;-)
> 

we certainly could have an @{attachment} variable similar to what we
do with @{profile_name}, the proposed magic @{attachment of X} is
harder if X is not the profile being computed, as you say it would
require that the X profile be compiled at the same time as the profile
referencing via @{attachment of X}

Its not a bad idea, but has limited use in the current compilation
model. We certainly do want to move towards compiling more profiles
as a unit as that allows for more optimizations/sharing but we aren't
ready yet.


> The only way this could work in a somewhat sane way is expanding it in 
> the kernel - and even then, I'm not sure if I really want to allow a 
> profile to influence another profile's rules by changing the attachment. 
> (Since I'm already in devil's advocate mode - would this be done before 
> or after implementing the kernel-side @{pid} variable? ;-)
> 
after/at the same time - they both rely on largely the same work, with
only minor changes to on how the kernel generates the specific variable
reference.

> 
> Bonus questions:
> 
> What should aa-logprof and aa-genprof do when a new profile gets 
> created? Ask the user which profile name should be used? Or have some 
> "clever" method to choose one?
> 
I would think it could default to the base name (last component of
the path) which usually is the name the program is known by and
give the user an option to modify it.

> Oh, and aa-status currently only displays the profile name, not the 
> attachment - which is not too helpful with name != attachment ;-)
> 
sounds like a feature request, I'll take care of the kernel bits if
you take care of the userspace ;-)