if ! grep "apparmordebug" /proc/cmdline; then
echo "profile init-systemd /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a
elif grep "apparmordebug" /proc/cmdline; then
echo "profile init-systemd-debug /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a
fi
Does this include superroot? Some sort of superroot is required. Otherwise not even developers could experiment with changes to essential files such as init-systemd.
I don’t like the idea of including a “superroot” at all.
If developers need to experiment with changes, they can boot with apparmor=0, make the changes and reboot. Or, they can just give themselves write access to those files in the policies.
Booting without any apparmor at all isn’t great. That could be just the moment that malware is waiting for. I mean malware that would be contained thanks to an apparmor profile from breaking out but then breaking out for real due to a zero apparmor boot.
Choice “either apparmor-profile-everything or no-apparmor-at-all”, “perfect or nothing” isn’t a great choice.
I need to test changes without reboot because I get the syntax wrong too often to keep rebooting.
It’s also a software freedom feature. Refusing root access (or “real/full” root) access or “then break your system by disabling apparmor” is a software freedom restriction. [1]
Could be like this:
if grep "superroot" /proc/cmdline; then
echo "profile init-systemd-superroot /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a
elif grep "apparmordebug" /proc/cmdline; then
echo "profile init-systemd-debug /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a
else
echo "profile init-systemd /lib/systemd/systemd flags=(complain) {}" | /sbin/apparmor_parser -a
fi
[1] FSF was asked earlier about their position on root access refusal. That was interesting related to Android.
If the software is truly a piece of free software which respects your essential freedoms, then you would be able to modify it so that you can gain root access (or any other type of access) and re-install it on the device. If it does not allow that, then it isn’t free software.
However, Android has many freedom issues, and lack of root access is only one of them.
The Replicant project attempts to build a fully free Android distribution which runs on several devices. Please see: https://replicant.us/
An old attack[archive][13] was observed in the wild that exploited a JavaScript vulnerability in Firefox. [14] The observed version of the attack collected the hostname and MAC address of the victims’ computers, and sent that information to a remote web server. This threat is partially mitigated nowadays by the development of a security slider in the Tor Browser Bundle, which prevents the execution of JavaScript code completely with the correct settings. Nevertheless, Whonix ™ would have protected against a MAC address leak [15] and at worst leaked a hostname which is common to all Whonix ™ users.
Not a targeted attack at all. Fortunately the attacker only collected IP address and MAC address. Didn’t attempt to proceed to further infect the system with rootkits. But if it has been attempted, then apparmor might have prevented breakout of the confinement. This was an attack by a “somewhat good actor” which got caught and well analyzed. Not necessarily always that way.
Much less of a breakage than zero apparmor. I am pretty sure this will keep Free Software enthusiasts happy. I’ll even be writing documentation how to opt that boot mode in as a default boot mode. (Just modify /etc/default/grub.d.)
No need. The two or three files…
init-systemd-superroot [1]
init-systemd-debug [2]
init-systemd [3]
could be based on the same abstraction? And then [3] would just use the abstraction. [2] would have the abstraction and some relaxation on top. [1] would have further relexations on top.
I don’t see how would lower security for anyone who’s not using it. But once [2], [3] are implemented and all of this matured, we can look into [1] and see how would influence the security.
That time yes. But nothing in principle made Linux immune. Just “luck” it was the good guys attacking all Windows users and not someone else using it for bad. Well, one could make the argument once you’re using Linux, all security hardening is overkill. Yet, I suppose, it’s our enjoyment.
installation? No installation for VM images.
That would be an OK solution but I am not sure about the details, if patch is the best tool here. Boot modes seems more flexible/convenient since one can change easy from one to another.
That’s not true at all. A lot of security hardening is leaps behind overkill.
I meant package installation.
No, we’d still have the boot modes. The patching is just so the profiles are easier to maintain (1 profile instead of 3). We’d create copies of init-systemd then patch those copies. The boot modes would then switch between the patched copies.
Would [1], [2], [3] importing abstractions, i.e. have a line #include <abstractions/init-systemd> or #include <init-systemd-abstraction> (depending on file system layout) be a better options than patch?
Obviously, this shouldn’t be applied by default so users aren’t forced to use apparmor, but it can be optional for users that don’t care much about freedom and don’t want apparmor to ever be disabled.
This patch only allows apparmor to be disabled if CONFIG_SECURITY_APPARMOR_DISABLE is set. If it is not set, apparmor=0 does nothing.
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).
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.)
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?
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.
