Upstream AppArmor should be configurable to follow symlinks

[tabbott]

If we DEB_DIVERT_FILES something permitted in an AppArmor profile, an AppArmor'd application can't follow the symlink and read the target .debathena file. We've introduced a workaround for the egregious case here, but we really should simply be able to modify the profile to say that it should follow symlinks on that file... and then upstream that patch to the profile.

(Originally this bug was "Report /etc/krb5.conf apparmor issue upstream", "r23642 introduced a workaround for apparmor complaints about /etc/krb5.conf being a symlink. We should report the issue upstream.")

[geofft]

 https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/132468
and
 https://bugs.launchpad.net/ubuntu/+source/openldap2.3/+bug/203898

are two cases where Ubuntu ran into this issue themselves. In the first case they added /var/run/resolvconf/resolv.conf to the AppArmor? profile; in the second case they switched to hardlinks. On the assumption that hardlinks are not an option for Debian diversions, what we're doing now (diverting and transforming the AppArmor? profile) appears to be what we should do.

dtchen, some dude on #ubuntu-devel, indicated that he was interested in seeing this too, so proposing something to upstream to solve this in general wouldn't be out of the question.

This is, though, slightly harder than "AppArmor? should follow symlinks" -- it is certainly the case that a program protected by AppArmor? that needs to write to a config file in your homedir _shouldn't_ follow symlinks, if it's able to create that file as a symlink to some arbitrary other place. Perhaps we can mark /etc/krb5.conf (being in a safe directory) as a file that is safe to follow symlinks through, with another AppArmor? permission.

[lfaraone]

Also affects evince starting firefox

[jdreed]

I feel like transforming the profiles is sort of the right answer in some cases. It's unclear to me that any symlink solution will work, because (though I haven't looked at the code), I understand the kernel side of things resolves all symlinks before presenting apparmor with a policy question. So what you want to test is "apparmor should know that a file is a target of a symlink for which it has a policy entry" and that's, uh, hard.

The upstream bug here is that cupsd decides to be clever rather than just using the "kerberosclient" abstraction, which we already divert.