Allow LKM-based LSM modules.

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html