On Thu, Nov 23, 2017 at 02:18:46PM +0100, Christoph Hellwig wrote: > Hi all, > > is there any good reason for the recommends of apparmor in the latest > linux packages?
This is in response to a discussion that happened on this list. The thread started in august last year[1], but really picked up speed last month[2] and this one[3]. The idea is that, if no critical issues are found, buster would release with AppArmor enabled by default. If critical issues are found, however, I expect the decision will be reversed (or at the least, postponed). [1] https://lists.debian.org/debian-devel/2017/08/msg00090.html [2] https://lists.debian.org/debian-devel/2017/10/threads.html#00086 [3] https://lists.debian.org/debian-devel/2017/11/threads.html#00000 > apparomor is just one of many security modules, and > a fairly bogus one to start with. The kernel should not recommend it > as it doesn't add at all to the expected kernel functionality. If AppArmor is to become the default, then having it be recommended by the kernel is a proper way of implementing that; it would be pulled in by default, but if you don't want it it's still possible to remove it. (I won't comment on the "fairly bogus one" bit, I'm not that well versed in the specifics of AppArmor vs the other options there) > The changelog suggests it was done that systemd units might use it, > but in that case those systemd units should depend on apparmor. Perhaps the changelog could be clarified then, there are other reasons :-) > And to start with there probably should be a policty that no unit > file shall fail the boot for a missing security module (any of them). Yes, indeed. I haven't seen such a failure; but if you have, then please do file a bug -- that's not supposed to happen. Thanks, -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
signature.asc
Description: PGP signature
