enable AppArmor by default

[adrelanos]

Technically, add apparmor=1 security=apparmor to kernelopts.

qvm-prefs -s vmname kernelopts "nopat apparmor=1 security=apparmor"

For Debian templates I don't foresee any issues. For Whonix templates I foresee even less issues. Other templates, no idea.

What is the plan regarding 'VM kernel by default'?
(I am not advocating either dom0 or VM kernel. Just asking.)

[adrelanos]

In case this is a no or inconclusive I would back up to a separate ticket enable AppArmor by default for Qubes-Whonix.

---

For Whonix it's sane to enable AppArmor by default since we don't ship AppArmor profiles by default which have potential to break in bad ways. (Such as for Tor Browser which has its own updater so Tor Browser might rush ahead and do things which are not covered by apparmor-profile-torbrowser.) We only ship AppArmor profiles for packages which are upgraded through Debian apt package management which undergo testing before flowing into the stable repository (such as for Tor, sdwdate, ...).

AppArmor enabled by default in Non-Qubes-Whonix for many releases.

Package https://github.com/Whonix/grub-enable-apparmor only works when using VM kernel.

Related:

• https://www.whonix.org/wiki/AppArmor
• https://www.whonix.org/wiki/Template:Qubes_AppArmor

[marmarek]

What is the plan regarding 'VM kernel by default'?

For now it is blocked by being incompatible with PVH :/

[lunarthegrey]

AppArmor works good in my PVH VMs, been using it for a while now. I don't think it's installed by default in the Debian template if I can remember correctly.

[jpouellet]

Is this now unblocked by QubesOS/qubes-linux-kernel@96b8fba?

/cc @HW42

[adrelanos]

Ignoring the news of QubesOS/qubes-linux-kernel@96b8fba - recently I added to Whonix wiki:

While Debian enabled AppArmor by default since Debian buster, Fedora does not. This matters since Qubes, which is Fedora based, by default uses dom0, not VM kernel. Therefore this is still required even though Whonix 15 is Debian buster based.

[tasket]

@marmarek This issue should be changed to T:bug, at least with respect to debian-10 templates. The reason is that AppArmor is enabled by default in Debian 10.

FWIW, AppArmor works fine with current templates and the 4.19 kernels as long as apparmor=1 security=apparmor is added to the kernelopts pref. I think it should work OK with the stable 4.14 kernels as well.

[andrewdavidwong]

This issue should be changed to T:bug, at least with respect to debian-10 templates. The reason is that AppArmor is enabled by default in Debian 10.

If there were separate issues for this for Debian and Fedora, then the Debian one could have the T: bug label. However, since they don't, I think we should leave this as-is with respect to the type. However, increasing the priority seems appropriate.

[marmarek]

This is yet another case where using in-vm kernel would make it much easier, as it would be the template controlling kernel command line. BTW with grub 2.04, it should be possible to use it with PVH mode too (previously only PV or HVM). There is grub2-xen-pvh package in current-testing already (to be installed in dom0).

For kernel provided from dom0, things are more complex. We need a mechanism for template/standalone qube advertise support for apparmor and then a mechanism to add relevant kernel options. Possibly also allowing user to override it (force-disable, force-enable).

Maybe we could implement it with qvm-features / qvm-service framework? It would go this way:

1. qubes.PostInstall service in a template check for apparmor support (I'd go with checking if apparmor systemd service exists) and if so, report qvm-feature-request supported-service.apparmor=1
2. Dom0 part (already exists) will see that feature request and set supported-service.apparmor=1 feature on the template.
3. Another dom0 extension (to be written) will monitor supported-service.apparmor=1 feature - and when it's set for the first time, it will set also apparmor=1 feature.
4. If apparmor=1 feature is present, apparmor=1 security=apparmor will be added to kernel command line (for the template and all qubes based on it).

The above (especially point 3) may be surprising for some. But it allows: a) enabling apparmor by default if supported, b) overriding that decision.
Alternatively, points 2 and 3 could be combined - template requesting apparmor=1 directly, not through intermediate supported-service.apparmor=1. This could be easier to follow, but it would be harder to distinguish template supporting apparmor from forcefully enabled apparmor on non-supporting template. And depending on design choices, user decision could be overridden(*).

Another concern is abusing supported-service.* feature. As documented on linked page, those are meant for supporting given qvm-service name. In case of apparmor, it wouldn't be the case. This is an argument for using apparmor=1 directly, or choosing yet another name.

(*) Should the template be able to say "I don't support apparmor anymore", for example if user uninstall relevant packages? Should kernel options be dropped then? On the other hand, should the user be able to disable apparmor even if template does support it?

@adrelanos @unman any opinions?

[tasket]

I would have thought that doing a qvm-prefs kernelopts in the rpm postinstall for the template would satisfy the "enabled by default, but changeable" requirement.

The tricky part is finding debian 10 templates that already exist, but not by the original name. This is one of several cases where it would be helpful for Qubes dom0 to know the OS type, distro and version of a template or standalone vm.

[marmarek]

rpm postinstall for the template

I definitely don't want a distribution-specific code in rpm %post. For multiple reasons:

• no template-built output should run in dom0 to preserve isolation (see here and here)
• Improve template distribution mechanism #2534 (possibly migrating away from rpm)
• doesn't cover upgrading templates in-place, or already installed templates

The tricky part is finding debian 10 templates that already exist, but not by the original name.

My proposal cover this. Installing updated package within template will start advertising support for apparmor.

This is one of several cases where it would be helpful for Qubes dom0 to know the OS type, distro and version of a template or standalone vm.

I don't object this on the principle, but prefer to have as little distribution-specific code in dom0 as possible. Rather - set of features that template can advertise it supports. This way it's easier to create customized templates without dom0 modifications.

[adrelanos]

I find all of this too complex and argued for "VM kernel all the way" in #5212 (comment).

If you like to keep dom0 kernel long term, I'll revisit your comment #4088 (comment), follow-up comments and then pick the least worst one.

[adrelanos]

Is this also in R4.0?

Anything needed to do on the templates side, i.e. advertising apparmor feature for Debian, Fedora, Whonix or other templates?

//cc @herypt

[3hhh]

It's in 4.1 only and should be added to the changelog for that very reason.

I at least was quite suprised about apparmor being enabled after investigating why certain stuff didn't work in my VMs.

[herypt]

@adrelanos Sorry for the late reply, it checks if apparmor.service is enabled in the template.

[Nurmagoz]

Side note:

This ticket feature not applied to debian-minimal according to #8331.