[apparmor] Asking for best practice on upgrading in regard to named profiles

[Christian Boltz]

Hello,

Am Dienstag, 15. Januar 2019, 11:11:49 CET schrieb Christian Ehrhardt:
> today I saw an interesting patch to libvirt [1] (thanks Jim) that made
> me think more about proper migration through those changes.
> 
> TL;DR:
> - profile A with binary-path
> - profile B referencing peer A by binary-path
> - profile A gets updated to now have name + binary-path
> - profile A gets loaded by name now
> - will profile B no more "find" it's reference in the peer statement
> as it "only" references the binary-path?
> 
> Details:
> So to me [1] seems safe and it tells me that "if you are unsure what
> your peer is using" then the way to go is to duplicate the rules
> keeping the binary-path and adding the named reference in addition.
> Some proliferation, but otherwise safe in terms of package upgrades.

Right, duplicating rules with peer= is the recommended way to support 
the "old" path-based profile name, and the "new" named profile.

The perfect migration path is:

1) add a   peer=foo   rule  whereever you have   peer=/foo
2) wait until everybody has the updated profile
3) change "/foo {" to "profile foo /foo {"
4) wait even longer
5) optional - remove   peer=/foo   rules once you are very sure nobody 
   needs them anymore

After 3) profiles with only   peer=/foo   will break / cause denials.

If all affected profiles are shipped in one package, the risk of 
breakage is much lower and you can skip the "wait" steps. For example, 
we did this with the dovecot profiles and abstraction which are all in 
the apparmor git repo and end up in the same tarball.

> But then there also is [2]. The change here first looks similar with:
> - the first hunk referencing name+binary-path via the {profile_name}
>   (I guess that is what it does)

That should be   @{profile_name}   (note the "@"). 
It's correct in https://bugzilla.opensuse.org/show_bug.cgi?id=1118952#c3 
so I guess it's just a broken "try hiding that mail address" attemp in 
the list archive.

> - The second hunk again doing the proliferation to list path & name

That part is inside a child profile - and since we don't have a variable 
for "parent profile", it needs to be done that way.

> Feel free to correct me above if my assumptions were incorrect
> already. But what I wondered about mostly was the hint that using [2]
> might need some coordination with apparmor (e.g. on package
> dependencies) to quote "... since the dnsmasq profile currently has
> 'peer=/usr/sbin/libvirtd'"
>
> Now I wonder, if a profile has name and binary-path like in [2]
>     profile libvirtd /usr/sbin/libvirtd
> and another profile was referencing it with the old path, in this case
> "/usr/sbin/libvirtd", but the new profile is now loaded "by name"
> will the profile of dnsmasq no more "recognize" it's peer.

Correct, that's why I submitted
https://gitlab.com/apparmor/apparmor/merge_requests/304 ;-)


Regards,

Christian Boltz
-- 
"If you spend more on coffee than on IT security,
then you will be hacked. [Richard A. Clarke / 2002]
-------------- 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/20190115/b5ca606c/attachment.sig>