Apparmor initialization failed

[subproc]

Qubes OS version:

R3.2 R4.0

Affected TemplateVMs:

all templates

---

Steps to reproduce the behavior:

after installing apparmor and related packages, like explained in the whonix wiki, and set kernel parameters to "nopat apparmor=1 security=apparmor", there's a working apparmor module with the kernel 4.9.56-21, but switching to the 4.14.13-1 or 4.14.13-2 it's not working at all...

Expected behavior:

having a working apparmor module

Actual behavior:

with the 4.14 kernel if i call "sudo aa-status":
apparmor.service - AppArmor initialization
Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Condition: start condition failed
└─ ConditionSecurity=apparmor was not met

General notes:

it seems that there's only support for selinux (disabled) and yama (enabled)

---

Related issues:

in R3.2 if i want a working apparmor i've to switch back to the 4.9 kernel, but in R4.0 is not an option, so no apparmor at all

[subproc]

it seems that apparmor is disabled at compiling time in qubes os.
CONFIG_SECURITY_APPARMOR=y is commented out in the config as visible in https://github.com/QubesOS/qubes-linux-kernel/blob/stable-4.14/config-qubes
I don't know why 'till the 4.9 the kernel was compiled with apparmor enabled and now not

[subproc]

it seems that apparmor is disabled at compiling time in qubes os.
CONFIG_SECURITY_APPARMOR=y is commented out in the config as visible in https://github.com/QubesOS/qubes-linux-kernel/blob/stable-4.14/config-qubes
I don't know why 'till the 4.9 the kernel was compiled with apparmor enabled and now not

[marmarek]

@HW42 any reason for not enabling it?

[marmarek]

@HW42 any reason for not enabling it?

[HW42]

No. I just weren't aware of any users so derivating from the Fedora default didn't make sense (see QubesOS/qubes-linux-kernel#13 (comment)).

[HW42]

No. I just weren't aware of any users so derivating from the Fedora default didn't make sense (see QubesOS/qubes-linux-kernel#13 (comment)).

[marmarek]

Ok, so lets enable it. And probably also worth updating to 4.14.17.
And to 4.15.1 in master branch (kernel-latest). Can you check if nothing breaks badly and open PRs?

[marmarek]

Ok, so lets enable it. And probably also worth updating to 4.14.17.
And to 4.15.1 in master branch (kernel-latest). Can you check if nothing breaks badly and open PRs?

[HW42]

Ok

[HW42]

Ok

[subproc]

thanks a lot, now there's a working apparmor module...i think we can close this ticket

[subproc]

thanks a lot, now there's a working apparmor module...i think we can close this ticket

[troubadoour]

Was there a kernel update recently?
It looks like this issue is showing again with 4.14.18-1.pvops.qubes.x86_64

Apparmor status reports:

Condition: start condition failed at Wed 2018-03-28 11:41:31 UTC; 15min ago
└─ ConditionSecurity=apparmor was not met

[troubadoour]

Was there a kernel update recently?
It looks like this issue is showing again with 4.14.18-1.pvops.qubes.x86_64

Apparmor status reports:

Condition: start condition failed at Wed 2018-03-28 11:41:31 UTC; 15min ago
└─ ConditionSecurity=apparmor was not met

[troubadoour]

This was a false alarm. Some trouble after reinstalling AppArmor.
Thanks for re-opening, it can be closed again.

[troubadoour]

This was a false alarm. Some trouble after reinstalling AppArmor.
Thanks for re-opening, it can be closed again.