Hi,
Patrick Schleizer wrote (20 Jun 2014 19:32:47 GMT) :
> intrigeri:
>> Patrick Schleizer wrote (09 Jun 2014 14:20:15 GMT) :
>>> 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
> [...]
> if [ $? = 3 ]; then
> # AppArmor not enabled in kernel.
> # Let's enable it.
> maybe_apparmor="apparmor=1 security=apparmor"
> fi
Ah, OK. That's the part that was not obvious to me in your initial
email. Thanks for clarifying. Anyway, let's forget that solution and
work on the other :)
>> 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!
Thanks for trying it!
> 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?
Yes, ordering requires more thought, and a survey of how other
packages that ship snippets into /etc/default/grub.d/ do. Are you up
to it?
> Could you add the /etc/default/grub.d/10_apparmor.cfg config file to the
> apparmor package then please?
Once someone has thought through the ordering thing, and the Lintian
warning is implemented, I'd personally be happy to provide a patch
against the apparmor package that implements this.
>> 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.
I tend to agree, but that's valid if, and only if, no package
gratuitously depend on the apparmor package, which we need to guard
against first.
>> 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.
Are you interested in working on this? At least filing a wishlist bug
against Lintian, describing the need, and marking #702030 as blocked
by that other bug would be a good start.
> I don't understand the need for a whitelist, though. That's
> what lintian overrides are for?
I would find it inelegant to add such an override in
apparmor-{utils,profiles,profiles-extra}. But probably that's merely
personal taste, and the Lintian maintainers might feel differently
about it.
Looking forward to see you take the next steps :)
Cheers,
--
intrigeri
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
