Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Tetsuo Handa <penguin-kernel <at> I-love.SAKURA.ne.jp>
Subject: [PATCH 0/5] Allow LKM-based LSM modules.
Newsgroups: gmane.linux.kernel.lsm
Date: Monday 19th November 2012 13:57:28 UTC (over 4 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
 
CD: 3ms