Subject: [PATCH 0/5] Allow LKM-based LSM modules.
Date: Monday 19th November 2012 13:57:28 UTC (over 5 years ago)
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_co2012_handa.pdf ) 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_co2012_henderson.pdf ). 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html