Bug#979500: [pkg-apparmor] Bug#979500: dh-apparmor: please support local includes of abstractions like "abstraction/name"
Control: tag - moreinfo Control: tag + wontfix Hi, Christian Ehrhardt (2021-02-08): > I'm already part of the crowd waiting for "Include if exists" to be > widely available. > And yes, that would solve my problem as well. > > But IMHO a huge problem with "Include if exists" is, that on older > apparmor it totally breaks the rule parsing. > That makes it hard to fully jump onto the new feature yet: > - upstreams don't know how far back their SW will be built, this would > need to become at least a build time version/feature check against > apparmor > - distro-packaging often enough is used for backports, where again > we'd need code to handle old and new feature sets I hear you and I understand this set of conflicting constraints is difficult to disentangle :/ > But thinking more about it I think I still agree that we can close this bug. > That is because in the (hopefully few) places we need this we can > handle it (a bit ugly) in the maintscripts. > If we'd fully support it in dh-apparmor it might encourage people "too > much" to use that instead of the hopefully better future of > "include-if-exists". This makes sense to me. I'm marking this bug as wontfix for now, so that other folks who wonder why dh-apparmor lacks this feature can find the answer. Thank you all for the constructive discussion, cheers!
Bug#979500: [pkg-apparmor] Bug#979500: dh-apparmor: please support local includes of abstractions like "abstraction/name"
On Sat, Feb 6, 2021 at 8:08 AM intrigeri wrote: > > Hi, > > intrigeri (2021-01-08): > > Christian Boltz (2021-01-07): > >> I'd argue that this is a problem that is already solved ;-) > >> > >> Starting with AppArmor 3.0, all[1] upstream abstractions come with a > >> rule like (example taken from abstractions/base): > >> > >> include if exists > >> > >> so if you create that directory and place a file there, it will be > >> included by the abstraction. > > > >> [...] > > > >> For abstractions shipped by individual package (like libvirt), it would > >> also make sense to add an include if exists > >> rule to make it easy to add something to an abstraction. > > > > I like what Christian Boltz is proposing (thanks!): as far as > > I understand, it can happen in libvirt upstream, will benefit even > > non-Debian distros, and does not require modifying dh-apparmor. > > > > Christian Ehrhardt, how does it sound? Any reason why the approach you > > initially suggested on this bug report is better? > > Ping? I beg your pardon I totally lost your and Christian B. replies on this one in my inbox-cracks. Thanks Intrigeri for the ping. I'm already part of the crowd waiting for "Include if exists" to be widely available. And yes, that would solve my problem as well. But IMHO a huge problem with "Include if exists" is, that on older apparmor it totally breaks the rule parsing. That makes it hard to fully jump onto the new feature yet: - upstreams don't know how far back their SW will be built, this would need to become at least a build time version/feature check against apparmor - distro-packaging often enough is used for backports, where again we'd need code to handle old and new feature sets But thinking more about it I think I still agree that we can close this bug. That is because in the (hopefully few) places we need this we can handle it (a bit ugly) in the maintscripts. If we'd fully support it in dh-apparmor it might encourage people "too much" to use that instead of the hopefully better future of "include-if-exists". > I'd like to add that one of the reasons for adding support for > "include if exists" in AppArmor upstream was to cancel the need for > distros to manage local override files via packaging machinery, > which long term will allow us to simplify things like dh-apparmor, > making them easier to maintain and to use :) > -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#979500: [pkg-apparmor] Bug#979500: dh-apparmor: please support local includes of abstractions like "abstraction/name"
Hi, intrigeri (2021-01-08): > Christian Boltz (2021-01-07): >> I'd argue that this is a problem that is already solved ;-) >> >> Starting with AppArmor 3.0, all[1] upstream abstractions come with a >> rule like (example taken from abstractions/base): >> >> include if exists >> >> so if you create that directory and place a file there, it will be >> included by the abstraction. > >> [...] > >> For abstractions shipped by individual package (like libvirt), it would >> also make sense to add an include if exists >> rule to make it easy to add something to an abstraction. > > I like what Christian Boltz is proposing (thanks!): as far as > I understand, it can happen in libvirt upstream, will benefit even > non-Debian distros, and does not require modifying dh-apparmor. > > Christian Ehrhardt, how does it sound? Any reason why the approach you > initially suggested on this bug report is better? Ping? I'd like to add that one of the reasons for adding support for "include if exists" in AppArmor upstream was to cancel the need for distros to manage local override files via packaging machinery, which long term will allow us to simplify things like dh-apparmor, making them easier to maintain and to use :)
Bug#979500: [pkg-apparmor] Bug#979500: dh-apparmor: please support local includes of abstractions like "abstraction/name"
Hello, I'd argue that this is a problem that is already solved ;-) Starting with AppArmor 3.0, all[1] upstream abstractions come with a rule like (example taken from abstractions/base): include if exists so if you create that directory and place a file there, it will be included by the abstraction. You don't need to provide those directories or dummy files via the package, and in fact I'd say that they should only be created when really needed to keep /etc/apparmor.d/ readable. (Obviously, if a program needs to extend a specific abstraction, packaging an abstractions/$abstraction.d/$package file makes sense.) For abstractions shipped by individual package (like libvirt), it would also make sense to add an include if exists rule to make it easy to add something to an abstraction. Note: up to AppArmor 2.13.x, the aa-* tools (aa-logprof etc.) break in funny ways when hitting include if exists rules, and sadly that's not easy to fix (ETOOBIGPATCH). Therefore I'd recommend not to backport include if exists rules to profiles or abstractions in older distros. The aa-* tools from AppArmor 3.x fully support include if exists rules. Regards, Christian Boltz [1] The only exception is abstractions/ubuntu-browsers because (for historic reasons) an abstractions/ubuntu-browsers.d directory already exists and is used in a different way. -- seccheck runs here on a host that contains 3 daily backups of 10+ SAP hosts, and the "Local Monthly Security" Mail size is 562 MB. This mail size causes an unfriednly, suspicious grin on the face of my mail admin... [Werner Flamme in opensuse-security] signature.asc Description: This is a digitally signed message part.
