Hi, On Thu, Nov 18, 2010 at 08:37:44PM +0100, Julien Cristau wrote: > On Thu, Nov 18, 2010 at 11:23:39 -0800, Kees Cook wrote: > > > On Thu, Nov 11, 2010 at 13:52:12 +0000, maximilian attems wrote: > > > LSM: Enable AppArmor? as well as/instead of Tomoyo? > > > --------------------------------------------------- > > > As the LSM need to be built we can't enable them. This needs a technical > > > solution were code can be disregarded as init sections or similar. > > > AppArmor seems more popular as Opensuse and Ubuntu uses it. Technicaly > > > Tomoyo is said to be cleaner. > > > > What do you mean by "can't" here? You can build _all_ of them, > > actually. The active LSM is just selected at boot-time through the > > kernel command line arguments. If it's a concern over kernel size, > > upstream specifically removed the ability to make the LSM modular, > > so this means that no additional LSMs will ever be available in Debian? > > > See the second sentence. "This needs a technical solution where code can > be disregarded as init sections or similar." So your kernel has a bunch > of LSMs builtin, but at boot time one of them is selected and you > release the memory taken by the rest of them instead of keeping the code > lying there unused.
Right, my point was that upstream expressly moved away from that ability, which means, if combined with the other "only if in upstream" statements, the Debian kernel will only ever be built with one LSM. Now, don't get me wrong, I'd hugely prefer there be an __init-like way to handle this, and it actually touches on the constification work too. Still, blocking until the feature exists seems unfun. :) Thanks, -Kees -- Kees Cook @debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118200333.gg13...@outflux.net
