Full System AppArmor Policy - Testers Wanted!

[madaidan]

apparmor-profile-everything is an experimental AppArmor policy which confines all user space processes on the system. It is still currently in development and requires testing.

Install it by executing:

sudo apt-get install apparmor-profile-everything

Then reboot.

apparmor-profile-everything supports different boot modes: aadebug and superroot. aadebug allows certain permissions necessary for advanced debugging and superroot relaxes the policy substantially, even making bypasses possible. It is highly recommended to stick to the default boot mode.

It also contains a wrapper to restrict apt as apt requires permissions that may be abused to circumvent the policy. When updating or installing applications, you must use the rapt command.

Please report any issues you face while using this so they can be resolved.

See also:

Whonix/apparmor-profile-everything

Using apparmor-profile-everything on Debian Buster

I have been keeping up with @madaidan’s and @Patrick’s ongoing development of apparmor-profile-everything. So far, their efforts have led to a system of total confinement aptly named apparmor-profile-everything. This is not simply a single profile but a series of profiles, system files, and related scripting. Together these elements work as one to confine the user’s system starting from init onward. The confinements include: the systemd init process and any children it spawns, the apt-get proce…

[Dyras]

Quick question. Is this intended to be installable in KickSecure as well? Because it doesn’t seem to work for me.

Just checking before I post more debugging info, etc.

[madaidan]

Yes, please post any errors you get.

[facott]

Is it normal that after installing apparmor-profile-everything whonix will only boot in live mode?

[Patrick]

@facott

Is it normal that after installing apparmor-profile-everything whonix will only boot in live mode?

No. But more likely not actually live mode and just live mode indicator systray being broken.

Do live mode functionality test:

https://www.whonix.org/wiki/VM_Live_Mode#Functionality_Test

Please run the following command and post the output here.

bash -x /usr/share/livecheck/livecheck.sh

---

Can the following command be run? @madaidan

sudo --non-interactive /bin/lsblk --noheadings --all --raw --output RO

(This is what /usr/share/livecheck/livecheck.sh does.)

---

https://github.com/Whonix/whonix-xfce-desktop-config/blob/master/usr/share/livecheck/livecheck.sh

[facott]

You are right, it’s just the indicator.
I can’t use pastebin link to post the output.

[facott]

Both kloak and vboxadd-service units fail after installing apparmor-profile-everything.
Is it enough to post only journalctl log?
I am sorry for the noob question but I know nothing.

[Patrick]

@facott

I can’t use pastebin link to post the output.

Upgraded your account just now. You can add links now.

See also (written just now):
https://www.whonix.org/wiki/Forum_Best_Practices#Pasting_Logs_for_Support

@facott

Both kloak and vboxadd-service units fail after installing apparmor-profile-everything.
Is it enough to post only journalctl log?

Probably not. Perhaps:

• Watch Systemd Journal Log of Current Boot

then in another terminal tab or window, restart these services.

sudo systemctl restart kloak

---

sudo systemctl restart vboxadd-service

While doing that, the relevant issue might show up in the systemd journal log.

Also please paste logs for specific daemons.

sudo journalctl -b --no-pager -u kloak

---

sudo journalctl -b --no-pager -u vboxadd-service

[facott]

Kloak

-- Logs begin at Sat 2020-11-14 15:01:14 UTC, end at Sat 2020-11-14 16:04:40...

Vboxadd-service

-- Logs begin at Sat 2020-11-14 15:01:14 UTC, end at Sat 2020-11-14 16:05:32...

Apt-daily

-- Logs begin at Sat 2020-11-14 15:01:14 UTC, end at Sat 2020-11-14 16:09:32...

Apt-daily-upgrade

-- Logs begin at Sat 2020-11-14 15:01:14 UTC, end at Sat 2020-11-14 16:08:21...

And this is sudo journalctl -b -f output

