[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

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

madaidan via Whonix Forum:

Dunno. What do you think?

Using source code based implementations, declarative implementations are
always easier to grasp than any auto generated, scripted, patched
implementations. Hence #include is strongly preferred.

1 Like

Attackers can read program binaries to try and find vulnerabilities. Important binaries like SUID ones are sometimes made unreadable for security.

Should all binaries (or just important ones like apt-get) be unreadable?

This wouldn’t have much of a security gain as an attacker can just read the open source code, read the libraries the program uses or ptrace the process. ptracing can be easily fixed though.

Also see https://stackoverflow.com/questions/29083388/why-is-it-common-for-binary-elf-suid-executables-to-also-allow-read-access

I don’t see any security advantage at all. Have there ever been cases where this would have helped? Therefore lets not add complication without gain.

One point makes sense though. Although for usability. Not security. If we remove suid then it should also remove read and exec for user. That way things fail closed and obvious rather than failing open. (su reporting wrong password even though password incorrect and no suid).

1 Like

I don’t know. I first heard about this from grsec https://forums.grsecurity.net/viewtopic.php?t=2939

I’m working on the boot modes here https://github.com/madaidan/apparmor-profile-everything/tree/boot-modes

I just have a single init-systemd file that contains all 3 profiles.

What should I add to debug and superroot?

I also need to add a grub menu but haven’t figured that out yet.

1 Like

These might be a bit much grub boot menu default entries. We already have 4:

  • persistent boot
  • recovery mode persistent boot
  • live boot
  • recovery mode live boot

Option recovery mode live boot is way too unimportant (given much important boot modes) to have a default entry. But I just now figured out how to get rid of it. Soon we will have three default boot menu entries:

  • persistent boot
  • recovery mode persistent boot
  • live boot

(By default entry I mean: easily accessible in grub default boot menu.)

Related: multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot

This discussion cannot really be separated from multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot.

I am not longer sure, should there be a root boot mode default entry or superoot default default entry or both? Will ask in above forum thread.

Could you please either replace the following or add an additional short options?

  • no-apparmor-profile-everything
  • apparmor-superroot
  • apparmor-debug

These are quite a lot to type when typing these manually. Suggestions for shorter versions:

  • no-apparmor-profile-everything -> noape
  • apparmor-superroot -> superroot
  • apparmor-debug -> aadebug

In some situations (Qubes) these options may not be (easily) accessible through Qubes boot menu but manually typing kernel boot parameters only (in Qubes VM settings, kernel parameter).

Suggested criteria for good short kernel boot parameter names:

  • short
  • easy to type
  • hard to misread / type wrong
  • not inappropriately conflicting with existing boot option
  • unlikely to be picked in future by a different project which isn’t aware of us (so we don’t have to change these later) to avoid double-use of these

apparmor-debug -> aadebug… Maybe for that one we could “hijack” (if there already is such a kernel boot parameter) debug?

I don’t think we should add 3 more default boot menu entries? noape, aadebug don’t seem important enough to be added as grub default boot menu entries?

For now we could merge your git branch immediately without adding any new grub boot menu entries. For now we could type noape, superroot, aadebug manually. Until we figured out the design (which menu entries should be default) and implementation of multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot.

1 Like

Good question.

superroot:

  • Allow running /usr/bin/sudo and /usr/bin/sudoedit apparmor unconfined by apparmor-profile-everything?
  • (Usual pam sudo password checking still applies. No changes required.)
  • Perhaps for user admin only (if that is possible)?
  • That would result in sudoedit /etc/apt/sources.list.d/custom.list to be writeable?
  • While sudo tcpdump wouldn’t be restricted by apparmor-profile-everything it would still be restricted by (exists really) /etc/apparmor.d/usr.sbin.tcpdump, which is good (and which the admin could disable if wanted)?
  • Or invent a new wrapper /usr/bin/supersudo which is allowed to run /usr/bin/sudo unconfined? That way a sysadmin or developer could easily within the same session compare apparmor-profile-everything restricted sudo vs unrestricted sudo. Similar for sudoedit.

debug:

  • dmesg
  • journalctl
  • /var/logs
  • Not sure. Can add more stuff on demand.
1 Like

What’s the point of full system confinement if you allow sudo unconfined?

Whatever the policy would stop an attacker from doing, the attacker can just preface with sudo.

1 Like

Indeed, well, that is the disadvantage of the superroot boot mode.

It’s only for the superroot boot mode. I wouldn’t know how else to implement superroot, i.e. allow manipulation of files such as in /etc/apt/sources.list.d folder or other files deemed dangerous for untrusted root. superroot is same as “trusted” root. Same as Whonix has prior apparmor-profile-everything or same as most Linux distributions.

1 Like

We can just not source the dangerous-files abstraction for superroot. At least then, an attacker has to do some work to bypass the restrictions.

That would not be superroot.
The idea of superroot is “anything goes”. Or “old Whonix”. Or “similar sudo like most Linux desktop distribution such as Debian”.
Something that stays out of the way of expert, developer or lazy users. A freedom feature.

(As mentioned here there will likely be the following grub boot menu default entries:

  • PERSISTENT mode USER (For daily activities.) (this includes “full” apparmor-profile-everything)
  • LIVE mode USER (For daily activities.) (this includes “full” apparmor-profile-everything)
  • PERSISTENT mode ADMIN (For software installation.) (this includes “full” apparmor-profile-everything)
  • PERSISTENT mode SUPERADMIN (Be very cautious!)

Add yet another mode? “superroot, but an attacker has to do some work to bypass the restrictions” - short name? Worth adding?

There are many different faccetes between security / freedom. I was hoping with three boot options (user-only, root but apparmor-profile-everything restricted, and superroot (fully unrestricted)) would give a sufficient balance. Something everyone could be happy with.

Btw I am making “some good progress” implementing the the grub boot menu entries. Will be “similar” to this very post: multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot

“similar”: Well, some things are non-ideal by technical limitations of grub-mkconfig such as recovery mode might be the second and not last boot menu entry. I am not sure yet. Still in process.

“some progress” = boot menu entries that allow setting kernel boot parameters. Not a full implementation of “boot/login into user” vs “boot/login into admin”.

1 Like

Then we can add

owner=(root) /** rwmlkpix,
capability,

Should give root complete access to the entire filesystem and all capabilities while every other user is still restricted.

I don’t think it should be added. Too many boot menus will just confuse people.

1 Like

Sounds very good!

These grub default menu entries were implemented.

Please review.

Looked at /boot/grub/grub.cfg which looks good but entirely untested in a live boot for now. I thought this might be a good visualization for discussion.

Let me know if these grub boot menu entries need adjustments to work well with apparmor-profile-everything.

(Also posted here: multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot)

1 Like

What about aadebug?

1 Like

Only manual kernel boot parameter (through grub boot menu key press e). No default grub boot menu entry. As per this post AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policy.

If we still want to go for aadebug at all? Maybe already covered by superroot? Or another default grub boot menu entry PERSISTENT mode ADMIN with DEBUG? I hope not.

1 Like

aadebug should still be a thing so people can do basic debugging without worsening security too much.

Not having a boot menu for aadebug is a good idea so it doesn’t get too bloated.

Also, is it possible to add a warning to superadmin? e.g. user tries to boot with the superadmin boot menu, it pops up with a message saying something like “Don’t use this unless you know what you’re doing. Be very cautious etc. Consider using aadebug instead.”

1 Like

That is a good idea.

A nested grub boot menu is not possible due to the /etc/grub.d / update-grub framework limitations.

A systemd unit file that runs very early at boot could do. Systemd unit files are capable of accepting user terminal input such. There could be an option YES (continue boot) | NO (reboot) and a timeout which continues booting after XX seconds. Systemd unit files are as far as I know also capable of interrupting the boot process until some systemd unit has finished (timeout).

1 Like

That may be too late and the malware could’ve already exploited superroot.

It would be best to have it pre-boot. Maybe an ncurses menu in the initramfs? Is that even possible?

1 Like

Possibly? Pre boot FDE password entry is inside initramfs or outside?

1 Like

Outside. The bootloader decrypts everything before starting the initramfs.

What does this have to do with it?

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]