Hi Patrick and anyone listening on the line,
Patrick Schleizer wrote (09 Jun 2014 14:20:15 GMT) :
> I have two ideas on how to implement this and might eventually even be
> able to submit patches for this.
I like reading this. Thanks for working on it! :)
> 1) A clean solution, that can be implemented in the grub-common package:
> In /etc/grub.d/10_linux it could be attempted to run aa-status and if it
> exits 0, the following line
> [...]
> could be extended with
> apparmor=1 security=apparmor
It looks like the user story you have in mind to enable AppArmor
"permanently" would then be:
* in GRUB menu, manually enable AppArmor
* boot Debian
* run update-grub
* now AppArmor is enabled by default
Right?
My main problem with that it turns the current (possibly temporary,
e.g. for debugging) system state into the permanent one. This seems
potentially very confusing to users.
E.g. if I boot Debian while manually disabling AppArmor for some
reason, and then e.g. upgrade the Linux kernel, then update-grub is
automatically run, and AppArmor will be disabled for the following
boot. That's not what I would expect to happen. Same for the opposite
story, if I decide to try AppArmor once and run "apt upgrade", I don't
expect my one-shot decision to be silently turned into
a permanent one.
> 2) A less clean solution that can be implemented in the apparmor package:
> Create a script /etc/grub.d/39_apparmor, that searches
> /boot/grub/grub.cfg for [...]
I don't think we want to go into that: parsing and patching grub.cfg
in a safe and robust way is hard. Maybe the Augeas lens shipped in
augeas-lenses is good enough to do so *now*, but it's hard to be sure
that it will always remain that good.
Anyway, I eventually took time to look at how update-grub works, and
I think I've found a clean solution to this problem: grub-mkconfig
sources ${sysconfdir}/default/grub.d/*.cfg after sourcing
${sysconfdir}/default/grub, so all we have to do is ship
/etc/default/grub.d/apparmor.cfg, that would inject what we want into
GRUB_CMDLINE_LINUX. May you please test this?
Still, there's a potential issue with grounding the decision on
whether the apparmor package is installed: I've seen packages
gratuitously depend on apparmor (see e.g. #751452), merely because
they're shipping a profile, so this could cause more unexpected
behavior: I don't think we want to turn AppArmor on without at least
*one* conscious decision from the user, at least in the current state
of things. Maybe a Lintian warning raised when a package depends on
the apparmor one, and it's not on some whitelist of packages that
really need to depend on it, would be enough to catch most of these
problems, though.
What do you think?
Cheers,
--
intrigeri
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
