Apparmor profile for Qubes available!

[dkzkz]

@wafmtjwadllc

Even if you create apparmor profiles there are too many ways to exploit it crackarmor, Unconfined Child Processes, Information Leaks via System Calls, etc.

Instead harden the template vm by hardening overall vm.

You’re right but using apparmor is better than nothing no ? Additional security won’t harm anyone

@wafmtjwadllc

I had checked the source code, where Python Tk (a GUI tool) is used. The code copies all AppArmor profiles to /etc/apparmor.d/ . To make this persistent across VM restarts, you run this on template vm.

Oh you was talking about the script installation… hum yes i thought the script will be a good idea at first but it’s bad and too complicated to maintain etc… i’m actually planning to create a deb package instead. The deb package will be much more easier to qubes users to install. I’ve never build a debian package so i’m currently struggling with basic things but once it will be finished i will remove the installation script in favor of the debian package.

@wafmtjwadllc

selinux is powerful but you need to have good understanding of linux and need to invest huge time in selinux to master it. Also there are not many good source out there to learn it so its may take years mastering it

I like challenge but you’re 100% right about that learning selinux and also apparmor is hard but hey it’s not impossible

@wafmtjwadllc

• mitigations=auto,nosmt (dom0 already does this no need to use this here). disabling SMT impacts huge performance half your cpu cores will be gone by disabling SMT.
• kvm_amd.sev=1, kvm_amd.sev_es=1, kvm_amd.sev_snp=1, kvm-intel.vmentry_l1d_flush=always, kvm.mitigate_smt_rsb=1 (unncessary kvm parameters for Qubes VM. Qubes OS uses xen not kvm).
• iommu=force , intel_iommu=on , iommu.passthrough=0 , iommu.strict=1 — Controlled by Xen in dom0, not guest VMs.
• l1d_flush=on , l1tf=full,force , pti=on , spectre_v2=on , ssbd=force-on Already enforced at Xen/hypervisor level.
• init_on_alloc=1 , init_on_free=1 , page_alloc.shuffle=1 , slab_nomerge , slab_debug=FZ — Redundant due to VM isolation provides only little benefit.
• module.sig_enforce=1 , lockdown=confidentiality , vdso32=0 , vsyscall=none — Strong but often overkill; Qubes already isolates

I listened to you i changed every salt files to match the value you recommended

The only value i didn’t removed is lockdown=confidentiality but the other value has ben removed. I didn’t removed the lockdown because it will not do any harm but if necessary i can remove it if you want

If you have any other suggestion tell me

Also due to our previous discussion i’m planning to create a minimal script in /etc/ to randomize the machine-id at boot like Whonix does.

But like i explained earlier apps will still know you’re a Qubes users anyway

[dkzkz]

Due to the recent CVE discovered in apparmor Nine critical vulnerabilities in Linux AppArmor put over 12M enterprise systems at risk | CSO Online and due to the discussion i had with @wafmtjwadllc i think we should replace apparmor by SElinux

This is why i started to learn SElinux syntax , policies etc…

I ended up with this small SElinux policies

(deny domain proc_t (file (read write open getattr)))
(deny domain machineid_t (file (read write open getattr)))

This deny read and write access to anyone , any process in the system including root users itself to get the machine-id, proc information of the system and to modify them

To be clear no one , no malware will be able to get, modify your machine-id and proc information.

If you want to setup SElinux quickly to test the policy yourself go to my post Anonymize hostname hardened template automatic installation of browser to get the salt command

and pick one of .sls files here

This should take 2-3 minutes to install. Or you can also manually do it yourself by following this post How to install & activate SELinux on minimal fedora templates?

Once done create a “.cil” file in the vm by doing

nano a.cil

Then put inside the .cil

(deny domain proc_t (file (read write open getattr)))
(deny domain machineid_t (file (read write open getattr)))

Then do :

sudo semodule -i *.cil

Now if you do as sudo cat /etc/machine-id you will get "Permission denied" like in the screenshot and if you try to edit the machine-id and write data there you will get a Permission denied even as sudo.

I think SElinux is far more better than Apparmor because we can deny access to any root filesystem or home directory. Example we can easily deny access to anyone in the system to get your ssh key or gpg key.

But it’s very very complicated to understand how it’s works. But i think it’s worth the effort. To learn so i will stop creating apparmor profile. And i will focus on SElinux instead.

I don’t know yet what i will do with those apparmor profile i will probably move them to a another repository you will still be able to use them.

Also i tried to setup SElinux on debian by following this guide How to install & activate SELinux on minimal fedora templates? but it didn’t work at all. That’s only work for fedora. If anyone has find a way to enable SElinux for Debian please create a Qubes forum post to explain how you did that.

[oversight]

Apparmor before major version 5 (except on Ubuntu) does not mediate unix sockets and also not dbus.

So it seems pretty pointless to only use apparmor for confining programs intra-vm before apparmor 5, since it could escape via X11 or dbus. You would additionally need to combine it with mount namespaces to hinder access to socket paths and also take care of abstract sockets for every application.

If the application is a GUI application you would additionally need to take care of isolating x11 via Xpra/Xephyr, but I don’t know, whether this even properly works in Qubes or not. This also applies to Selinux and apparmor 5.

Additionally for QubesOS, if programs need to access qrexec, this is equivalent to root ^[1]

@dkzkz

There is a good reason why Tails , Whonix or Secureblue do not rely on firejail to secure a system they rely only on Apparmor or Selinux or Secureblue.

Their use is pretty shallow.

---

1. selinux/qubes-core-qrexec.te

   ↩︎