-- Logs begin at Sat 2020-11-14 15:01:14 UTC. --Nov 14 16:24:43 host sdwdate[1...

(there are strange links here, is it ok?)

[Patrick]

That helps a lot.

Extracted from the last log.

Nov 14 16:24:58 host audit[14305]: AVC apparmor=“DENIED” operation=“open” profile=“init-systemd” name="/sys/block/" pid=14305 comm=“lsblk” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

Nov 14 16:25:09 host audit[1]: AVC apparmor=“DENIED” operation=“open” profile=“init-systemd” name="/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0A:00/power_supply/BAT0/" pid=1 comm=“systemd” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

Nov 14 16:25:09 host audit[14337]: AVC apparmor=“DENIED” operation=“open” profile=“init-systemd” name="/var/lib/apt/daily_lock" pid=14337 comm=“apt.systemd.dai” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0

Nov 14 16:25:21 host audit[1]: AVC apparmor=“DENIED” operation=“open” profile=“init-systemd” name="/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0A:00/power_supply/BAT0/" pid=1 comm=“systemd” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

Nov 14 16:25:21 host audit[14347]: AVC apparmor=“DENIED” operation=“open” profile=“init-systemd” name="/var/lib/apt/daily_lock" pid=14347 comm=“apt.systemd.dai” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0

Nov 14 16:25:32 host audit[14353]: AVC apparmor=“DENIED” operation=“exec” info=“no new privs” error=-1 profile=“init-systemd” name="/usr/sbin/kloak" pid=14353 comm="(kloak)" requested_mask=“x” denied_mask=“x” fsuid=0 ouid=0 target="/usr/sbin/kloak"

Nov 14 16:25:46 host audit[14482]: AVC apparmor=“DENIED” operation=“open” profile=“init-systemd” name="/proc/modules" pid=14482 comm=“lsmod” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

Let’s wait for @madaidan to fix these.

[madaidan]

@Patrick

Can the following command be run?

No, this requires read access to the hard drive which is explicitly denied: https://github.com/Whonix/apparmor-profile-everything/blob/master/etc/apparmor.d/abstractions/dangerous-files#L104

We could slightly relax the restrictions to allow reading /sys/devices/pci**/block/{s,v}da/dev however, this could potentially allow an attacker to bypass some restrictions and read sensitive files e.g. System.map which can aid further exploitation. Is there another way to implement this check?

@Patrick

Nov 14 16:25:32 host audit[14353]: AVC apparmor=“DENIED” operation=“exec” info=“no new privs” error=-1 profile=“init-systemd” name="/usr/sbin/kloak" pid=14353 comm="(kloak)" requested_mask=“x” denied_mask=“x” fsuid=0 ouid=0 target="/usr/sbin/kloak"

Seems to be the same issue as we had with sdwdate, haveged and onion-grater. Might need to subtract some systemd hardening.

@Patrick

Nov 14 16:25:46 host audit[14482]: AVC apparmor=“DENIED” operation=“open” profile=“init-systemd” name="/proc/modules" pid=14482 comm=“lsmod” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

This is only allowed in aadebug mode: https://github.com/Whonix/apparmor-profile-everything/blob/master/etc/apparmor.d/abstractions/aadebug#L5

[Patrick]

@madaidan

Is there another way to implement this check?

Not that I know. The live mode check needs some way to know if the kernel thinks there are any devices mounted as read-write.

(It only detects live mode if all devices are mounted read-only.)

Happy for suggestions for alternatives.

Currently using this:

sudo --non-interactive /bin/lsblk --noheadings --all --raw --output RO

Would it help if instead that was /path/to/some/wrapper and sudo --non-interactive /path/to/some/wrapper? Happy to implement that too. Even such a wrapper being allowed to run wouldn’t be good enough?

(That wrapper would then run /bin/lsblk --noheadings --all --raw --output RO.)

[madaidan]

@Patrick

Would it help if instead that was /path/to/some/wrapper and sudo --non-interactive /path/to/some/wrapper ? Happy to implement that too. Even such a wrapper being allowed to run wouldn’t be good enough?

(That wrapper would then run /bin/lsblk --noheadings --all --raw --output RO .)

We could just create a profile directly for /bin/lsblk since it doesn’t appear to include any functionality that is especially dangerous (if it does, we can create a rapt-like wrapper). This would also allow using lsblk for other purposes.

[madaidan]

Should be fixed with this

Create lsblk AppArmor profile

[madaidan]

@Patrick

Nov 14 16:25:21 host audit[14347]: AVC apparmor=“DENIED” operation=“open” profile=“init-systemd” name="/var/lib/apt/daily_lock" pid=14347 comm=“apt.systemd.dai” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0

This is conflicting with https://github.com/Whonix/apparmor-profile-everything/blob/master/etc/apparmor.d/abstractions/dangerous-files#L25

Will need to also create a profile for /usr/lib/apt/apt.systemd.daily.

[madaidan]

Should now be fixed by

Create apt.systemd.daily AppArmor profile

[Patrick]

@madaidan

We could just create a profile directly for /bin/lsblk since it doesn’t appear to include any functionality that is especially dangerous (if it does, we can create a rapt-like wrapper). This would also allow using lsblk for other purposes.

Sounds great!
I doubt lsblk has dangerous functionality. Since its name beings with ls it’s only an informational tool. Not a manipulation tool.

[Patrick]

All merged and now available in testers repository.