lkml.org 
[lkml]   [2016]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[PATCH 0/8] CaitSith LSM module
    Date
    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

    \
     
     \ /
      Last update: 2016-10-21 14:50    [W:4.668 / U:0.352 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site