Hi!
intrigeri:
> 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
Absolutely not.
> * boot Debian
> * run update-grub
> * now AppArmor is enabled by default
>
> Right?
[Since your solution is simpler and better, and I had this already
written, this is just FYI maybe.]
No, I was proposing a patch for /etc/grub.d/10_linux in the grub-common.
Currently:
message="$(gettext_printf "Loading Linux %s ..." ${version})"
cat << EOF
echo '$message'
linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion}
ro ${args}
EOF
Proposed:
I had something in mind like this. Untested. Needs more thought. Some
useless code just to express the idea.
which aa-status >/dev/null 2>&1
if [ $? = 0 ]; then
aa-status >/dev/null 2>&1
if [ $? = 0 ]; then
# AppArmor enabled, let's keep it.
maybe_apparmor="apparmor=1 security=apparmor"
fi
if [ $? = 2 ]; then
# AppArmor disabled by user with "/etc/init.d/apparmor teardown".
# Leave it disabled.
maybe_apparmor=""
fi
if [ $? = 3 ]; then
# AppArmor not enabled in kernel.
# Let's enable it.
maybe_apparmor="apparmor=1 security=apparmor"
fi
else
maybe_apparmor=""
fi
message="$(gettext_printf "Loading Linux %s ..." ${version})"
cat << EOF
echo '$message'
linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion}
ro ${maybe_apparmor} ${args}
Imagined like this:
1) sudo apt-get install apparmor
2) apparmor automatically gets enabled. Seems to be the Debian way. If
you install any daemons, most are automatically started.
3) /etc/grub.d/10_linux does the magic to enable apparmor in grub.cfg,
so it gets enabled on next reboot.
4) Maybe users who want to disable apparmor while leaving the apparmor
package installed could use "apparmor=0 security=" in /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT.
5) Maybe we can detect if users did run "/etc/init.d/apparmor teardown"
and not enable apparmor on next update-grub as well. Maybe
/etc/init.d/apparmor should run update-grub.
> 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.
I am not sure I understand.
>> 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.
Valid point.
> 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?
Requires Debian Jessie.
It works! Great solution!
Shouldn't we use a number in front of the config file such as
/etc/default/grub.d/10_apparmor.cfg, to get a useful order and to make
it simpler for users to overrule it?
Could you add the /etc/default/grub.d/10_apparmor.cfg config file to the
apparmor package then please?
> I don't think we want to turn AppArmor on without at least
> *one* conscious decision from the user,
I view "sudo apt-get install apparmor" as my conscious decision and
would expect AppArmor getting enabled. As far I understand the debian
way is install a package = enable it's functionality (such as when you
install a package containing a daemon [ex: apache2] it usually gets
automatically started by default.
> I've seen packages
> gratuitously depend on apparmor (see e.g. #751452), merely because
> they're shipping a profile
Agreed with your bug report. Sounds like an easy to fix, grave bug
[making the package unfit for release] [but the experienced DD's are
better qualified to decide on that].
> 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.
Good idea. I don't understand the need for a whitelist, though. That's
what lintian overrides are for?
Cheers,
Patrick
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
