Hi, intrigeri: > tl;dr: I hereby propose we enable AppArmor by default in testing/sid, > and decide one year later if we want to keep it this way in the > Buster release.
Thanks a lot to everyone who participated on this thread, tried AppArmor and reported bugs, or expressed support/interest privately! Summary of the discussion: no strong objection was raised; quite a few potential issues were mentioned; the most serious ones were either resolved already, or in good way to be resolved in the next 2 weeks. So, my understanding is that we have a broad consensus and can start the proposed experiment. I need advice from you folks on one specific matter, see below. > 1. Enable AppArmor by default in testing/sid as soon as feasible in > the Buster cycle. > I can think of several possible ways to do it but for now I'd > rather focus on the "do we want to do it at all" conversation. It's now time to discuss the "how" aspect. Enabling AppArmor by default requires two changes: 1. enabling the LSM in Linux: problem solved, Ben Hutchings agreed we should do this in src:linux, at least for the time being; 2. installing the apparmor package by default: it ships the bits of code that load AppArmor policy during boot and some shared bits of policy that most other AppArmor profiles rely upon. This email is about (2). There are two aspects to it. For new installations, it seems that making the apparmor package "Priority: standard" is the way to go. I've asked debian-boot@'s opinion about it [priority:standard?] but the rest of our developers community is of course welcome to comment as well. For upgrades it seems much more complicated. Ideally I would like the apparmor package to be installed automatically: - on testing/sid upgrades, during the Buster dev cycle: this would greatly increase the value of the "enable AppArmor by default for a while" experiment as we would get lots more data to reason about when the time comes; - during Stretch to Buster upgrades: this seems necessary so every user gets the AppArmor benefits, regardless of when they installed their system initially. I also want to provide easy means for users to opt-out from the experiment. I've requested advice on this topic from a few fellow Debian people and the conclusion seems to be: - I was told essentially "we generally don't do that in Debian" by a few people who suggested me asking this mailing list. I don't understand the rationale though — during system upgrades we do change the distro behavior in many ways: we add new features, we enable new security measures, we switch init systems, we switch from MySQL to MariaDB and all sort of things — so it's not obvious to me why doing the same to enable a security system like AppArmor would be a Bad Thing™. Is the concern specifically about doing so by pulling a new package in? Or is it specifically about enabling a LSM that was previously disabled? (Any such big change brings a risk of introducing regressions, so the underlying questions seem to be "is the risk worth it? is the risk well managed?") - We have no better option to achieve that than having another package, that's already installed by default, add a "Recommends: apparmor". This feels artificial and rather ugly, but it might be the only option. I don't know which other package would be the most suitable to add this dependency. Any suggestion? Any other idea? I'd love to read your thoughts about this. Let's discuss it. [priority:standard?] https://bugs.debian.org/879590#25 Cheers, -- intrigeri