Hi, intrigeri: > Michael Biebl: >> This is my idea basically: say you have a apparmor profile which >> contains /bin/foo. >> When that profile file is read by the apparmor profile parser, you check >> for symlinks in those paths. >> The parser notices on a merged user system that /bin is a path to >> /usr/bin, so it adds /bin/foo and /usr/bin/foo on the whitelist.
> This would indeed avoid patching anything for things like merged-/usr, > /var/run and friends. The main problem I see with this approach is > that as a side-effect, it will create rules that overlap with other > parts of the policy, which causes various problems: 1. if such rules > have conflicting "x" modifiers, policy compilation will fail hard > (that's not theoretical: I've actualy hit such problems while > preparing the patches for merged-/usr); 2. automatic "let me fix the > policy you wrote on the fly" stuff tends to be harder to audit and > debug (which is the main reason why I decided against using the > existing AppArmor "alias" support to deal with merged-/usr). > Now, I wonder if there are more problems that would come with this > approach, that explain why it wasn't chosen. Or whether it's "just" > a matter of lacking time to implement it… in which case it likely > won't happen in time for Stretch, while merged-/usr will quite > possibly be the default in there, so it would be nice to have the > proposed patch applied :) Ping? I'm still curious about this, and having a comment from a source more authoritative than me would probably help explain why the Evince Debian package maintainers should take my proposed patch. Cheers, -- intrigeri -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
