Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode
Hi, Seth Arnold: > On Thu, Aug 10, 2017 at 05:50:41PM -0400, intrigeri wrote: >> Context: this is about the apparmor-profiles package, that has no >> reverse-dependency, so this whole thing is not such a big deal (users >> [...] >> 2. Install *all* the profiles shipped by this package to >>/etc/apparmor.d/, set it in complain mode. >> >>(Once it's been clarified what this package is about, let's smooth >>the "get started with contributing to these profiles" process.) > The quality levels of the profiles in this package -- and their relevance > to modern systems -- is probably too varied at this point to suggest > turning them all on in any capacity by default. OK. This plus the fact deny rules are (confusingly) enforced in complain mode, plus some more bug reports from somewhat confused users, convinced me that we should not ship all these profiles in /etc; and at the very least, not in Debian while we're still considering enabling AppArmor by default. > If Someone were to go through them with an eye towards heavily > pruning what should be pruned first, this might be > a reasonable idea. Someone != me. > I think I'd rather they all be installed on the side though, and perhaps > suggested by the tools, if they don't already. Deal. I lack energy to handle the packaging side of moving files from /etc to /usr right now though (conffiles to non-conffiles, sounds scary), so in the meantime I took several steps to make the apparmor-profile package description more humble and to stop encouraging average users to install it at all: https://salsa.debian.org/apparmor-team/apparmor/merge_requests/1, merged, not uploaded yet. Same on https://wiki.debian.org/AppArmor/HowToUse, where I also added warnings about the deny rules vs. complain mode problem. There's definitely more work to do on this bug but for now I'm happy enough with the resulting state of things, that should be vastly more sustainable than it used to for me. Cheers, -- intrigeri
Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode
LGTM. -- If quantum mechanics hasn't profoundly shocked you, you haven't understood it yet. - Niels Bohr
Bug#830502: [pkg-apparmor] Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode
On Thu, 2017-08-10 at 17:50 -0400, intrigeri wrote: > > And the long-term goal is that eventually, some of these shared > profiles might become good enough to be shipped in the apparmor > package and enforced by default (and others should simply dropped from > Debian-based distros if nobody cares enough to make them work on > Debian and maintain them proactively). I agree with what Seth said, so I'll only respond on this point. When the profiles are good enough to ship by default, Ubuntu historically has preferred to ship profiles in the package that is under enforcement, since you get the security policy by default (without having to opt-in to another package) and because it allows the maintainer of the package to update the rules (ie, the maintainer of cups need only worry about the cups package as opposed to cups and apparmor). This of course isn't without its problems, but wanted to clarify this point wrt Ubuntu at least. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part
Bug#830502: [pkg-apparmor] Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode
On Thu, Aug 10, 2017 at 05:50:41PM -0400, intrigeri wrote: > Context: this is about the apparmor-profiles package, that has no > reverse-dependency, so this whole thing is not such a big deal (users > [...] > 2. Install *all* the profiles shipped by this package to >/etc/apparmor.d/, set it in complain mode. > >(Once it's been clarified what this package is about, let's smooth >the "get started with contributing to these profiles" process.) The quality levels of the profiles in this package -- and their relevance to modern systems -- is probably too varied at this point to suggest turning them all on in any capacity by default. If Someone were to go through them with an eye towards heavily pruning what should be pruned first, this might be a reasonable idea. I think I'd rather they all be installed on the side though, and perhaps suggested by the tools, if they don't already. It would be nice to have more examples that we're not ashamed of more widely available :) Thanks signature.asc Description: PGP signature
Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode
Hi, I've re-read the bug log and taken a step back. Here's some context and a proposal. Please provide input/opinions; especially Ubuntu people are welcome to comment: I want to do something that works for them as well (saying "we don't care much about this package, do whatever you want and we'll pull it as-is" is a valid option). Context: this is about the apparmor-profiles package, that has no reverse-dependency, so this whole thing is not such a big deal (users won't be affected unless they voluntarily install this package). This package ships policy in /etc/apparmor.d/ (loaded, in so-called complain mode i.e. not enforced except 'deny' rules), and some more in /usr/share/doc/apparmor-profiles/extras/ (not loaded at all). IMO the primary short-term goal of shipping this package at all in Debian/Ubuntu is to encourage enthusiast AppArmor users on Debian, Ubuntu and derivatives to improve WIP, shared profiles that live in the upstream AppArmor bzr repo, instead of writing their own from scratch. As Antoine explained, we currently do a poor job at this with this package. And the long-term goal is that eventually, some of these shared profiles might become good enough to be shipped in the apparmor package and enforced by default (and others should simply dropped from Debian-based distros if nobody cares enough to make them work on Debian and maintain them proactively). I propose we pick some low-hanging fruits to better achieve these goals without hindering our other, perhaps more important WIP efforts: 1. Rephrase the description of this package to better express what users are entitled to expect from the policy it ships. (Giving the package a less misleading name would be even better, but that would require more work spread over many wikis/doc pages so let's not bother for now.) 2. Install *all* the profiles shipped by this package to /etc/apparmor.d/, set it in complain mode. (Once it's been clarified what this package is about, let's smooth the "get started with contributing to these profiles" process.) 3. Take advantage of reportbug mechanisms (as suggested by Antoine) to help users report bugs and contribute patches about this policy to better places than the Debian BTS. 4. Go back to the broader "have better tools & processes to do cross-distro profiles maintenance" topic. Cheers, -- intrigeri
Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode
intrigeri: > Drawbacks of shipping not-quite-ready-yet profiles (in complain mode) > in /etc/apparmor.d/: Here's another one, that might be a deal breaker: * 'deny' rules are enforced even in complain mode, so *all* AppArmor users are affected by any bug in such rules
Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode
On 2017-07-04 09:52:55, intrigeri wrote: > Hi, > > intrig...@debian.org: >> The apparmor-profiles package ships a number of profiles in >> /etc/apparmor.d/, "in complain mode so that users can test and choose >> which are desired". This includes policy for dovecot, dnsmasq, >> avahi-daemon, ping. > >> This is confusing to some of us, and to users in general. And IIRC >> Felix had some concerns about shipping these profiles there as well. > >> During the team meeting we had at DebConf, several options were >> suggested: > >> a) Move the profiles that are not good enough to be enforced to >>a separate package > >> b) Move the profiles that are not good enough to be enforced to >>/usr/share/doc (where we already ship a number of profiles) > >> Also, it might be that some of these profiles are actually good enough >> to be enforced by default, instead of being moved elsewhere. > > I'm adding Antoine in the loop as he suggested on > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866790#19 that we do the > opposite, > i.e. to ship profiles from /usr/share/doc/apparmor-profiles/extras/ in > /etc/apparmor.d/ in complain mode. It seems we have good reasons to > move policy that's not quite ready for production use out of > /etc/apparmor.d/ (this is what this bug was about originally), but we > also have good reasons to do the exact opposite. > > Advantages of shipping not-quite-ready-yet profiles (in complain mode) > in /etc/apparmor.d/: > > * users who want to use some of these profiles simply have to >aa-enforce them, and they'll automatically get updated versions >when they upgrade apparmor-profiles; FTR the current situation is >that these users *copy* those profiles to /etc and then report bugs >about their obsolete copy (e.g. #866790), which is confusing to >users and adds extra maintenance workload on our team; > > * giving these profiles more exposure to testing might encourage some >users to improve them upstream. > > Drawbacks of shipping not-quite-ready-yet profiles (in complain mode) > in /etc/apparmor.d/: > > * it's hard to communicate to users the quality of these profiles, >and where bugs/improvements shall be submitted; currently we have >/usr/share/doc/apparmor-profiles/extras/README that states clearly >that these profiles "are not as mature as the profiles in >/etc/apparmor.d/", and that improvements shall be submitted >directly upstream. If we were shipping these profiles in /etc, I'm >worried we would get even more bug reports about them in the Debian >BTS, which causes 1. extra workload on our team; 2. frustration for >the user (being redirected to yet another BTS after reporting a bug >discourages many people, while perhaps they would send their >proposed changes directly upstream if instructed to do so in the >first place) My counter-argument here would be that I would *assume* a profile in "complain" mode is not production ready, by definition. The problem with people filing bugs directly in the BTS is a false problem, in my opinion: you'll always get this, regardless of how you set things up. Obfuscating the profiles in /usr/share hasn't helped you with my bug report, and I consider myself a rather experienced user. I even *knew* about that policy before and *read* that README file, all the way back when I deployed those profiles, and I simply forgot about it. A more productive way of pre-triaging bug reports is with reportbug hooks, to make sure users are made aware, when reporting bugs, what they should report upstream. For example, the file "/usr/share/bug/$package/presubj" is shown to the user before asking for the subject. You can even interactively prompt the user for stuff... See the docs here for details: /usr/share/doc/reportbug/README.developers.gz Such a prompt would have certainly given me pause when reporting a bug against apparmor-profiles-extra... In other words, I think shipping profiles in /usr/share is the wrong solution to this problem. Proper packaging of those profiles should install them in /etc/apparmor.d, otherwise they do not bring a significant enough advantage for me to use them over directly getting them from upstream (other than the maintainers' verification and trust path, naturally). Bug pre-triaging problems can be solved in other ways. Thanks! A. -- Nothing in life is to be feared, it is only to be understood Now is the time to understand more, so that we may fear less. - Marie Curie
Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode
Hi, intrig...@debian.org: > The apparmor-profiles package ships a number of profiles in > /etc/apparmor.d/, "in complain mode so that users can test and choose > which are desired". This includes policy for dovecot, dnsmasq, > avahi-daemon, ping. > This is confusing to some of us, and to users in general. And IIRC > Felix had some concerns about shipping these profiles there as well. > During the team meeting we had at DebConf, several options were > suggested: > a) Move the profiles that are not good enough to be enforced to >a separate package > b) Move the profiles that are not good enough to be enforced to >/usr/share/doc (where we already ship a number of profiles) > Also, it might be that some of these profiles are actually good enough > to be enforced by default, instead of being moved elsewhere. I'm adding Antoine in the loop as he suggested on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866790#19 that we do the opposite, i.e. to ship profiles from /usr/share/doc/apparmor-profiles/extras/ in /etc/apparmor.d/ in complain mode. It seems we have good reasons to move policy that's not quite ready for production use out of /etc/apparmor.d/ (this is what this bug was about originally), but we also have good reasons to do the exact opposite. Advantages of shipping not-quite-ready-yet profiles (in complain mode) in /etc/apparmor.d/: * users who want to use some of these profiles simply have to aa-enforce them, and they'll automatically get updated versions when they upgrade apparmor-profiles; FTR the current situation is that these users *copy* those profiles to /etc and then report bugs about their obsolete copy (e.g. #866790), which is confusing to users and adds extra maintenance workload on our team; * giving these profiles more exposure to testing might encourage some users to improve them upstream. Drawbacks of shipping not-quite-ready-yet profiles (in complain mode) in /etc/apparmor.d/: * it's hard to communicate to users the quality of these profiles, and where bugs/improvements shall be submitted; currently we have /usr/share/doc/apparmor-profiles/extras/README that states clearly that these profiles "are not as mature as the profiles in /etc/apparmor.d/", and that improvements shall be submitted directly upstream. If we were shipping these profiles in /etc, I'm worried we would get even more bug reports about them in the Debian BTS, which causes 1. extra workload on our team; 2. frustration for the user (being redirected to yet another BTS after reporting a bug discourages many people, while perhaps they would send their proposed changes directly upstream if instructed to do so in the first place) I have to say I'm torn between these two options. What do my fellow team-mates think? Cheers, -- intrigeri
Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode
Package: apparmor-profiles Version: 2.10.95-4 Severity: normal The apparmor-profiles package ships a number of profiles in /etc/apparmor.d/, "in complain mode so that users can test and choose which are desired". This includes policy for dovecot, dnsmasq, avahi-daemon, ping. This is confusing to some of us, and to users in general. And IIRC Felix had some concerns about shipping these profiles there as well. During the team meeting we had at DebConf, several options were suggested: a) Move the profiles that are not good enough to be enforced to a separate package b) Move the profiles that are not good enough to be enforced to /usr/share/doc (where we already ship a number of profiles) Also, it might be that some of these profiles are actually good enough to be enforced by default, instead of being moved elsewhere. Apparently, I've volunteered to work on that, but help would be greatly welcome :) Next step is to check what other distros (Ubuntu, OpenSUSE) do about these profiles. Cheers, -- intrigeri
