[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1477054150-4772-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
Date: Fri, 21 Oct 2016 21:49:02 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: linux-security-module@...r.kernel.org
Cc: linux-kernel@...r.kernel.org,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Subject: [PATCH 0/8] CaitSith LSM module
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
Powered by blists - more mailing lists