[PATCH 0/8] CaitSith LSM module

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

CaitSith (acronym for "Characteristic action inspection tool. See if
this helps.") is an LSM based access control implementation which uses
action check list (acl) as policy syntax.

Syntax of an acl block is shown below.

  acl "Action" "Whether to check Action or not"
    "Decision1" "Whether to use Decision1 or not"
    "Decision2" "Whether to use Decision2 or not"
    "Decision3" "Whether to use Decision3 or not"

  Specify Action as a key, and enumerate conditions as needed
  using variable=value or variable!=value expression.

  Split into two phases: "whether to check or not" and "whether
  to grant/deny or not".

  "Action" is name of action (e.g. "execve").

  "Decision" is either "allow" or "deny".

  You can define multiple acl blocks as needed. All acl blocks for
  each "Action" will be evaluated. The access request will be granted
  when none of deny line in all evaluated acl blocks matches.

  An unsigned integer value is prefixed to each line of rules for
  controlling priority of evaluation.

Examples shown below will help you understanding.

  Example 1: /usr/sbin/httpd is allowed to execute only
             /var/www/cgi-bin/counter.cgi and /usr/bin/suexec .

    1000 acl execute task.exe="/usr/sbin/httpd"
      100 allow path="/var/www/cgi-bin/counter.cgi"
      150 allow path="/usr/sbin/suexec"
      200 deny

  Example 2: /usr/sbin/httpd is not allowed to execute /bin/sh and
             /bin/bash .

    2000 acl execute task.exe="/usr/sbin/httpd"
      100 deny path="/bin/sh"
      150 deny path="/bin/bash"
      200 allow

  Example 3: /usr/sbin/suexec is allowed to be executed by only
             /usr/sbin/httpd .

    2000 acl execute path="/usr/sbin/suexec"
      100 allow task.exe="/usr/sbin/httpd"
      200 deny

CaitSith tries to remove many limitations which existing security
enhanced Linux (I mean any LSM based access control implementation) has.

  (1) CaitSith can use both string / numeric arguments (like TOMOYO and
      AppArmor) and security labels (like SELinux and Smack). There is no
      reason that access control implementation must not use both.

  (2) CaitSith can specify rules from the point of view of both subjects
      (a.k.a. capability list) and objects (a.k.a. access control list).
      There is no reason that access control implementation must use
      capability list which entails identification of all subjects.

      While security people are tempted to protect as much as possible,
      users generally have insufficient resource for protecting all. If
      users have sufficient resource, they will be already using existing
      implementations.

      I found users who want to restrict only a few objects without
      being bothered by managing all subjects in their systems. This is
      impossible for TOMOYO because TOMOYO entails managing all subjects
      in their systems. In CaitSith, this limitation is solved by writing
      rules using action as a key.

  (3) CaitSith can represent complicated string / numeric arguments
      compared to TOMOYO, for any condition is represented as zero or
      more repetition of variable=value or variable!=value expression.

      In TOMOYO, the policy syntax requires positional mandatory parameters
      (e.g. pathname when opening a pathname, pathname and DAC permission
      mode when creating a pathname) based on type and number of arguments
      for that action. But it turned out that using positional parameters
      undesirably limits ability to specify complicated conditions. For
      example, when specific pattern should be excluded from some pattern
      (e.g. "*" but "*.tmp"), administrator has to use \- operator (e.g.
      "\*\-\*.tmp") for that purpose. It makes conditions difficult to
      understand. \- operator needs to be used with cautions that unwanted
      patterns are not included by error. It made complicated conditions
      very hard to understand.
      In CaitSith, this limitation is solved by writing rules like
      path="\*" path!="\*.tmp" instead of path="\*\-\*.tmp" .

  (4) CaitSith can specify rules using both whitelisting and blacklisting.

      As far as I know, whoever involved in security enhanced Linux in
      Japan lost their jobs. In other words, security enhanced Linux made
      no business sense in Japan. I think that existing implementations
      are asking for too much skill/knowledge compared to users can afford.

      CaitSith's syntax acts as whitelisting if an unconditional deny line
      comes before an unconditional allow line comes, acts as blacklisting
      if an unconditional allow line comes before an unconditional deny
      line comes.

CaitSith stayed four years and a half listening for whether it suits
user's needs. In the last year or so, questions regarding how to use
TOMOYO are getting to come. However, it turned out that CaitSith seems
to fit better than TOMOYO for what many of the questioners want to
achieve. You can see slides shown below for full explanation of
the how and why.

  http://I-love.SAKURA.ne.jp/tomoyo/CaitSith-en.pdf (English)
  http://I-love.SAKURA.ne.jp/tomoyo/CaitSith-ja.pdf (Japanese)

In order to minimize the burden of reviewing, this patchset implements
only functionality of checking program execution requests (i.e. execve()
system call) using pathnames. I'm planning to add other functionalities
after this version got included into mainline. You can find how future
versions of CaitSith will look like at http://caitsith.osdn.jp/ .

Tetsuo Handa (8):
  CaitSith: Add header file.
  CaitSith: Add pathname calculation functions.
  CaitSith: Add policy I/O functions.
  CaitSith: Add permission check functions.
  CaitSith: Add LSM adapter functions.
  CaitSith: Add policy loader functions.
  CaitSith: Add garbage collector functions.
  CaitSith: Add Kconfig and Makefile

 security/Kconfig                |    6 +
 security/Makefile               |    2 +
 security/caitsith/Kconfig       |   48 ++
 security/caitsith/Makefile      |   15 +
 security/caitsith/caitsith.h    |  347 +++++++++
 security/caitsith/gc.c          |  373 ++++++++++
 security/caitsith/load_policy.c |  106 +++
 security/caitsith/lsm.c         |   60 ++
 security/caitsith/permission.c  |  691 +++++++++++++++++
 security/caitsith/policy_io.c   | 1553 +++++++++++++++++++++++++++++++++++++++
 security/caitsith/realpath.c    |  227 ++++++
 11 files changed, 3428 insertions(+)
 create mode 100644 security/caitsith/Kconfig
 create mode 100644 security/caitsith/Makefile
 create mode 100644 security/caitsith/caitsith.h
 create mode 100644 security/caitsith/gc.c
 create mode 100644 security/caitsith/load_policy.c
 create mode 100644 security/caitsith/lsm.c
 create mode 100644 security/caitsith/permission.c
 create mode 100644 security/caitsith/policy_io.c
 create mode 100644 security/caitsith/realpath.c

-- 
1.8.3.1