[apparmor] Deprecating attachment based profile names for apparmor 3

[Christian Boltz]

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).

> 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.

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 ;-)

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? ;-)


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?

Oh, and aa-status currently only displays the profile name, not the 
attachment - which is not too helpful with name != attachment ;-)


Regards,

Christian Boltz
-- 
Aus technischen Grunden befindet sich die Signatur
auf der Rückseite dieser Mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180829/1d5ec8c0/attachment.sig>