All merged.
Is /proc/pid/sched spy on keystrokes - proof of concept spy-gksu covered by apparmor-profile-everything yet?
No, /proc/pid/sched is allowed. We’ll need to test if removing it breaks anything.
Hi! Might this system-wide AppArmor work on Ubuntu? One thing I’ve noticed is that this profile gives any app full read/write access to the home directory. Would any app that writes into ~/.bashrc be able to get around AppArmor?
It might work but it’s untested and unsupported. It’s not finished yet, even for Debian.
No. This isn’t an individual sandbox. All userspace processes are confined under it. Any process sourcing .bashrc will be confined under it. Even init will be confined under it.
Full read/write access to the home directory is required. Otherwise, you wouldn’t be able to access your own home directory. System-wide sandboxing framework - sandbox-app-launcher will prevent apps from accessing your files though by running each app in its own restrictive sandbox.
@ale-carra
It can work on Ubuntu, but there are a couple things that are just a tiny bit different. Use the scripts and profiles included in apparmor-profile-everything as a template. On Ubuntu, you will definitely need to switch the init-systemd profile to complain mode initially. Reason is: paths to certain things are a little bit different in Ubuntu. If you do not enable complain mode, you will not be able to login.
Enable it in complain mode: sudo aa-complain init-systemd (from /etc/apparmor.d directory). When you restart your machine, study syslog to see the denied messages
sudo cat /var/log/syslog | grep “init-systemd”
Make necessary adjustments and then enable and test:
sudo apparmor_parser -r init-systemd && sudo aa-enforce init-systemd
Check the apt-get profile for log messages too, but at least apt-get will not prevent login.
Protip: if you get stuck and canot login, interrupt grub and on grub commandline add this: apparmor=0 and continue to boot and login. Fix the error, and go to /etc/default/grub, remove apparmor=0, regenerate grub and reboot.
Alright. That is very OK with me.
GitHub - madaidan/apparmor-profile-everything: AppArmor for everything. APT, systemd, init, all systemd units, all applications. Mandatory Access Control. Security Hardening. could be regarded as independent upstream. Adding support for Ubuntu, review/merge of Ubuntu (other other distribution) specific patches would be up to decide to @madaidan.
Generally, I am not sure it’s a good use of time to make things work for other distributions. Even review/merge effort costs time. Depends on the amount of time required. Might be decided on a by case basis.
For a while Whonix build script supported using Ubuntu sources too, i.e. using Ubuntu rather than Debian as a base distribution. However, I didn’t notice more users/contributions but on the other hand more complicated if/else code for Ubuntu specific glitches and higher maintenance effort. When making code changes, it had to be considered to not break Ubuntu builds.
What however is probably always useful if other distributions contribute stuff which is useful for us too in order to reduce their delta.
I intend to create individual apparmor profiles for each default process as per principle of least privilege.
madaidan via Whonix Forum:
Fixes by madaidan · Pull Request #43 · Kicksecure/apparmor-profile-everything · GitHub
Merged.
madaidan via Whonix Forum:
Merged.
Though, there was a merge conflict which I resolved. You you please check files look as intended in git master?
No.
owner /proc/{,kmsg,devices,modules,mtrr} r,
should be
owner /proc/{,kmsg,devices,mtrr} r,
Using environment scrubbing with everything broke the GUI and console.
GUI error message:
Unable to contact settings server
/usr/bin/dbus-launch terminated abnormally without any error message
Console error message:
Unable to change owner or mode of tty stdin: Permission denied
Following Restrict root access - #104 by madaidan, this isn’t nearly as restrictive as I thought but it’s still better than nothing.
We should also remove either writing or executing from /opt, /{,var/}tmp and /{,usr/local/}etc to prevent introduction of new arbitrary code.
This isn’t as important now though as we don’t have W^X memory mappings either so it can be bypassed.
That won’t work. Tor Browser in Whonix relies on environment variables such as TOR_SKIP_LAUNCH and others.
Isn’t the profile working an opt-in permission basis anyhow? I.e. everything forbidden by default and then opt-in what’s allowed? Why would writing to /opt be possible to begin with?