To: john.johansen@canonical.com, linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/8] CaitSith LSM module
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
References: <1477054150-4772-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
        <3232ef1d-b378-a8a2-f113-03b2db4cc332@canonical.com>
In-Reply-To: <3232ef1d-b378-a8a2-f113-03b2db4cc332@canonical.com>
Message-Id: <201610252026.HCH52140.FOtVFOJLQMSOHF@I-love.SAKURA.ne.jp>
Date: Tue, 25 Oct 2016 20:26:00 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 5011
Lines: 99

John Johansen wrote:
> 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.

I see.

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

I can't predict that. There are users who migrated to CaitSith, but there are
also users who continue using TOMOYO. Users will choose from any implementation
based on what is most suitable for their goals. I'm trying to rescue users
who are trying to use TOMOYO for usages which TOMOYO did not expect.

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

Thank you for your time.