|| ||Kees Cook <keescook-AT-chromium.org> |
|| ||Tetsuo Handa <penguin-kernel-AT-i-love.sakura.ne.jp> |
|| ||Re: [PATCH v6] LSM: Multiple concurrent LSMs |
|| ||Wed, 7 Nov 2012 07:16:07 -0800|
|| ||casey-AT-schaufler-ca.com, jmorris-AT-namei.org,
|| ||Article, Thread
On Wed, Nov 7, 2012 at 5:15 AM, Tetsuo Handa
> There are three reasons I want to allow legal registration of LKM-based LSM
> modules after the init process starts.
> First is that many distributions nowadays enable multiple LSM modules. Since
> LSM modules cannot be a LKM, all possible LSM modules have to be built-in,
> bloating the vmlinuz file. If LSM modules are allowed to be a LKM, distributors
> can reduce the size of vmlinuz (making the kernel load time shorter). TOMOYO is
> sitting here waiting for legal registration of LKM-based LSM modules.
> Second is that several distributions (e.g. Fedora and RHEL) enable only one LSM
> module (e.g. SELinux). On such distributions, users who want to use other LSM
> modules at their own risk have to replace the kernel package; this limitation
> is a strong psychological barrier and maintenance burden for such users. I'm
> using AKARI (which is a LKM-based TOMOYO) for troubleshooting RHEL systems
> because replacing the kernel package (in order to use TOMOYO) is unlikely
> acceptable for RHEL users.
> Third is that LSM is not the tool for thought control. LSM should be the tool
> for minimizing the burden of all subsystems' maintainers.
> I hope LSM folks have learned that "not everybody can configure SELinux" and
> "even AppArmor is not configurable for somebody"
> ( http://events.linuxfoundation.org/images/stories/pdf/lcna... )
> and "Yama is sufficient for some users" and other (not yet in-tree) modules may
> be sufficient for some other users
> ( http://events.linuxfoundation.org/images/stories/pdf/lcna... ).
> For accelerating the development of custom LSM module which users really want,
> LSM interface should be opened to allow LKM-based LSM modules.
FWIW, I tend to agree here -- it would be nice to get LKM-based LSM
back. Anyone paranoid enough about adding LSMs can disable module
That said, given the size of this patch, perhaps we could keep LKM
enabling in the design consideration, but make it a separate patch? I
don't think LKM enabling should block getting the stacking patch in.
Chrome OS Security
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)