Enabling AppArmor

Qubes-Whonix
1

Hi,

During Whonix Qubes setup I followed the instructions for enabling apparmour, but aa-status says its not enabled/loaded.

I double-checked that the qvm pref is set properly, so I don’t know what went wrong.

3

Yes, I restarted them. Those parameters match mine and the result is “1”.

If I run aa-status by itself it says the apparmor module is not loaded.

4

Running this in the AppVM?

"At the moment, if you want to use this, you must apply these settings to the TemplateVMs as well as the TemplateBasedVMs. Once Qubes Q3 gets released, TemplateBasedVMs will inherit the kernelopts setting of their TemplateVM. "
(newly created VMs should inherit kernelopts of TemplateVM · Issue #1091 · QubesOS/qubes-issues · GitHub)

If “qvm-prefs -l whonix-ws kernelopts” says ““nopat apparmor=1 security=apparmor”” then this only applies to the whonix-ws TemplateVM. You have to apply this setting to AppVMs separately.

5

I’ve tested it in both templates and both template-based vms. It did not appear I needed to set the prefs for the template-based vms as the settings carried over. But then I manually set them just in case.

Could the kernel version have something to do with it? The vms are using 3.19.3-4.

6

Can you please check, if

contains

?

Kernel should have nothing to do with it. Certainly recent enough. Works for me with Qubes Q3 RC2 default 3.18.17-6. Please try if it works with that one.

(Edit: RC2 not RC1)

8

Whonix doesn’t require/enforce/etc. any canonical kernel versions.

9

[quote=“Patrick, post:6, topic:1398”]Can you please check, if

cat /proc/cmdline

contains

apparmor=1 security=apparmor

?

Kernel should have nothing to do with it. Certainly recent enough. Works for me with Qubes Q3 RC2 default 3.18.17-6. Please try if it works with that one.

(Edit: RC2 not RC1)[/quote]

I’m having trouble just getting a terminal to run in the gw. It takes over 2min before any windows appear (timesync and whonixcheck) and then I can run a terminal. This is not how I’m used to Whonix-Qubes running.

Whonixcheck is looking pretty scary… The template and appvms are pristine, but everything in the list shows ERROR and it has the temerity to tell me there are unwanted packages in the system:

WARNING: Whonix Unwanted Packages Test Result: 2 unwanted package(s) installed. It is recommended that you remove them from your TemplateVM. 1. Open a terminal, dom0 -> Start Menu -> Whonix-Gateway TemplateVM -> Terminal. 2. Purge sudo apt-get purge chrony ntpdate 3. Shutdown the Whonix-Gateway TemplateVM. (dom0 -> Qubes VM Manager -> right click Whonix-Gateway TemplateVM -> Shutdown VM) 4. Shutdown and restart this Template-Based ProxyVM. (dom0 -> Qubes VM Manager -> right click 'anon-gw' -> Shutdown VM) See also: https://www.whonix.org/wiki/Whonix_Debian_Packages If you know what you are doing, feel free to disable this check. Create a file /etc/whonix.d/50_whonixcheck_user and add: whonixcheck_skip_functions+=" check_unwanted_packages " ERROR: Check Timezone Result: /etc/timezone settings different from Whonix defaults. timezone_file_expected_content: Etc/UTC timezone_file_actual_content: UTC ERROR: Check Timezone Result: Settings different from Whonix defaults. (See above!) You could try to fix this. dom0 -> Start Menu -> 'anon-gw' -> Konsole sudo su echo "Etc/UTC" > /etc/timezone cp "/usr/share/zoneinfo/Etc/UTC" "/etc/localtime" It is generally recommended to keep the default as per Whonix Design. [1] If you did not change timezone related settings, please report this Whonix bug. If you know what you are doing, feel free to disable this check. Create a file /etc/whonix.d/50_whonixcheck_user and add: whonixcheck_skip_functions+=" check_timezone " [1] https://www.whonix.org/wiki/Dev/Design-Shared#timezone ERROR: Systemd Clock Check Result: Unexpected results by timedatectl. ttimedatectl_output_pretty: Local time: Sat 2015-09-19 04:10:42 UTC Universal time: Sat 2015-09-19 04:10:42 UTC RTC time: n/a Time zone: UTC (UTC, +0000) NTP enabled: yes NTP synchronized: no RTC in local TZ: no DST active: n/a It is generally recommended to keep the default as per Whonix Design. [1] If you did not change timezone related settings, please report this Whonix bug. If you know what you are doing and changed this on purpose, feel free to disable this check. [2]

[1] Whonix Networking Implementation Documentation
[2] Create a file /etc/whonix.d/50_whonixcheck_user and add:
whonixcheck_skip_functions+=" check_systemd_clock "

10

user@host:~$ cat /proc/cmdline
root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH 3 nopat apparmor=1 security=apparmor

11

/proc/cmdline looks good. I don’t know then why “sudo aa-status” doesn’t show it enabled then.

[hr]

The second whonxicheck warning… Try this.

timedatectl set-ntp false

You installed whonixcheck from the testers repository. And probably also a lot more. That works well for Whonix 12 development images, but upgrades Whonix 11 → Whonix 12 are not yet tested. I am not surprised by these issues. Those have to be covered in in upgrade instructions.

I don’t know yet what causes the terminal opening bug. But I don’t know what Whonix specific could cause this. I think it’s a Qubes upstream bug / race condition. Could be window errors because environment variable QT_X11_NO_MITSHM not set · Issue #1172 · QubesOS/qubes-issues · GitHub ? Maybe D-Bus Error · Issue #1138 · QubesOS/qubes-issues · GitHub.

If you would like to help debug this, see what /var/lib/qubes/vm-templates/whonix-gw/apps.templates/konsole.desktop is doing. Try to emulate that from a dom0 terminal. qvm-run. Without -q. With --pass-io.

12

Does enabling AppArmor in the plain Debian templates work for you?

13

After adding apparmor-utils to the debian8 template and starting one of those appvms, aa-status says the module isn’t loaded. This is the /proc/cmdline:

root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH 3 nopat apparmor=1 security=apparmor

If there is no workaround forthcoming, I’ll put apparmor on the backburner for now. I’d rather get a typical whonix setup working smoothly and help you iron out the wrinkles. I’ll follow up in the other thread if that’s OK with you.

14

OK, after switching to kernel 3.18.17-6 apparmor now loads. Looks like its the kernel after all… 3.19.3-4 won’t load the module.

15

Yes.

17

Is this something that can be reproduced using the Debian templates and worth being reported against Qubes upstream?

It would be weird if the kernel works now but if AppArmor would break because of a bug introduced in upcoming versions.

19

Great!