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.
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.
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).
I don’t know. I first heard about this from grsec grsecurity forums • View topic - Recent Advances: How We Learn From Exploits
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.
These might be a bit much grub boot menu default entries. We already have 4:
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:
(By default entry I mean: easily accessible in grub default boot menu.)
This discussion cannot really be separated from multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode.
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-everythingapparmor-superrootapparmor-debugThese 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:
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 user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode.
Good question.
superroot:
/usr/bin/sudo and /usr/bin/sudoedit apparmor unconfined by apparmor-profile-everything?admin only (if that is possible)?sudoedit /etc/apt/sources.list.d/custom.list to be writeable?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)?/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:
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.
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.
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 user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode - #32 by Patrick
“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”.
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.
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 user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode - #34 by Patrick)
What about aadebug?
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 - #220 by Patrick.
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.
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.”
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).
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?
Possibly? Pre boot FDE password entry is inside initramfs or outside?
Outside. The bootloader decrypts everything before starting the initramfs.
What does this have to do with it?