Subject: Re: [PATCH 0/8] CaitSith LSM module
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
        linux-security-module@vger.kernel.org
References: <1477054150-4772-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-kernel@vger.kernel.org
From: John Johansen <john.johansen@canonical.com>
Organization: Canonical
Message-ID: <3232ef1d-b378-a8a2-f113-03b2db4cc332@canonical.com>
Date: Mon, 24 Oct 2016 11:18:18 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <1477054150-4772-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 5893
Lines: 119

On 10/21/2016 05:49 AM, Tetsuo Handa wrote:
> 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.
> 

<< snip >>

> 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.
> 
In fact a full DTE implementation requires using 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)
> 

The majority of your points for CaitSith are comparisons to TOMOYO your other
LSM. In the long run do you see CaitSith replacing Tomoyo, as it seems to be
the LSM you are now focused on?

> 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/ .
> 
Thanks I've started working my way through this, but it is going to take
me a while.

> 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
>