[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Let's enable AppArmor by default (why not?)

I think the only two ways to get a new package installed upon stretch → buster are:

1. Suggest the admin do it in the release notes. (It should be documented in the release notes no matter which option we pick, of course.)

2. Suggest the admin do it in a NEWS.Debian entry (but it needs to be an upgraded package, not a new one, else it won't be displayed. So the linux-image-4.* packages won't work, but e.g., linux-image-amd64 would).

3. Have a Recommends or Depends on it from another package that is installed. (Presumably that'd be a Recommends from the linux-image-* packages, and would be dropped down to a Suggests for buster+1).

4. Suggest the admin do it in a debconf note. Highly discouraged nowadays.

All of those except #1 also work for folks following testing or unstable.

Personally, I don't have a preference between #1 and #3, as long as we find some reasonable way to opt-out if we go with #3 (and document it in the release notes).

On 10/26/2017 11:02 AM, intrigeri wrote:

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


Reply to: