|| ||Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> |
|| ||email@example.com |
|| ||[PATCH 0/5] Allow LKM-based LSM modules. |
|| ||Mon, 19 Nov 2012 22:57:28 +0900|
|| ||Article, Thread
This patchset changes LSM interface to legally accept registration of LKM-based
LSM modules and changes TOMOYO into a LKM-based LSM module.
[PATCH 1/5] TOMOYO: Make dependency on CONFIG_SECURITY_PATH/CONFIG_SECURITY_NETWORK optional.
[PATCH 2/5] TOMOYO: Rename security/tomoyo/tomoyo.c to security/tomoyo/lsm.c.
[PATCH 3/5] Allow runtime registration of LSM modules.
[PATCH 4/5] Export functions needed by TOMOYO loadable kernel module.
[PATCH 5/5] TOMOYO: Allow TOMOYO to become a loadable kernel module.
Why I want this?
We are now trying to change LSM interface to allow running multiple LSM
modules in parallel.
There are three reasons I want to allow legal registration of LKM-based LSM
modules after the init process starts.
(1) 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.
(2) 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. Currently 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.
TOMOYO is very useful for troubleshooting Linux systems. But if TOMOYO is
not chosen at the time of booting the kernel, there is no means to enable
TOMOYO for troubleshooting Linux systems. Speak of enterprise systems,
I learned from my current job that even restarting Java application is
difficult, let alone rebooting the system only for enabling LSM module.
I do need strace-like LSM module which can be enabled/disabled without
rebooting the system. If registration of LKM-based LSM modules becomes
legal, TOMOYO is the nearest position for using like strace utility.
(3) 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.
Without runtime loading support, for most Linux users, Yama will be the
only module that will be benefit by allowing running multiple LSM modules
in parallel. Not many can run SELinux/SMACK/TOMOYO/AppArmor in parallel.
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html