AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policy

https://forums.grsecurity.net/viewtopic.php?t=2574

There have been numerous ASLR holes due to /proc/[pid]/{,stat,maps,auxv} which we allow access to in apparmor-profile-everything. We should restrict these but test if it breaks anything.

1 Like

Denying access to /proc/[pid]/stat breaks a ton of stuff. We can probably fix that issue in another way (see how e.g. GRKERNSEC_PROC_MEMMAP fixes it).

I’m seeing some errors for /proc/[pid]/{,maps,auxv} but it doesn’t seem like anything major.

1 Like

Rename networking to networking-aae by madaidan · Pull Request #38 · Kicksecure/apparmor-profile-everything · GitHub merged.

1 Like

https://openwall.info/wiki/p_lkrg/Protected_Features#Protected-Process-example

This could be used to further protect privileged processes like apt.

madaidan via Whonix Forum:

Historical formerly experimental Linux Kernel Runtime Guard (LKRG) features [Openwall Community Wiki]

This could be used to further protect privileged processes like apt.

It’s part of LKRG experimental branch. Not part of LKRG main branch.
LKRG experimental branch as far I know was deprecated and LKRG upstream
wiki is outdated. If you like a more certain answer, please check in
LKRG source code or ask upstream LKRG.

1 Like

4 posts were split to a new topic: risks of writing to /dev/random, crediting entropy, RNDADDENTROPY related to untrusted root

1 Like
1 Like
1 Like

All merged.

Is /proc/pid/sched spy on keystrokes - proof of concept spy-gksu covered by apparmor-profile-everything yet?

1 Like

No, /proc/pid/sched is allowed. We’ll need to test if removing it breaks anything.

1 Like

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.

1 Like

@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.

2 Likes

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.

2 Likes

I intend to create individual apparmor profiles for each default process as per principle of least privilege.

1 Like

madaidan via Whonix Forum:

Add Xorg apparmor profile by madaidan · Pull Request #42 · Kicksecure/apparmor-profile-everything · GitHub

Fixes by madaidan · Pull Request #43 · Kicksecure/apparmor-profile-everything · GitHub

Merged.

1 Like

madaidan via Whonix Forum:

Remove write access to /proc/mtrr by madaidan · Pull Request #44 · Kicksecure/apparmor-profile-everything · GitHub

Only allow access to module info in debug mode by madaidan · Pull Request #45 · Kicksecure/apparmor-profile-everything · GitHub

Merged.

1 Like

Though, there was a merge conflict which I resolved. You you please check files look as intended in git master?

1 Like