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

AppArmor
303

Did everything you asked.

https://github.com/madaidan/apparmor-profile-everything/blob/net_admin/lib/systemd/system/networking.service.d/30_apparmor_profile_everything.conf

https://github.com/madaidan/apparmor-profile-everything/blob/net_admin/sbin/networking-aae

1 Like
304

Yes. systemd drop-in support is amazing. Hard to ask for better features. It explicitly supports that use case. It supports to totally replace/overwrite existing keywords or expand these too.

Just noticed. I made a mistake. The actual syntax for a drop-in is this:

[Service]
ExecStart=
ExecStart=/sbin/networking up
ExecStop=
ExecStop=/sbin/networking down

The first ExecStart= tells systemd to clear all previous ExecStart keywords. Otherwise it would keep the existing one and only expand, i.e multiple ExecStart=.

1 Like
305

Fixed

1 Like
306

The ordering of dangerous-files got messed up a bit when the pull requests were merged. apparmor-profile-everything/dangerous-files at master · Kicksecure/apparmor-profile-everything · GitHub should be just below the systemd lines, not the kernel.d lines.

1 Like
307

It might be better to just fix this directly in the kernel with a patch adding a kernel.dmesg_restrict=2 sysctl rather than trying to hack our way around it.

308

To debug, view logs… Could you use a “backdoor”? A way to make yourself superroot with /path/to/unconfined/sudo/script so you can view logs? Or serial console login as root?

1 Like
309

madaidan via Whonix Forum:

I don’t know what that is.

1 Like
310

madaidan via Whonix Forum:

Maybe displace would be better for this than str_replace.

That one I don’t understand.

1 Like
311

madaidan via Whonix Forum:

correct variable assignment order by nyxnor · Pull Request #2 · Whonix/whonix-firewall · GitHub

It is not enforcing the actual firewall scripts. The actual firewall
scripts are in /usr/bin, see

https://github.com/Whonix/whonix-firewall/blob/master/usr/lib/whonix-firewall/enable-firewall
is only a helper script for systemd.

1 Like
312

That was just to make networking.service execute our wrapper but now that we have the drop-in, it doesn’t matter.

It is. /usr/lib/whonix-firewall/enable-firewall executes /usr/bin/whonix_firewall which executes /usr/bin/whonix-workstation-firewall or /usr/bin/whonix-gateway-firewall.

1 Like
313 
sudo whonix_firewall
sudo /usr/bin/whonix_firewall

is a common use case. Used in Whonix documentation. Users run that manually. Therefore needs to be contained or the way users interact with that needs to be changed in the wiki and /usr/bin files would have to be moved elsewhere to discourage that.

1 Like
314
1 Like
315

Need /usr/lib too since that one comes with fallback lockdown firewall rules on error.

1 Like
316

It confines both now whonix-firewall/whonix-firewall at apparmor · madaidan/whonix-firewall · GitHub using an abstraction whonix-firewall/whonix-firewall at apparmor · madaidan/whonix-firewall · GitHub

1 Like
317

I don’t know how, but everything’s breaking now. I created a new KVM VM, switched to the dev repo and installed apparmor-profile-everything. XFCE fails to start and systemd is spamming errors about not being able to write to something in /run/ and /sys/fs/cgroup/ even though that’s allowed:

apparmor-profile-everything/init-systemd at master · Kicksecure/apparmor-profile-everything · GitHub

apparmor-profile-everything/init-systemd at master · Kicksecure/apparmor-profile-everything · GitHub

There are a few more errors but Fixes by madaidan · Pull Request #30 · Kicksecure/apparmor-profile-everything · GitHub fixes most of them.

318

Doesn’t work. Run

capsh --drop=all --

as root which gets rid of all capabilities, including CAP_SYS_PTRACE. Root can still see other user’s processes.

The only way we can probably hide this is to restrict every /proc rule to owner or a kernel patch. Both of which might cause tons of breakage.

319

This can’t be solved with apparmor-profile-everything since the kernel gives it away. It isn’t found with any file.

We’d have to patch it out.

https://paste.debian.net/hidden/1ecd5569/

Although, there may be some files that might also leak this information.

320

madaidan via Whonix Forum:

Doesn’t work. Run

capsh --drop=all --

as root which gets rid of all capabilities, including CAP_SYS_PTRACE. Root can still see other user’s processes.

The only way we can probably hide this is to restrict every /proc rule to owner or a kernel patch. Both of which might cause tons of breakage.

If we cannot restrict “real root” enough, could we perhaps instead give
user admin similar permission than “real root” except for those we
don’t want to give?

The question boils down to:

  • “What should user user be able to do?” No “sudo su”. No “sudo
    anything” except for things listed in /etc/sudoers.d. User rights only.
  • “What should user admin be able to do?” Maybe create a list of
    commands / tasks that are usually done using sudo/root and then allow
    user admin to do it?
  • “What should user superadmin be able to do?” “Everything.”
1 Like
321

That doesn’t get rid of “real root” though. It still exists and is still being used by certain system services so we still need to restrict it.

Although it would be good to give a subset of root to an admin user so users can use it for certain things e.g. installing packages but not dangerous things.

1 Like
322

Btw I’ve created a patch that should allow us to restrict real root with a hidepid=3 mount option but I’ve yet to test it.