Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933577AbcJUMtn (ORCPT ); Fri, 21 Oct 2016 08:49:43 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:39000 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933461AbcJUMtf (ORCPT ); Fri, 21 Oct 2016 08:49:35 -0400 From: Tetsuo Handa To: linux-security-module@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Tetsuo Handa Subject: [PATCH 0/8] CaitSith LSM module Date: Fri, 21 Oct 2016 21:49:02 +0900 Message-Id: <1477054150-4772-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> X-Mailer: git-send-email 1.8.3.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6896 Lines: 156 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