A better way would be to create our own app launcher that uses aa-exec to run the app in a confined_app profile although that might be too much work having to decide which apps run in confined_app by default and make it usable.
If we do decide to do this though, we can also do things like run each app as their own user in their own bubblewrap sandbox for better confinement.
Similar to android which has zygote.
With developers repository.
Jan 13 17:17:56 host audit[1876]: AVC apparmor="ALLOWED" operation="ptrace" profile="/usr/lib/whonix-firewall/**" pid=1876 comm="systemctl" requested_mask="read" denied_mask="read" peer="unconfined"
Jan 13 17:17:56 host audit[1876]: AVC apparmor="ALLOWED" operation="open" profile="/usr/lib/whonix-firewall/**" name="/proc/cmdline" pid=1876 comm="systemctl" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 13 17:17:56 host audit[1876]: AVC apparmor="ALLOWED" operation="ptrace" profile="/usr/lib/whonix-firewall/**" pid=1876 comm="systemctl" requested_mask="read" denied_mask="read" peer="unconfined"
Jan 13 17:17:56 host kernel: audit: type=1400 audit(1578935876.449:19): apparmor="ALLOWED" operation="ptrace" profile="/usr/lib/whonix-firewall/**" pid=1876 comm="systemctl" requested_mask="read" denied_mask="read" peer="unconfined"
Jan 13 17:17:56 host kernel: audit: type=1400 audit(1578935876.449:20): apparmor="ALLOWED" operation="open" profile="/usr/lib/whonix-firewall/**" name="/proc/cmdline" pid=1876 comm="systemctl" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 13 17:17:56 host kernel: audit: type=1400 audit(1578935876.449:21): apparmor="ALLOWED" operation="ptrace" profile="/usr/lib/whonix-firewall/**" pid=1876 comm="systemctl" requested_mask="read" denied_mask="read" peer="unconfined"
Jan 13 17:17:56 host audit[1880]: AVC apparmor="ALLOWED" operation="ptrace" profile="/usr/lib/whonix-firewall/**" pid=1880 comm="systemctl" requested_mask="read" denied_mask="read" peer="unconfined"
Jan 13 17:17:56 host audit[1880]: AVC apparmor="ALLOWED" operation="open" profile="/usr/lib/whonix-firewall/**" name="/proc/cmdline" pid=1880 comm="systemctl" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 13 17:17:56 host kernel: audit: type=1400 audit(1578935876.457:22): apparmor="ALLOWED" operation="ptrace" profile="/usr/lib/whonix-firewall/**" pid=1880 comm="systemctl" requested_mask="read" denied_mask="read" peer="unconfined"
Jan 13 17:17:56 host kernel: audit: type=1400 audit(1578935876.457:23): apparmor="ALLOWED" operation="open" profile="/usr/lib/whonix-firewall/**" name="/proc/cmdline" pid=1880 comm="systemctl" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jan 13 17:17:56 host kernel: audit: type=1400 audit(1578935876.457:24): apparmor="ALLOWED" operation="ptrace" profile="/usr/lib/whonix-firewall/**" pid=1880 comm="systemctl" requested_mask="read" denied_mask="read" peer="unconfined"
Jan 13 17:17:56 host audit[1880]: AVC apparmor="ALLOWED" operation="ptrace" profile="/usr/lib/whonix-firewall/**" pid=1880 comm="systemctl" requested_mask="read" denied_mask="read" peer="unconfined"
Could you fix please?
Merged.
I figured out the problem. Denying write access to /**/systemd/ causes this.
That and a few other things are fixed in https://github.com/Whonix/apparmor-profile-everything/pull/32
Merged.
## Deny access to /boot and /usr/src to hide them from the logs.
audit deny /boot/ rw,
audit deny /boot/** rw,
audit deny /usr/src/ rw,
audit deny /usr/src/** rw,
What hiding form the logs useful for here?
By “logs”, I mean apparmor logs. I noticed that something would try to access /boot and /usr/src which would then give unwanted errors in the logs.
madaidan via Whonix Forum:
By “logs”, I mean apparmor logs.
I know.
I noticed that something would try to access /boot and /usr/src which would then give unwanted errors in the logs.
What accesses /boot and /usr/src? That would be good to know so that can
be documented. Anything trying to access these folders and failing might
be OK but it might also break some functionality. Therefore better to
initially log this and disable logging later after we at least know the
major, default installed things which try to access these folders.
For some reason, remove-system.map wasn’t being confined under kicksecure-shell-script for me so it was giving those errors. I replaced the profiles with the ones in git and the errors stopped.
I removed the deny rules and added more System.map locations in https://github.com/Whonix/apparmor-profile-everything/pull/33
I’m getting this error now due to our sysctl restrictions:
AVC apparmor="DENIED" operation="open" profile="init-systemd" name="/proc/sys/kernel/core_pattern" pid=1 comm="systemd-shutdow" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
We’ll need to create a systemd-shutdown profile for this although I don’t know why it needs access to that anyway.
We should also create a profile for Xorg since it’s a large amount of code, has a history of vulnerabilities and to get rid of this error:
AVC apparmor="DENIED" operation="capable" profile="init-systemd" pid=1715 comm="Xorg" capability=17 capname="sys_rawio"
Granting CAP_SYS_RAWIO in the main profile is not ok as it opens up so many ways to escalate to kernel privileges such as iopl().
Even if we do make an X profile, I don’t know if I’m comfortable with exposing CAP_SYS_RAWIO to a program with such huge attack surface.
Now at 23 capabilities.
Will https://github.com/Whonix/apparmor-profile-everything/pull/25 get merged?
madaidan via Whonix Forum:
https://github.com/Whonix/apparmor-profile-everything/pull/34
Merged.
Now at 23 capabilities.
Will https://github.com/Whonix/apparmor-profile-everything/pull/25 get merged?
I didn’t manage yet to add Qubes compatibility. And then got distracted
by other things. Thanks for reminding me! 
apparmor-profile-everything does not work on Qubes at all anyhow. But
this would be another change which would make it hard to fix since it
would break networking. Should I merge changes which break Qubes for
certain?
/var/lib/dkmks and /var/lib/hardened-kernel - compilation happens there. Kernel / module related addresses / symbols / binaries might leak there? Could add the read access rights restrictions please?
Qubes will be broken either way so I think yes.
madaidan via Whonix Forum:
Qubes will be broken either way so I think yes.
Will merge.
Pretty sure . /etc/default/networking is not required. Untested.
/lib/systemd/system/networking.service already does
EnvironmentFile=-/etc/default/networking. Will remove.
Will rename etc/apparmor.d/sbin.networking to
etc/apparmor.d/sbin.networking-aae for consistency.