Ticket #166 (new task)

Opened 15 years ago

Last modified 12 years ago

Upstream AppArmor should be configurable to follow symlinks

Reported by: tabbott Owned by:
Priority: normal Milestone: Upstream Utopia
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:  LP:132468  LP:203898

Description (last modified by geofft) (diff)

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

Change History

comment:1 Changed 15 years ago by broder

  • Component changed from dotfiles to default

comment:2 Changed 15 years ago by geofft


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.

comment:3 Changed 15 years ago by jdreed

  • Upstream bug set to LP:132468 LP:203898
  • Milestone set to Upstream Utopia

comment:4 Changed 14 years ago by geofft

  • Description modified (diff)
  • Summary changed from Report /etc/krb5.conf apparmor issue upstream to Upstream AppArmor should be configurable to follow symlinks

comment:5 Changed 12 years ago by lfaraone

Also affects evince starting firefox

comment:6 Changed 12 years ago by 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.

Note: See TracTickets for help on using tickets.