[TOMOYO #7 08/30] Some of permission checks from VFS helper functions.

[TOMOYO #7 08/30] Some of permission checks from VFS helper functions.

[Tetsuo Handa]

[-- Attachment #1: tomoyo-tomoyo-vfs-header.patch --]
[-- Type: text/plain, Size: 4993 bytes --]

TOMOYO Linux performs pathname based access control,
but "struct vfsmount" is not passed to VFS helper functions
which is needed for deriving requested pathname.

Since I want to do conventional DAC's permission checks
before TOMOYO Linux's permission checks, I copied some of
permission checks from VFS helper functions.

The side effect of this approach is that DAC permission checks
are done twice. But the approach to pass "struct vfsmount" to
VFS helper functions seems unacceptable.

Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
---
 include/linux/tomoyo_vfs.h |  141 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 141 insertions(+)

--- /dev/null
+++ linux-2.6.25-rc8-mm1/include/linux/tomoyo_vfs.h
@@ -0,0 +1,141 @@
+/*
+ * include/linux/tomoyo_vfs.h
+ *
+ * Implementation of the Domain-Based Mandatory Access Control.
+ *
+ * Copyright (C) 2005-2008  NTT DATA CORPORATION
+ *
+ * Version: 1.6.0   2008/04/01
+ *
+ */
+
+#ifndef _LINUX_TOMOYO_VFS_H
+#define _LINUX_TOMOYO_VFS_H
+
+/*
+ * This file contains copy of some of VFS helper functions.
+ *
+ * Since TOMOYO Linux requires "struct vfsmount" parameter to calculate
+ * an absolute pathname of the requested "struct dentry" parameter
+ * but the VFS helper functions don't receive "struct vfsmount" parameter,
+ * TOMOYO Linux checks permission outside VFS helper functions.
+ * To keep the DAC's permission checks are performed before the
+ * TOMOYO Linux's permission checks are performed, I'm manually inserting
+ * these functions that performs the DAC's permission checks into fs/namei.c.
+ *
+ * The approach to obtain "struct vfsmount" parameter from
+ * the "struct task_struct" doesn't work because it triggers deadlock.
+ */
+
+/*
+ * Permission checks before security_inode_mknod() is called.
+ *
+ * This function is exported because
+ * vfs_mknod() is called from net/unix/af_unix.c.
+ */
+int pre_vfs_mknod(struct inode *dir, struct dentry *dentry, int mode)
+{
+	int error = may_create(dir, dentry, NULL);
+	if (error)
+		return error;
+	if ((S_ISCHR(mode) || S_ISBLK(mode)) && !capable(CAP_MKNOD))
+		return -EPERM;
+	if (!dir->i_op || !dir->i_op->mknod)
+		return -EPERM;
+	return 0;
+}
+EXPORT_SYMBOL(pre_vfs_mknod);
+
+/* Permission checks before security_inode_mkdir() is called. */
+static inline int pre_vfs_mkdir(struct inode *dir, struct dentry *dentry)
+{
+	int error = may_create(dir, dentry, NULL);
+	if (error)
+		return error;
+	if (!dir->i_op || !dir->i_op->mkdir)
+		return -EPERM;
+	return 0;
+}
+
+/* Some of permission checks before security_inode_rmdir() is called. */
+static inline int pre_vfs_rmdir(struct inode *dir, struct dentry *dentry)
+{
+	int error = may_delete(dir, dentry, 1);
+	if (error)
+		return error;
+	if (!dir->i_op || !dir->i_op->rmdir)
+		return -EPERM;
+	return 0;
+}
+
+/* Some of permission checks before security_inode_unlink() is called. */
+static inline int pre_vfs_unlink(struct inode *dir, struct dentry *dentry)
+{
+	int error = may_delete(dir, dentry, 0);
+	if (error)
+		return error;
+	if (!dir->i_op || !dir->i_op->unlink)
+		return -EPERM;
+	return 0;
+}
+
+/* Permission checks before security_inode_link() is called. */
+static inline int pre_vfs_link(struct dentry *old_dentry, struct inode *dir,
+			       struct dentry *new_dentry)
+{
+	struct inode *inode = old_dentry->d_inode;
+	int error;
+	if (!inode)
+		return -ENOENT;
+	error = may_create(dir, new_dentry, NULL);
+	if (error)
+		return error;
+	if (dir->i_sb != inode->i_sb)
+		return -EXDEV;
+	if (IS_APPEND(inode) || IS_IMMUTABLE(inode))
+		return -EPERM;
+	if (!dir->i_op || !dir->i_op->link)
+		return -EPERM;
+	if (S_ISDIR(old_dentry->d_inode->i_mode))
+		return -EPERM;
+	return 0;
+}
+
+/* Permission checks before security_inode_symlink() is called. */
+static inline int pre_vfs_symlink(struct inode *dir, struct dentry *dentry)
+{
+	int error = may_create(dir, dentry, NULL);
+	if (error)
+		return error;
+	if (!dir->i_op || !dir->i_op->symlink)
+		return -EPERM;
+	return 0;
+}
+
+/* Permission checks before security_inode_rename() is called. */
+static inline int pre_vfs_rename(struct inode *old_dir,
+				 struct dentry *old_dentry,
+				 struct inode *new_dir,
+				 struct dentry *new_dentry)
+{
+	int error;
+	const int is_dir = S_ISDIR(old_dentry->d_inode->i_mode);
+	if (old_dentry->d_inode == new_dentry->d_inode)
+		return 0;
+	error = may_delete(old_dir, old_dentry, is_dir);
+	if (error)
+		return error;
+	if (!new_dentry->d_inode)
+		error = may_create(new_dir, new_dentry, NULL);
+	else
+		error = may_delete(new_dir, new_dentry, is_dir);
+	if (error)
+		return error;
+	if (!old_dir->i_op || !old_dir->i_op->rename)
+		return -EPERM;
+	if (is_dir && new_dir != old_dir)
+		error = permission(old_dentry->d_inode, MAY_WRITE, NULL);
+	return error;
+}
+
+#endif

-- 

[TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Tetsuo Handa]

[-- Attachment #1: tomoyo-hooks.patch --]
[-- Type: text/plain, Size: 49226 bytes --]

This file contains modifications against kernel source code
needed to use TOMOYO Linux 1.6.

Although LSM hooks are provided for performing access control,
TOMOYO Linux 1.6 doesn't use LSM because of the following reasons.

Reason 1:

CONFIG_SECURITY=y adds security fields to various structures and
introduces hooks for allocating/freeing these security fields.
But TOMOYO Linux can hardly utilize them.

TOMOYO Linux requires modification against only "struct task_struct",
and adding two variables to "struct task_struct" is sufficient.

I think reserving LSM hooks for other security modules (e.g. SELinux, SMACK)
and making TOMOYO Linux coexist with them is better than
poorly utilizing LSM hooks and making TOMOYO Linux irreconcilable.
In fact, I'm building TOMOYO Linux kernel packages with SELinux enabled
and I'm experiencing no problems.

Reason 2:

TOMOYO Linux supports "delayed enforcing" mode that allows administrator
judge interactively when policy violation occurred.
To support that mode, all hooks but ccs_may_autobind() are called from
context that is permitted to sleep.
But some of LSM hooks are called from context that is not permitted to sleep.

Reason 3:

LSM hooks are called from VFS helper functions.
But VFS helper functions don't receive "struct vfsmount" that are needed for
TOMOYO Linux.
Current specification of LSM is suitable for label based access control,
but is not suitable for pathname based access control.
As far as I can see, adding "struct vfsmount" to VFS helper functions
to make LSM suitable for pathname based access control is unlikely acceptable.
TOMOYO Linux can achieve its functionality using
mnt_want_write()/mnt_drop_write()-like hooks.

Reason 4:

TOMOYO Linux is not only a tool for doing access control
but also a tool for analyzing a system's behavior.


Currently, this patch encloses inserted lines in
"/***** ... start. *****/" and "/***** end. *****/" comments so that
reviewers can easily find the range of modifications.
Of course, these comments will go away when ready to merge.

This patch makes two lines deletion by
  sed -e 's:search_binary_handler:search_binary_handler_with_transition:'
TOMOYO does domain transition when execve() is called.
Thus, distinguishing search_binary_handler() from do_execve() and
search_binary_handler() from other functions (e.g. load_script())
makes TOMOYO's domain transition handler simple.

Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
Cc: linux-netdev <netdev@vger.kernel.org>
---
 Documentation/kernel-parameters.txt |   15 ++++
 arch/ia64/ia32/sys_ia32.c           |    7 ++
 arch/mips/kernel/ptrace32.c         |    7 ++
 arch/s390/kernel/ptrace.c           |    7 ++
 arch/sh/kernel/ptrace_64.c          |    7 ++
 arch/x86/kernel/ptrace.c            |    7 ++
 fs/Kconfig                          |    2 
 fs/Makefile                         |    2 
 fs/attr.c                           |   19 +++++
 fs/compat.c                         |    2 
 fs/compat_ioctl.c                   |    9 ++
 fs/exec.c                           |   20 +++++-
 fs/fcntl.c                          |    9 ++
 fs/ioctl.c                          |    7 ++
 fs/namei.c                          |  118 ++++++++++++++++++++++++++++++++++++
 fs/namespace.c                      |   49 ++++++++++++++
 fs/open.c                           |   27 ++++++++
 fs/proc/Makefile                    |    3 
 fs/proc/proc_misc.c                 |    5 +
 include/linux/init_task.h           |    4 +
 include/linux/sched.h               |    9 ++
 kernel/compat.c                     |    7 ++
 kernel/kexec.c                      |    7 ++
 kernel/kmod.c                       |    5 +
 kernel/module.c                     |   11 +++
 kernel/ptrace.c                     |   11 +++
 kernel/sched.c                      |    7 ++
 kernel/signal.c                     |   21 ++++++
 kernel/sys.c                        |   21 ++++++
 kernel/sysctl.c                     |   94 ++++++++++++++++++++++++++++
 kernel/time.c                       |   11 +++
 kernel/time/ntp.c                   |    7 ++
 net/core/datagram.c                 |   11 +++
 net/ipv4/inet_connection_sock.c     |    7 ++
 net/ipv4/inet_hashtables.c          |    7 ++
 net/ipv4/udp.c                      |   10 +++
 net/socket.c                        |   41 ++++++++++++
 net/unix/af_unix.c                  |   15 ++++
 38 files changed, 626 insertions(+), 2 deletions(-)

--- linux-2.6.25-rc8-mm1.orig/arch/ia64/ia32/sys_ia32.c
+++ linux-2.6.25-rc8-mm1/arch/ia64/ia32/sys_ia32.c
@@ -51,6 +51,9 @@
 #include <asm/types.h>
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 #include "ia32priv.h"
 
@@ -1754,6 +1757,10 @@ sys32_ptrace (int request, pid_t pid, un
 	struct task_struct *child;
 	unsigned int value, tmp;
 	long i, ret;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_PTRACE))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	lock_kernel();
 	if (request == PTRACE_TRACEME) {
--- linux-2.6.25-rc8-mm1.orig/arch/mips/kernel/ptrace32.c
+++ linux-2.6.25-rc8-mm1/arch/mips/kernel/ptrace32.c
@@ -35,6 +35,9 @@
 #include <asm/system.h>
 #include <asm/uaccess.h>
 #include <asm/bootinfo.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 int ptrace_getregs(struct task_struct *child, __s64 __user *data);
 int ptrace_setregs(struct task_struct *child, __s64 __user *data);
@@ -50,6 +53,10 @@ asmlinkage int sys32_ptrace(int request,
 {
 	struct task_struct *child;
 	int ret;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_PTRACE))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 #if 0
 	printk("ptrace(r=%d,pid=%d,addr=%08lx,data=%08lx)\n",
--- linux-2.6.25-rc8-mm1.orig/arch/s390/kernel/ptrace.c
+++ linux-2.6.25-rc8-mm1/arch/s390/kernel/ptrace.c
@@ -41,6 +41,9 @@
 #include <asm/system.h>
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 #ifdef CONFIG_COMPAT
 #include "compat_ptrace.h"
@@ -698,6 +701,10 @@ sys_ptrace(long request, long pid, long 
 	struct task_struct *child;
 	int ret;
 
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_PTRACE))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 	lock_kernel();
 	if (request == PTRACE_TRACEME) {
 		 ret = ptrace_traceme();
--- linux-2.6.25-rc8-mm1.orig/arch/sh/kernel/ptrace_64.c
+++ linux-2.6.25-rc8-mm1/arch/sh/kernel/ptrace_64.c
@@ -33,6 +33,9 @@
 #include <asm/system.h>
 #include <asm/processor.h>
 #include <asm/mmu_context.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 /* This mask defines the bits of the SR which the user is not allowed to
    change, which are everything except S, Q, M, PR, SZ, FR. */
@@ -253,6 +256,10 @@ asmlinkage int sh64_ptrace(long request,
 {
 #define WPC_DBRMODE 0x0d104008
 	static int first_call = 1;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_PTRACE))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	lock_kernel();
 	if (first_call) {
--- linux-2.6.25-rc8-mm1.orig/arch/x86/kernel/ptrace.c
+++ linux-2.6.25-rc8-mm1/arch/x86/kernel/ptrace.c
@@ -32,6 +32,9 @@
 #include <asm/prctl.h>
 #include <asm/proto.h>
 #include <asm/ds.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 #include "tls.h"
 
@@ -1240,6 +1243,10 @@ asmlinkage long sys32_ptrace(long reques
 	void __user *datap = compat_ptr(data);
 	int ret;
 	__u32 val;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_PTRACE))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	switch (request) {
 	case PTRACE_TRACEME:
--- linux-2.6.25-rc8-mm1.orig/fs/Kconfig
+++ linux-2.6.25-rc8-mm1/fs/Kconfig
@@ -2196,4 +2196,6 @@ endif
 source "fs/nls/Kconfig"
 source "fs/dlm/Kconfig"
 
+source "fs/Kconfig.ccs"
+
 endmenu
--- linux-2.6.25-rc8-mm1.orig/fs/Makefile
+++ linux-2.6.25-rc8-mm1/fs/Makefile
@@ -121,3 +121,5 @@ obj-$(CONFIG_DEBUG_FS)		+= debugfs/
 obj-$(CONFIG_OCFS2_FS)		+= ocfs2/
 obj-$(CONFIG_GFS2_FS)           += gfs2/
 obj-$(CONFIG_UNION_FS)		+= unionfs/
+
+include $(srctree)/fs/Makefile-2.6.ccs
--- linux-2.6.25-rc8-mm1.orig/fs/attr.c
+++ linux-2.6.25-rc8-mm1/fs/attr.c
@@ -14,6 +14,9 @@
 #include <linux/fcntl.h>
 #include <linux/quotaops.h>
 #include <linux/security.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 /* Taken over from the old code... */
 
@@ -159,12 +162,28 @@ int notify_change(struct dentry * dentry
 
 	if (inode->i_op && inode->i_op->setattr) {
 		error = security_inode_setattr(dentry, attr);
+		/***** TOMOYO Linux start. *****/
+		if (!error && (ia_valid & ATTR_MODE) &&
+		    !ccs_capable(TOMOYO_SYS_CHMOD))
+			error = -EPERM;
+		if (!error && (ia_valid & (ATTR_UID | ATTR_GID)) &&
+		    !ccs_capable(TOMOYO_SYS_CHOWN))
+			error = -EPERM;
+		/***** TOMOYO Linux end. *****/
 		if (!error)
 			error = inode->i_op->setattr(dentry, attr);
 	} else {
 		error = inode_change_ok(inode, attr);
 		if (!error)
 			error = security_inode_setattr(dentry, attr);
+		/***** TOMOYO Linux start. *****/
+		if (!error && (ia_valid & ATTR_MODE) &&
+		    !ccs_capable(TOMOYO_SYS_CHMOD))
+			error = -EPERM;
+		if (!error && (ia_valid & (ATTR_UID | ATTR_GID)) &&
+		    !ccs_capable(TOMOYO_SYS_CHOWN))
+			error = -EPERM;
+		/***** TOMOYO Linux end. *****/
 		if (!error) {
 			if ((ia_valid & ATTR_UID && attr->ia_uid != inode->i_uid) ||
 			    (ia_valid & ATTR_GID && attr->ia_gid != inode->i_gid))
--- linux-2.6.25-rc8-mm1.orig/fs/compat.c
+++ linux-2.6.25-rc8-mm1/fs/compat.c
@@ -1399,7 +1399,7 @@ int compat_do_execve(char * filename,
 	if (retval < 0)
 		goto out;
 
-	retval = search_binary_handler(bprm, regs);
+	retval = search_binary_handler_with_transition(bprm, regs);
 	if (retval >= 0) {
 		/* execve success */
 		security_bprm_free(bprm);
--- linux-2.6.25-rc8-mm1.orig/fs/compat_ioctl.c
+++ linux-2.6.25-rc8-mm1/fs/compat_ioctl.c
@@ -113,6 +113,9 @@
 #ifdef CONFIG_SPARC
 #include <asm/fbio.h>
 #endif
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 static int do_ioctl32_pointer(unsigned int fd, unsigned int cmd,
 			      unsigned long arg, struct file *f)
@@ -2910,6 +2913,12 @@ asmlinkage long compat_sys_ioctl(unsigne
 		/*FALL THROUGH*/
 
 	default:
+		/***** TOMOYO Linux start. *****/
+		if (!ccs_capable(TOMOYO_SYS_IOCTL)) {
+			error = -EPERM;
+			goto out_fput;
+		}
+		/***** TOMOYO Linux end. *****/
 		if (filp->f_op && filp->f_op->compat_ioctl) {
 			error = filp->f_op->compat_ioctl(filp, cmd, arg);
 			if (error != -ENOIOCTLCMD)
--- linux-2.6.25-rc8-mm1.orig/fs/exec.c
+++ linux-2.6.25-rc8-mm1/fs/exec.c
@@ -60,6 +60,10 @@
 #include <linux/kmod.h>
 #endif
 
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
+
 int core_uses_pid;
 char core_pattern[CORENAME_MAX_SIZE] = "core";
 int suid_dumpable = 0;
@@ -118,6 +122,12 @@ asmlinkage long sys_uselib(const char __
 	error = vfs_permission(&nd, MAY_READ | MAY_EXEC);
 	if (error)
 		goto exit;
+	/***** TOMOYO Linux start. *****/
+	/* 01 means "read". */
+	error = ccs_check_open_permission(nd.path.dentry, nd.path.mnt, 01);
+	if (error)
+		goto exit;
+	/***** TOMOYO Linux end. *****/
 
 	file = nameidata_to_filp(&nd, O_RDONLY|O_LARGEFILE);
 	error = PTR_ERR(file);
@@ -664,6 +674,14 @@ struct file *open_exec(const char *name)
 		file = ERR_PTR(-EACCES);
 		if (S_ISREG(inode->i_mode)) {
 			int err = vfs_permission(&nd, MAY_EXEC);
+			/***** TOMOYO Linux start. *****/
+			if (!err && (current->tomoyo_flags &
+				     TOMOYO_CHECK_READ_FOR_OPEN_EXEC))
+				/* 01 means "read". */
+				err = ccs_check_open_permission(nd.path.dentry,
+								nd.path.mnt,
+								01);
+			/***** TOMOYO Linux end. *****/
 			file = ERR_PTR(err);
 			if (!err) {
 				file = nameidata_to_filp(&nd,
@@ -1325,7 +1343,7 @@ int do_execve(char * filename,
 	if (retval < 0)
 		goto out;
 
-	retval = search_binary_handler(bprm,regs);
+	retval = search_binary_handler_with_transition(bprm, regs);
 	if (retval >= 0) {
 		/* execve success */
 		free_arg_pages(bprm);
--- linux-2.6.25-rc8-mm1.orig/fs/fcntl.c
+++ linux-2.6.25-rc8-mm1/fs/fcntl.c
@@ -23,6 +23,9 @@
 #include <asm/poll.h>
 #include <asm/siginfo.h>
 #include <asm/uaccess.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 void set_close_on_exec(unsigned int fd, int flag)
 {
@@ -217,6 +220,12 @@ static int setfl(int fd, struct file * f
 	if (((arg ^ filp->f_flags) & O_APPEND) && IS_APPEND(inode))
 		return -EPERM;
 
+	/***** TOMOYO Linux start. *****/
+	if (((arg ^ filp->f_flags) & O_APPEND) &&
+	    ccs_check_rewrite_permission(filp))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
+
 	/* O_NOATIME can only be set by the owner or superuser */
 	if ((arg & O_NOATIME) && !(filp->f_flags & O_NOATIME))
 		if (!is_owner_or_cap(inode))
--- linux-2.6.25-rc8-mm1.orig/fs/ioctl.c
+++ linux-2.6.25-rc8-mm1/fs/ioctl.c
@@ -15,6 +15,9 @@
 #include <linux/uaccess.h>
 
 #include <asm/ioctls.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 /**
  * vfs_ioctl - call filesystem specific ioctl methods
@@ -35,6 +38,10 @@ static long vfs_ioctl(struct file *filp,
 
 	if (!filp->f_op)
 		goto out;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_IOCTL))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	if (filp->f_op->unlocked_ioctl) {
 		error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
--- linux-2.6.25-rc8-mm1.orig/fs/namei.c
+++ linux-2.6.25-rc8-mm1/fs/namei.c
@@ -36,6 +36,10 @@
 
 #define ACC_MODE(x) ("\000\004\002\006"[(x)&O_ACCMODE])
 
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
+
 /* [Feb-1997 T. Schoebel-Theuer]
  * Fundamental changes in the pathname lookup mechanisms (namei)
  * were necessary because of omirr.  The reason is that omirr needs
@@ -1595,6 +1599,14 @@ int vfs_create(struct inode *dir, struct
 	error = security_inode_create(dir, dentry, mode);
 	if (error)
 		return error;
+	/***** TOMOYO Linux start. *****/
+	if (nd) {
+		error = ccs_check_1path_perm(TYPE_CREATE_ACL, dentry,
+					     nd->path.mnt);
+		if (error < 0)
+			return error;
+	}
+	/***** TOMOYO Linux end. *****/
 	DQUOT_INIT(dir);
 	error = dir->i_op->create(dir, dentry, mode, nd);
 	if (!error)
@@ -1649,6 +1661,13 @@ int may_open(struct nameidata *nd, int a
 		if (!is_owner_or_cap(inode))
 			return -EPERM;
 
+	/***** TOMOYO Linux start. *****/
+	/* includes O_APPEND and O_TRUNC checks */
+	error = ccs_check_open_permission(dentry, nd->path.mnt, flag);
+	if (error)
+		return error;
+	/***** TOMOYO Linux end. *****/
+
 	/*
 	 * Ensure there are no outstanding leases on the file.
 	 */
@@ -1705,6 +1724,9 @@ static int __open_namei_create(struct na
 	return may_open(nd, 0, flag & ~O_TRUNC);
 }
 
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo_vfs.h>
+/***** TOMOYO Linux end. *****/
 /*
  * Note that while the flag value (low two bits) for sys_open means:
  *	00 - read-only
@@ -2076,6 +2098,16 @@ asmlinkage long sys_mknodat(int dfd, con
 
 	if (S_ISDIR(mode))
 		return -EPERM;
+	/***** TOMOYO Linux start. *****/
+	if (S_ISCHR(mode) && !ccs_capable(TOMOYO_CREATE_CHAR_DEV))
+		return -EPERM;
+	if (S_ISBLK(mode) && !ccs_capable(TOMOYO_CREATE_BLOCK_DEV))
+		return -EPERM;
+	if (S_ISFIFO(mode) && !ccs_capable(TOMOYO_CREATE_FIFO))
+		return -EPERM;
+	if (S_ISSOCK(mode) && !ccs_capable(TOMOYO_CREATE_UNIX_SOCKET))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 	tmp = getname(filename);
 	if (IS_ERR(tmp))
 		return PTR_ERR(tmp);
@@ -2101,10 +2133,34 @@ asmlinkage long sys_mknodat(int dfd, con
 			error = vfs_create(nd.path.dentry->d_inode,dentry,mode,&nd);
 			break;
 		case S_IFCHR: case S_IFBLK:
+			/***** TOMOYO Linux start. *****/
+			error = pre_vfs_mknod(nd.path.dentry->d_inode, dentry,
+					      mode);
+			if (error)
+				break;
+			error = ccs_check_1path_perm(S_ISCHR(mode) ?
+						     TYPE_MKCHAR_ACL :
+						     TYPE_MKBLOCK_ACL,
+						     dentry, nd.path.mnt);
+			if (error)
+				break;
+			/***** TOMOYO Linux end. *****/
 			error = vfs_mknod(nd.path.dentry->d_inode,dentry,mode,
 					new_decode_dev(dev));
 			break;
 		case S_IFIFO: case S_IFSOCK:
+			/***** TOMOYO Linux start. *****/
+			error = pre_vfs_mknod(nd.path.dentry->d_inode, dentry,
+					      mode);
+			if (error)
+				break;
+			error = ccs_check_1path_perm(S_ISFIFO(mode) ?
+						     TYPE_MKFIFO_ACL :
+						     TYPE_MKSOCK_ACL,
+						     dentry, nd.path.mnt);
+			if (error)
+				break;
+			/***** TOMOYO Linux end. *****/
 			error = vfs_mknod(nd.path.dentry->d_inode,dentry,mode,0);
 			break;
 	}
@@ -2172,6 +2228,13 @@ asmlinkage long sys_mkdirat(int dfd, con
 	error = mnt_want_write(nd.path.mnt);
 	if (error)
 		goto out_dput;
+	/***** TOMOYO Linux start. *****/
+	error = pre_vfs_mkdir(nd.path.dentry->d_inode, dentry);
+	if (!error)
+		error = ccs_check_1path_perm(TYPE_MKDIR_ACL, dentry,
+					     nd.path.mnt);
+	if (!error)
+	/***** TOMOYO Linux end. *****/
 	error = vfs_mkdir(nd.path.dentry->d_inode, dentry, mode);
 	mnt_drop_write(nd.path.mnt);
 out_dput:
@@ -2284,6 +2347,13 @@ static long do_rmdir(int dfd, const char
 	error = mnt_want_write(nd.path.mnt);
 	if (error)
 		goto exit3;
+	/***** TOMOYO Linux start. *****/
+	error = pre_vfs_rmdir(nd.path.dentry->d_inode, dentry);
+	if (!error)
+		error = ccs_check_1path_perm(TYPE_RMDIR_ACL, dentry,
+					     nd.path.mnt);
+	if (!error)
+	/***** TOMOYO Linux end. *****/
 	error = vfs_rmdir(nd.path.dentry->d_inode, dentry);
 	mnt_drop_write(nd.path.mnt);
 exit3:
@@ -2346,6 +2416,10 @@ static long do_unlinkat(int dfd, const c
 	struct dentry *dentry;
 	struct nameidata nd;
 	struct inode *inode = NULL;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_UNLINK))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	name = getname(pathname);
 	if(IS_ERR(name))
@@ -2370,6 +2444,13 @@ static long do_unlinkat(int dfd, const c
 		error = mnt_want_write(nd.path.mnt);
 		if (error)
 			goto exit2;
+		/***** TOMOYO Linux start. *****/
+		error = pre_vfs_unlink(nd.path.dentry->d_inode, dentry);
+		if (!error)
+			error = ccs_check_1path_perm(TYPE_UNLINK_ACL, dentry,
+						     nd.path.mnt);
+		if (!error)
+		/***** TOMOYO Linux end. *****/
 		error = vfs_unlink(nd.path.dentry->d_inode, dentry);
 		mnt_drop_write(nd.path.mnt);
 	exit2:
@@ -2435,6 +2516,10 @@ asmlinkage long sys_symlinkat(const char
 	char * to;
 	struct dentry *dentry;
 	struct nameidata nd;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_SYMLINK))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	from = getname(oldname);
 	if(IS_ERR(from))
@@ -2455,6 +2540,13 @@ asmlinkage long sys_symlinkat(const char
 	error = mnt_want_write(nd.path.mnt);
 	if (error)
 		goto out_dput;
+	/***** TOMOYO Linux start. *****/
+	error = pre_vfs_symlink(nd.path.dentry->d_inode, dentry);
+	if (!error)
+		error = ccs_check_1path_perm(TYPE_SYMLINK_ACL, dentry,
+					     nd.path.mnt);
+	if (!error)
+	/***** TOMOYO Linux end. *****/
 	error = vfs_symlink(nd.path.dentry->d_inode, dentry, from, S_IALLUGO);
 	mnt_drop_write(nd.path.mnt);
 out_dput:
@@ -2529,6 +2621,10 @@ asmlinkage long sys_linkat(int olddfd, c
 	struct nameidata nd, old_nd;
 	int error;
 	char * to;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_LINK))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	if ((flags & ~AT_SYMLINK_FOLLOW) != 0)
 		return -EINVAL;
@@ -2555,6 +2651,15 @@ asmlinkage long sys_linkat(int olddfd, c
 	error = mnt_want_write(nd.path.mnt);
 	if (error)
 		goto out_dput;
+	/***** TOMOYO Linux start. *****/
+	error = pre_vfs_link(old_nd.path.dentry, nd.path.dentry->d_inode,
+			     new_dentry);
+	if (!error)
+		error = ccs_check_2path_perm(TYPE_LINK_ACL, old_nd.path.dentry,
+					     old_nd.path.mnt, new_dentry,
+					     nd.path.mnt);
+	if (!error)
+	/***** TOMOYO Linux end. *****/
 	error = vfs_link(old_nd.path.dentry, nd.path.dentry->d_inode, new_dentry);
 	mnt_drop_write(nd.path.mnt);
 out_dput:
@@ -2786,6 +2891,15 @@ static int do_rename(int olddfd, const c
 	error = mnt_want_write(oldnd.path.mnt);
 	if (error)
 		goto exit5;
+	/***** TOMOYO Linux start. *****/
+	error = pre_vfs_rename(old_dir->d_inode, old_dentry, new_dir->d_inode,
+			       new_dentry);
+	if (!error)
+		error = ccs_check_2path_perm(TYPE_RENAME_ACL, old_dentry,
+					     oldnd.path.mnt, new_dentry,
+					     newnd.path.mnt);
+	if (!error)
+	/***** TOMOYO Linux end. *****/
 	error = vfs_rename(old_dir->d_inode, old_dentry,
 				   new_dir->d_inode, new_dentry);
 	mnt_drop_write(oldnd.path.mnt);
@@ -2809,6 +2923,10 @@ asmlinkage long sys_renameat(int olddfd,
 	int error;
 	char * from;
 	char * to;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_RENAME))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	from = getname(oldname);
 	if(IS_ERR(from))
--- linux-2.6.25-rc8-mm1.orig/fs/namespace.c
+++ linux-2.6.25-rc8-mm1/fs/namespace.c
@@ -31,6 +31,12 @@
 #include <asm/unistd.h>
 #include "pnode.h"
 #include "internal.h"
+/***** SAKURA Linux start. *****/
+#include <linux/sakura.h>
+/***** SAKURA Linux end. *****/
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 #define HASH_SHIFT ilog2(PAGE_SIZE / sizeof(struct list_head))
 #define HASH_SIZE (1UL << HASH_SHIFT)
@@ -1029,6 +1035,11 @@ static int do_umount(struct vfsmount *mn
 	if (retval)
 		return retval;
 
+	/***** SAKURA Linux start. *****/
+	if (ccs_may_umount(mnt) < 0)
+		return -EPERM;
+	/***** SAKURA Linux end. *****/
+
 	/*
 	 * Allow userspace to request a mountpoint be expired rather than
 	 * unmounting unconditionally. Unmount only happens if:
@@ -1119,6 +1130,10 @@ asmlinkage long sys_umount(char __user *
 {
 	struct nameidata nd;
 	int retval;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_UMOUNT))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	retval = __user_walk(name, LOOKUP_FOLLOW, &nd);
 	if (retval)
@@ -1466,6 +1481,11 @@ static noinline int do_loopback(struct n
 	err = -EINVAL;
 	if (IS_MNT_UNBINDABLE(old_nd.path.mnt))
 		goto out;
+	/***** SAKURA Linux start. *****/
+	err = -EPERM;
+	if (ccs_may_mount(nd) < 0)
+		goto out;
+	/***** SAKURA Linux end. *****/
 
 	if (!check_mnt(nd->path.mnt) || !check_mnt(old_nd.path.mnt))
 		goto out;
@@ -1580,6 +1600,11 @@ static noinline int do_move_mount(struct
 	if (!check_mnt(nd->path.mnt) || !check_mnt(old_nd.path.mnt))
 		goto out;
 
+	/***** SAKURA Linux start. *****/
+	err = -EPERM;
+	if (ccs_may_umount(old_nd.path.mnt) < 0 || ccs_may_mount(nd) < 0)
+		goto out;
+	/***** SAKURA Linux end. *****/
 	err = -ENOENT;
 	mutex_lock(&nd->path.dentry->d_inode->i_mutex);
 	if (IS_DEADDIR(nd->path.dentry->d_inode))
@@ -1684,6 +1709,11 @@ int do_add_mount(struct vfsmount *newmnt
 	err = -EINVAL;
 	if (S_ISLNK(newmnt->mnt_root->d_inode->i_mode))
 		goto unlock;
+	/***** SAKURA Linux start. *****/
+	err = -EPERM;
+	if (ccs_may_mount(nd) < 0)
+		goto unlock;
+	/***** SAKURA Linux end. *****/
 
 	newmnt->mnt_flags = mnt_flags;
 	if ((err = graft_tree(newmnt, &nd->path)))
@@ -1907,6 +1937,17 @@ long do_mount(char *dev_name, char *dir_
 	if (data_page)
 		((char *)data_page)[PAGE_SIZE - 1] = 0;
 
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_MOUNT))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
+	/***** SAKURA Linux start. *****/
+	retval = ccs_check_mount_permission(dev_name, dir_name, type_page,
+					    &flags);
+	if (retval < 0)
+		return retval;
+	/***** SAKURA Linux end. *****/
+
 	/* Separate the per-mountpoint flags */
 	if (flags & MS_NOSUID)
 		mnt_flags |= MNT_NOSUID;
@@ -2178,6 +2219,10 @@ asmlinkage long sys_pivot_root(const cha
 
 	if (!capable(CAP_SYS_ADMIN))
 		return -EPERM;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_PIVOT_ROOT))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	error = __user_walk(new_root, LOOKUP_FOLLOW | LOOKUP_DIRECTORY,
 			    &new_nd);
@@ -2192,6 +2237,10 @@ asmlinkage long sys_pivot_root(const cha
 		goto out1;
 
 	error = security_sb_pivotroot(&old_nd.path, &new_nd.path);
+	/***** SAKURA Linux start. *****/
+	if (!error)
+		error = ccs_check_pivot_root_permission(&old_nd, &new_nd);
+	/***** SAKURA Linux end. *****/
 	if (error) {
 		path_put(&old_nd.path);
 		goto out1;
--- linux-2.6.25-rc8-mm1.orig/fs/open.c
+++ linux-2.6.25-rc8-mm1/fs/open.c
@@ -27,6 +27,12 @@
 #include <linux/rcupdate.h>
 #include <linux/audit.h>
 #include <linux/falloc.h>
+/***** SAKURA Linux start. *****/
+#include <linux/sakura.h>
+/***** SAKURA Linux end. *****/
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 int vfs_statfs(struct dentry *dentry, struct kstatfs *buf)
 {
@@ -268,6 +274,11 @@ static long do_sys_truncate(const char _
 	if (error)
 		goto put_write_and_out;
 
+	/***** TOMOYO Linux start. *****/
+	error = ccs_check_1path_perm(TYPE_TRUNCATE_ACL, nd.path.dentry,
+				     nd.path.mnt);
+	if (!error)
+	/***** TOMOYO Linux end. *****/
 	error = locks_verify_truncate(inode, NULL, length);
 	if (!error) {
 		DQUOT_INIT(inode);
@@ -324,6 +335,10 @@ static long do_sys_ftruncate(unsigned in
 	if (IS_APPEND(inode))
 		goto out_putf;
 
+	/***** TOMOYO Linux start. *****/
+	error = ccs_check_1path_perm(TYPE_TRUNCATE_ACL, dentry, file->f_vfsmnt);
+	if (!error)
+	/***** TOMOYO Linux end. *****/
 	error = locks_verify_truncate(inode, file, length);
 	if (!error)
 		error = do_truncate(dentry, length, ATTR_MTIME|ATTR_CTIME, file);
@@ -551,6 +566,14 @@ asmlinkage long sys_chroot(const char __
 	error = -EPERM;
 	if (!capable(CAP_SYS_CHROOT))
 		goto dput_and_out;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_CHROOT))
+		goto dput_and_out;
+	/***** TOMOYO Linux end. *****/
+	/***** SAKURA Linux start. *****/
+	if (ccs_check_chroot_permission(&nd))
+		goto dput_and_out;
+	/***** SAKURA Linux end. *****/
 
 	set_fs_root(current->fs, &nd.path);
 	set_fs_altroot();
@@ -1206,6 +1229,10 @@ EXPORT_SYMBOL(sys_close);
  */
 asmlinkage long sys_vhangup(void)
 {
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_VHANGUP))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 	if (capable(CAP_SYS_TTY_CONFIG)) {
 		/* XXX: this needs locking */
 		tty_vhangup(current->signal->tty);
--- linux-2.6.25-rc8-mm1.orig/fs/proc/Makefile
+++ linux-2.6.25-rc8-mm1/fs/proc/Makefile
@@ -16,3 +16,6 @@ proc-$(CONFIG_PROC_KCORE)	+= kcore.o
 proc-$(CONFIG_PROC_VMCORE)	+= vmcore.o
 proc-$(CONFIG_PROC_DEVICETREE)	+= proc_devtree.o
 proc-$(CONFIG_PRINTK)	+= kmsg.o
+
+proc-$(CONFIG_SAKURA) += ccs_proc.o
+proc-$(CONFIG_TOMOYO) += ccs_proc.o
--- linux-2.6.25-rc8-mm1.orig/fs/proc/proc_misc.c
+++ linux-2.6.25-rc8-mm1/fs/proc/proc_misc.c
@@ -1049,4 +1049,9 @@ void __init proc_misc_init(void)
 		}
 	}
 #endif
+	/***** CCS start. *****/
+#if defined(CONFIG_SAKURA) || defined(CONFIG_TOMOYO)
+	printk(KERN_INFO "Hook version: 2.6.25-rc8-mm1 2008/04/02\n");
+#endif
+	/***** CCS end. *****/
 }
--- linux-2.6.25-rc8-mm1.orig/include/linux/init_task.h
+++ linux-2.6.25-rc8-mm1/include/linux/init_task.h
@@ -197,6 +197,10 @@ extern struct group_info init_groups;
 	INIT_IDS							\
 	INIT_TRACE_IRQFLAGS						\
 	INIT_LOCKDEP							\
+	/***** TOMOYO Linux start. *****/        \
+	.domain_info = &KERNEL_DOMAIN,           \
+	.tomoyo_flags = 0,                       \
+	/***** TOMOYO Linux end. *****/          \
 }
 
 
--- linux-2.6.25-rc8-mm1.orig/include/linux/sched.h
+++ linux-2.6.25-rc8-mm1/include/linux/sched.h
@@ -29,6 +29,11 @@
 #define CLONE_NEWNET		0x40000000	/* New network namespace */
 #define CLONE_IO		0x80000000	/* Clone io context */
 
+/***** TOMOYO Linux start. *****/
+struct domain_info;
+extern struct domain_info KERNEL_DOMAIN;
+/***** TOMOYO Linux end. *****/
+
 /*
  * Scheduling policies
  */
@@ -1278,6 +1283,10 @@ struct task_struct {
 	int latency_record_count;
 	struct latency_record latency_record[LT_SAVECOUNT];
 #endif
+	/***** TOMOYO Linux start. *****/
+	struct domain_info *domain_info;
+	u32 tomoyo_flags;
+	/***** TOMOYO Linux end. *****/
 };
 
 /*
--- linux-2.6.25-rc8-mm1.orig/kernel/compat.c
+++ linux-2.6.25-rc8-mm1/kernel/compat.c
@@ -25,6 +25,9 @@
 #include <linux/posix-timers.h>
 
 #include <asm/uaccess.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 int get_compat_timespec(struct timespec *ts, const struct compat_timespec __user *cts)
 {
@@ -868,6 +871,10 @@ asmlinkage long compat_sys_stime(compat_
 	err = security_settime(&tv, NULL);
 	if (err)
 		return err;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_SETTIME))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	do_settimeofday(&tv);
 	return 0;
--- linux-2.6.25-rc8-mm1.orig/kernel/kexec.c
+++ linux-2.6.25-rc8-mm1/kernel/kexec.c
@@ -31,6 +31,9 @@
 #include <asm/system.h>
 #include <asm/semaphore.h>
 #include <asm/sections.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 /* Per cpu memory for storing cpu states in case of system crash. */
 note_buf_t* crash_notes;
@@ -933,6 +936,10 @@ asmlinkage long sys_kexec_load(unsigned 
 	/* We only trust the superuser with rebooting the system. */
 	if (!capable(CAP_SYS_BOOT))
 		return -EPERM;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_KEXEC_LOAD))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	/*
 	 * Verify we have a legal set of flags
--- linux-2.6.25-rc8-mm1.orig/kernel/kmod.c
+++ linux-2.6.25-rc8-mm1/kernel/kmod.c
@@ -173,6 +173,11 @@ static int ____call_usermodehelper(void 
 	 */
 	set_user_nice(current, 0);
 
+	/***** TOMOYO Linux start. *****/
+	current->domain_info = &KERNEL_DOMAIN;
+	current->tomoyo_flags = 0;
+	/***** TOMOYO Linux end. *****/
+
 	retval = kernel_execve(sub_info->path, sub_info->argv, sub_info->envp);
 
 	/* Exec failed? */
--- linux-2.6.25-rc8-mm1.orig/kernel/module.c
+++ linux-2.6.25-rc8-mm1/kernel/module.c
@@ -47,6 +47,9 @@
 #include <asm/cacheflush.h>
 #include <linux/license.h>
 #include <asm/sections.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 #if 0
 #define DEBUGP printk
@@ -686,6 +689,10 @@ sys_delete_module(const char __user *nam
 
 	if (!capable(CAP_SYS_MODULE))
 		return -EPERM;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_USE_KERNEL_MODULE))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	if (strncpy_from_user(name, name_user, MODULE_NAME_LEN-1) < 0)
 		return -EFAULT;
@@ -2157,6 +2164,10 @@ sys_init_module(void __user *umod,
 	/* Must have permission */
 	if (!capable(CAP_SYS_MODULE))
 		return -EPERM;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_USE_KERNEL_MODULE))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	/* Only one module load at a time, please */
 	if (mutex_lock_interruptible(&module_mutex) != 0)
--- linux-2.6.25-rc8-mm1.orig/kernel/ptrace.c
+++ linux-2.6.25-rc8-mm1/kernel/ptrace.c
@@ -24,6 +24,9 @@
 
 #include <asm/pgtable.h>
 #include <asm/uaccess.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 /*
  * ptrace a task: make the debugger its new parent and
@@ -539,6 +542,10 @@ asmlinkage long sys_ptrace(long request,
 	/*
 	 * This lock_kernel fixes a subtle race with suid exec
 	 */
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_PTRACE))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 	lock_kernel();
 	if (request == PTRACE_TRACEME) {
 		ret = ptrace_traceme();
@@ -646,6 +653,10 @@ asmlinkage long compat_sys_ptrace(compat
 	/*
 	 * This lock_kernel fixes a subtle race with suid exec
 	 */
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_PTRACE))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 	lock_kernel();
 	if (request == PTRACE_TRACEME) {
 		ret = ptrace_traceme();
--- linux-2.6.25-rc8-mm1.orig/kernel/sched.c
+++ linux-2.6.25-rc8-mm1/kernel/sched.c
@@ -70,6 +70,9 @@
 
 #include <asm/tlb.h>
 #include <asm/irq_regs.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 /*
  * Scheduler clock - returns current time in nanosec units.
@@ -4509,6 +4512,10 @@ int can_nice(const struct task_struct *p
 asmlinkage long sys_nice(int increment)
 {
 	long nice, retval;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_NICE))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	/*
 	 * Setpriority might change our priority at the same moment.
--- linux-2.6.25-rc8-mm1.orig/kernel/signal.c
+++ linux-2.6.25-rc8-mm1/kernel/signal.c
@@ -32,6 +32,9 @@
 #include <asm/unistd.h>
 #include <asm/siginfo.h>
 #include "audit.h"	/* audit_signal_info() */
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 /*
  * SLAB caches for signal bits.
@@ -2147,6 +2150,12 @@ asmlinkage long
 sys_kill(int pid, int sig)
 {
 	struct siginfo info;
+	/***** TOMOYO Linux start. *****/
+	if (sig && !ccs_capable(TOMOYO_SYS_KILL))
+		return -EPERM;
+	if (sig && ccs_check_signal_acl(sig, pid) < 0)
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	info.si_signo = sig;
 	info.si_errno = 0;
@@ -2208,6 +2217,12 @@ asmlinkage long sys_tgkill(int tgid, int
 	/* This is only valid for single tasks */
 	if (pid <= 0 || tgid <= 0)
 		return -EINVAL;
+	/***** TOMOYO Linux start. *****/
+	if (sig && !ccs_capable(TOMOYO_SYS_KILL))
+		return -EPERM;
+	if (sig && ccs_check_signal_acl(sig, pid) < 0)
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	return do_tkill(tgid, pid, sig);
 }
@@ -2221,6 +2236,12 @@ sys_tkill(int pid, int sig)
 	/* This is only valid for single tasks */
 	if (pid <= 0)
 		return -EINVAL;
+	/***** TOMOYO Linux start. *****/
+	if (sig && !ccs_capable(TOMOYO_SYS_KILL))
+		return -EPERM;
+	if (sig && ccs_check_signal_acl(sig, pid) < 0)
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	return do_tkill(0, pid, sig);
 }
--- linux-2.6.25-rc8-mm1.orig/kernel/sys.c
+++ linux-2.6.25-rc8-mm1/kernel/sys.c
@@ -42,6 +42,9 @@
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/unistd.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 #ifndef SET_UNALIGN_CTL
 # define SET_UNALIGN_CTL(a,b)	(-EINVAL)
@@ -140,6 +143,12 @@ asmlinkage long sys_setpriority(int whic
 
 	if (which > PRIO_USER || which < PRIO_PROCESS)
 		goto out;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_NICE)) {
+		error = -EPERM;
+		goto out;
+	}
+	/***** TOMOYO Linux end. *****/
 
 	/* normalize: avoid signed division (rounding problems) */
 	error = -ESRCH;
@@ -376,6 +385,10 @@ asmlinkage long sys_reboot(int magic1, i
 			magic2 != LINUX_REBOOT_MAGIC2B &&
 	                magic2 != LINUX_REBOOT_MAGIC2C))
 		return -EINVAL;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_REBOOT))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	/* Instead of trying to make the power_off code look like
 	 * halt when pm_power_off is not set do it the easy way.
@@ -1359,6 +1372,10 @@ asmlinkage long sys_sethostname(char __u
 		return -EPERM;
 	if (len < 0 || len > __NEW_UTS_LEN)
 		return -EINVAL;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_SETHOSTNAME))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 	down_write(&uts_sem);
 	errno = -EFAULT;
 	if (!copy_from_user(tmp, name, len)) {
@@ -1404,6 +1421,10 @@ asmlinkage long sys_setdomainname(char _
 		return -EPERM;
 	if (len < 0 || len > __NEW_UTS_LEN)
 		return -EINVAL;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_SETHOSTNAME))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	down_write(&uts_sem);
 	errno = -EFAULT;
--- linux-2.6.25-rc8-mm1.orig/kernel/sysctl.c
+++ linux-2.6.25-rc8-mm1/kernel/sysctl.c
@@ -49,6 +49,9 @@
 
 #include <asm/uaccess.h>
 #include <asm/processor.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 #ifdef CONFIG_X86
 #include <asm/nmi.h>
@@ -1503,6 +1506,92 @@ repeat:
 	return -ENOTDIR;
 }
 
+/***** TOMOYO Linux start. *****/
+static int try_parse_table(int __user *name, int nlen, void __user *oldval,
+			   void __user *newval, ctl_table *table)
+{
+	int n;
+	int error = -ENOMEM;
+	int op = 0;
+	char *buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
+	if (oldval)
+		op |= 004;
+	if (newval)
+		op |= 002;
+	if (!op) { /* Neither read nor write */
+		error = 0;
+		goto out;
+	}
+	if (!buffer)
+		goto out;
+	memset(buffer, 0, PAGE_SIZE);
+	snprintf(buffer, PAGE_SIZE - 1, "/proc/sys");
+ repeat:
+	if (!nlen) {
+		error = -ENOTDIR;
+		goto out;
+	}
+	if (get_user(n, name)) {
+		error = -EFAULT;
+		goto out;
+	}
+	for ( ; table->ctl_name || table->procname; table++) {
+		if (n == table->ctl_name && n) {
+			int pos = strlen(buffer);
+			const char *cp = table->procname;
+			error = -ENOMEM;
+			if (cp) {
+				if (pos + 1 >= PAGE_SIZE - 1)
+					goto out;
+				buffer[pos++] = '/';
+				while (*cp) {
+					const unsigned char c =
+						*(const unsigned char *) cp;
+					if (c == '\\') {
+						if (pos + 2 >= PAGE_SIZE - 1)
+							goto out;
+						buffer[pos++] = '\\';
+						buffer[pos++] = '\\';
+					} else if (c > ' ' && c < 127) {
+						if (pos + 1 >= PAGE_SIZE - 1)
+							goto out;
+						buffer[pos++] = c;
+					} else {
+						if (pos + 4 >= PAGE_SIZE - 1)
+							goto out;
+						buffer[pos++] = '\\';
+						buffer[pos++] = (c >> 6) + '0';
+						buffer[pos++] =
+							((c >> 3) & 7) + '0';
+						buffer[pos++] = (c & 7) + '0';
+					}
+					cp++;
+				}
+			} else {
+				/* Assume nobody assigns "=\$=" for procname. */
+				snprintf(buffer + pos, PAGE_SIZE - pos - 1,
+					 "/=%d=", n);
+				if (!memchr(buffer, '\0', PAGE_SIZE - 2))
+					goto out;
+			}
+			if (table->child) {
+				name++;
+				nlen--;
+				table = table->child;
+				goto repeat;
+			}
+			/* printk("sysctl='%s'\n", buffer); */
+			error = ccs_check_file_perm(buffer, op, "sysctl");
+			goto out;
+		}
+	}
+	error = -ENOTDIR;
+ out:
+	kfree(buffer);
+	return error;
+}
+/***** TOMOYO Linux end. *****/
+
 int do_sysctl(int __user *name, int nlen, void __user *oldval, size_t __user *oldlenp,
 	       void __user *newval, size_t newlen)
 {
@@ -1519,6 +1608,11 @@ int do_sysctl(int __user *name, int nlen
 
 	for (head = sysctl_head_next(NULL); head;
 			head = sysctl_head_next(head)) {
+		/***** TOMOYO Linux start. *****/
+		error = try_parse_table(name, nlen, oldval, newval,
+					head->ctl_table);
+		if (!error)
+		/***** TOMOYO Linux end. *****/
 		error = parse_table(name, nlen, oldval, oldlenp, 
 					newval, newlen,
 					head->root, head->ctl_table);
--- linux-2.6.25-rc8-mm1.orig/kernel/time.c
+++ linux-2.6.25-rc8-mm1/kernel/time.c
@@ -41,6 +41,9 @@
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
 #include <asm/div64.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 #include "timeconst.h"
 
@@ -91,6 +94,10 @@ asmlinkage long sys_stime(time_t __user 
 	err = security_settime(&tv, NULL);
 	if (err)
 		return err;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_SETTIME))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	do_settimeofday(&tv);
 	return 0;
@@ -162,6 +169,10 @@ int do_sys_settimeofday(struct timespec 
 	error = security_settime(tv, tz);
 	if (error)
 		return error;
+	/***** TOMOYO Linux start. *****/
+	if (!ccs_capable(TOMOYO_SYS_SETTIME))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	if (tz) {
 		/* SMP safe, global irq locking makes it work. */
--- linux-2.6.25-rc8-mm1.orig/kernel/time/ntp.c
+++ linux-2.6.25-rc8-mm1/kernel/time/ntp.c
@@ -18,6 +18,9 @@
 #include <linux/math64.h>
 #include <linux/clocksource.h>
 #include <asm/timex.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 /*
  * Timekeeping variables
@@ -283,6 +286,10 @@ int do_adjtimex(struct timex *txc)
 	/* In order to modify anything, you gotta be super-user! */
 	if (txc->modes && !capable(CAP_SYS_TIME))
 		return -EPERM;
+	/***** TOMOYO Linux start. *****/
+	if (txc->modes && !ccs_capable(TOMOYO_SYS_SETTIME))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	/* Now we validate the data before disabling interrupts */
 
--- linux-2.6.25-rc8-mm1.orig/net/core/datagram.c
+++ linux-2.6.25-rc8-mm1/net/core/datagram.c
@@ -56,6 +56,11 @@
 #include <net/sock.h>
 #include <net/tcp_states.h>
 
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+#include <linux/tomoyo_socket.h>
+/***** TOMOYO Linux end. *****/
+
 /*
  *	Is a socket 'connection oriented' ?
  */
@@ -179,6 +184,12 @@ struct sk_buff *__skb_recv_datagram(stru
 		}
 		spin_unlock_irqrestore(&sk->sk_receive_queue.lock, cpu_flags);
 
+		/***** TOMOYO Linux start. *****/
+		error = ccs_socket_recv_datagram_permission(sk, skb, flags);
+		if (error < 0)
+			goto no_packet;
+		/***** TOMOYO Linux end. *****/
+
 		if (skb)
 			return skb;
 
--- linux-2.6.25-rc8-mm1.orig/net/ipv4/inet_connection_sock.c
+++ linux-2.6.25-rc8-mm1/net/ipv4/inet_connection_sock.c
@@ -23,6 +23,9 @@
 #include <net/route.h>
 #include <net/tcp_states.h>
 #include <net/xfrm.h>
+/***** SAKURA Linux start. *****/
+#include <linux/sakura.h>
+/***** SAKURA Linux end. *****/
 
 #ifdef INET_CSK_DEBUG
 const char inet_csk_timer_bug_msg[] = "inet_csk BUG: unknown timer value\n";
@@ -98,6 +101,10 @@ int inet_csk_get_port(struct sock *sk, u
 		do {
 			head = &hashinfo->bhash[inet_bhashfn(rover, hashinfo->bhash_size)];
 			spin_lock(&head->lock);
+			/***** SAKURA Linux start. *****/
+			if (ccs_may_autobind(rover) < 0)
+				goto next;
+			/***** SAKURA Linux end. *****/
 			inet_bind_bucket_for_each(tb, node, &head->chain)
 				if (tb->ib_net == net && tb->port == rover)
 					goto next;
--- linux-2.6.25-rc8-mm1.orig/net/ipv4/inet_hashtables.c
+++ linux-2.6.25-rc8-mm1/net/ipv4/inet_hashtables.c
@@ -22,6 +22,9 @@
 #include <net/inet_connection_sock.h>
 #include <net/inet_hashtables.h>
 #include <net/ip.h>
+/***** SAKURA Linux start. *****/
+#include <linux/sakura.h>
+/***** SAKURA Linux end. *****/
 
 /*
  * Allocate and initialize a new local port bind bucket.
@@ -421,6 +424,10 @@ int __inet_hash_connect(struct inet_time
 		local_bh_disable();
 		for (i = 1; i <= remaining; i++) {
 			port = low + (i + offset) % remaining;
+			/***** SAKURA Linux start. *****/
+			if (ccs_may_autobind(port) < 0)
+				continue;
+			/***** SAKURA Linux end. *****/
 			head = &hinfo->bhash[inet_bhashfn(port, hinfo->bhash_size)];
 			spin_lock(&head->lock);
 
--- linux-2.6.25-rc8-mm1.orig/net/ipv4/udp.c
+++ linux-2.6.25-rc8-mm1/net/ipv4/udp.c
@@ -105,6 +105,9 @@
 #include <net/checksum.h>
 #include <net/xfrm.h>
 #include "udp_impl.h"
+/***** SAKURA Linux start. *****/
+#include <linux/sakura.h>
+/***** SAKURA Linux end. *****/
 
 /*
  *	Snmp MIB for the UDP layer
@@ -175,6 +178,10 @@ int udp_lib_get_port(struct sock *sk, un
 		/* 1st pass: look for empty (or shortest) hash chain */
 		for (i = 0; i < UDP_HTABLE_SIZE; i++) {
 			int size = 0;
+			/***** SAKURA Linux start. *****/
+			if (ccs_may_autobind(rover) < 0)
+				goto next;
+			/***** SAKURA Linux end. *****/
 
 			head = &udptable[rover & (UDP_HTABLE_SIZE - 1)];
 			if (hlist_empty(head))
@@ -198,6 +205,9 @@ int udp_lib_get_port(struct sock *sk, un
 		/* 2nd pass: find hole in shortest hash chain */
 		rover = best;
 		for (i = 0; i < (1 << 16) / UDP_HTABLE_SIZE; i++) {
+			/***** SAKURA Linux start. *****/
+			if (ccs_may_autobind(rover) == 0)
+			/***** SAKURA Linux end. *****/
 			if (! __udp_lib_lport_inuse(net, rover, udptable))
 				goto gotit;
 			rover += UDP_HTABLE_SIZE;
--- linux-2.6.25-rc8-mm1.orig/net/socket.c
+++ linux-2.6.25-rc8-mm1/net/socket.c
@@ -94,6 +94,11 @@
 #include <net/sock.h>
 #include <linux/netfilter.h>
 
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+#include <linux/tomoyo_socket.h>
+/***** TOMOYO Linux end. *****/
+
 static int sock_no_open(struct inode *irrelevant, struct file *dontcare);
 static ssize_t sock_aio_read(struct kiocb *iocb, const struct iovec *iov,
 			 unsigned long nr_segs, loff_t pos);
@@ -557,6 +562,11 @@ static inline int __sock_sendmsg(struct 
 	err = security_socket_sendmsg(sock, msg, size);
 	if (err)
 		return err;
+	/***** TOMOYO Linux start. *****/
+	if (ccs_socket_sendmsg_permission(sock, (struct sockaddr *)
+					  msg->msg_name, msg->msg_namelen))
+		return -EPERM;
+	/***** TOMOYO Linux end. *****/
 
 	return sock->ops->sendmsg(iocb, sock, msg, size);
 }
@@ -1120,6 +1130,12 @@ static int __sock_create(struct net *net
 		family = PF_PACKET;
 	}
 
+	/***** TOMOYO Linux start. *****/
+	err = ccs_socket_create_permission(family, type, protocol);
+	if (err)
+		return err;
+	/***** TOMOYO Linux end. *****/
+
 	err = security_socket_create(family, type, protocol, kern);
 	if (err)
 		return err;
@@ -1351,6 +1367,13 @@ asmlinkage long sys_bind(int fd, struct 
 			err = security_socket_bind(sock,
 						   (struct sockaddr *)address,
 						   addrlen);
+			/***** TOMOYO Linux start. *****/
+			if (!err)
+				err = ccs_socket_bind_permission(sock,
+							 (struct sockaddr *)
+								 address,
+								 addrlen);
+			/***** TOMOYO Linux end. *****/
 			if (!err)
 				err = sock->ops->bind(sock,
 						      (struct sockaddr *)
@@ -1380,6 +1403,10 @@ asmlinkage long sys_listen(int fd, int b
 			backlog = somaxconn;
 
 		err = security_socket_listen(sock, backlog);
+		/***** TOMOYO Linux start. *****/
+		if (!err)
+			err = ccs_socket_listen_permission(sock);
+		/***** TOMOYO Linux end. *****/
 		if (!err)
 			err = sock->ops->listen(sock, backlog);
 
@@ -1444,6 +1471,13 @@ asmlinkage long sys_accept(int fd, struc
 	if (err < 0)
 		goto out_fd;
 
+	/***** TOMOYO Linux start. *****/
+	if (ccs_socket_accept_permission(newsock,
+					 (struct sockaddr *) address)) {
+		err = -ECONNABORTED; /* Hope less harmful than -EPERM. */
+		goto out_fd;
+	}
+	/***** TOMOYO Linux end. *****/
 	if (upeer_sockaddr) {
 		if (newsock->ops->getname(newsock, (struct sockaddr *)address,
 					  &len, 2) < 0) {
@@ -1508,6 +1542,13 @@ asmlinkage long sys_connect(int fd, stru
 	    security_socket_connect(sock, (struct sockaddr *)address, addrlen);
 	if (err)
 		goto out_put;
+	/***** TOMOYO Linux start. *****/
+	err = ccs_socket_connect_permission(sock,
+					    (struct sockaddr *) address,
+					    addrlen);
+	if (err)
+		goto out_put;
+	/***** TOMOYO Linux end. *****/
 
 	err = sock->ops->connect(sock, (struct sockaddr *)address, addrlen,
 				 sock->file->f_flags);
--- linux-2.6.25-rc8-mm1.orig/net/unix/af_unix.c
+++ linux-2.6.25-rc8-mm1/net/unix/af_unix.c
@@ -116,6 +116,9 @@
 #include <linux/mount.h>
 #include <net/checksum.h>
 #include <linux/security.h>
+/***** TOMOYO Linux start. *****/
+#include <linux/tomoyo.h>
+/***** TOMOYO Linux end. *****/
 
 static struct hlist_head unix_socket_table[UNIX_HASH_SIZE + 1];
 static DEFINE_SPINLOCK(unix_table_lock);
@@ -776,6 +779,11 @@ static int unix_bind(struct socket *sock
 		err = unix_autobind(sock);
 		goto out;
 	}
+	/***** TOMOYO Linux start. *****/
+	err = -EPERM;
+	if (sunaddr->sun_path[0] && !ccs_capable(TOMOYO_CREATE_UNIX_SOCKET))
+		goto out;
+	/***** TOMOYO Linux end. *****/
 
 	err = unix_mkname(sunaddr, addr_len, &hash);
 	if (err < 0)
@@ -822,6 +830,13 @@ static int unix_bind(struct socket *sock
 		err = mnt_want_write(nd.path.mnt);
 		if (err)
 			goto out_mknod_dput;
+		/***** TOMOYO Linux start. *****/
+		err = pre_vfs_mknod(nd.path.dentry->d_inode, dentry, mode);
+		if (!err)
+			err = ccs_check_1path_perm(TYPE_MKSOCK_ACL, dentry,
+						   nd.path.mnt);
+		if (!err)
+		/***** TOMOYO Linux end. *****/
 		err = vfs_mknod(nd.path.dentry->d_inode, dentry, mode, 0);
 		mnt_drop_write(nd.path.mnt);
 		if (err)
--- linux-2.6.25-rc8-mm1.orig/Documentation/kernel-parameters.txt
+++ linux-2.6.25-rc8-mm1/Documentation/kernel-parameters.txt
@@ -2130,6 +2130,21 @@ and is between 256 and 4096 characters. 
 	norandmaps	Don't use address space randomization
 			Equivalent to echo 0 > /proc/sys/kernel/randomize_va_space
 
+	CCS_loader=	[SAKURA/TOMOYO] Set policy loader's location.
+			Format: a valid pathname.
+			Default value /sbin/ccs-init.
+			This program is called when /sbin/init starts.
+
+	TOMOYO_QUIET	[TOMOYO] Turn off verbose mode by default.
+			Value can be changed at runtime via /proc/ccs/profile.
+
+	SYAORAN=	[SYAORAN] Set initial access control status.
+			Format: {"accept" | "enforce"}
+			accept -- permissive (log only, no denials).
+			enforce -- enforcing (deny and log).
+			Default value is not set.
+			Value can be changed at runtime via mount option.
+
 ______________________________________________________________________
 
 TODO:

-- 

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Daniel Walker]

On Fri, 2008-04-04 at 21:23 +0900, Tetsuo Handa wrote:

> This patch makes two lines deletion by
>   sed -e 's:search_binary_handler:search_binary_handler_with_transition:'
> TOMOYO does domain transition when execve() is called.
> Thus, distinguishing search_binary_handler() from do_execve() and
> search_binary_handler() from other functions (e.g. load_script())
> makes TOMOYO's domain transition handler simple.
> 
> Signed-off-by: Kentaro Takeda <takedakn@nttdata.co.jp>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Signed-off-by: Toshiharu Harada <haradats@nttdata.co.jp>
> Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
> Cc: linux-netdev <netdev@vger.kernel.org>
> ---
>  Documentation/kernel-parameters.txt |   15 ++++
>  arch/ia64/ia32/sys_ia32.c           |    7 ++
>  arch/mips/kernel/ptrace32.c         |    7 ++
>  arch/s390/kernel/ptrace.c           |    7 ++
>  arch/sh/kernel/ptrace_64.c          |    7 ++
>  arch/x86/kernel/ptrace.c            |    7 ++
>  fs/Kconfig                          |    2 
>  fs/Makefile                         |    2 
>  fs/attr.c                           |   19 +++++

>From a reviews perspective what I would want is each set of changes,
file system, networking, arch, etc split into separate patches. For
example you have a number of patches just adding header files. You could
merge the header file with the hook additions. Then you have a natural
code split up which should be easier to review..

> +	/***** TOMOYO Linux start. *****/
> +	if (!ccs_capable(TOMOYO_SYS_PTRACE))
> +		return -EPERM;
> +	/***** TOMOYO Linux end. *****/

For instance if the function name was "tomoyo_check_capable" it would be
clear that it's part of your code.. The current function naming here is
obscure ..
 

> +	/***** CCS start. *****/
> +#if defined(CONFIG_SAKURA) || defined(CONFIG_TOMOYO)
> +	printk(KERN_INFO "Hook version: 2.6.25-rc8-mm1 2008/04/02\n");
> +#endif
> +	/***** CCS end. *****/

This printk clearly needs to go away ..

> --- linux-2.6.25-rc8-mm1.orig/include/linux/init_task.h
> +++ linux-2.6.25-rc8-mm1/include/linux/init_task.h
> @@ -197,6 +197,10 @@ extern struct group_info init_groups;
>  	INIT_IDS							\
>  	INIT_TRACE_IRQFLAGS						\
>  	INIT_LOCKDEP							\
> +	/***** TOMOYO Linux start. *****/        \
> +	.domain_info = &KERNEL_DOMAIN,           \
> +	.tomoyo_flags = 0,                       \
> +	/***** TOMOYO Linux end. *****/          \
>  }

ifdef's ?

> 
> --- linux-2.6.25-rc8-mm1.orig/include/linux/sched.h
> +++ linux-2.6.25-rc8-mm1/include/linux/sched.h
> @@ -29,6 +29,11 @@
>  #define CLONE_NEWNET		0x40000000	/* New network namespace */
>  #define CLONE_IO		0x80000000	/* Clone io context */
>  
> +/***** TOMOYO Linux start. *****/
> +struct domain_info;
> +extern struct domain_info KERNEL_DOMAIN;
> +/***** TOMOYO Linux end. *****/
> +
>  /*
>   * Scheduling policies
>   */
> @@ -1278,6 +1283,10 @@ struct task_struct {
>  	int latency_record_count;
>  	struct latency_record latency_record[LT_SAVECOUNT];
>  #endif
> +	/***** TOMOYO Linux start. *****/
> +	struct domain_info *domain_info;
> +	u32 tomoyo_flags;
> +	/***** TOMOYO Linux end. *****/
>  };

ifdefs? 
 

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Tetsuo Handa]

Daniel Walker wrote:
> From a reviews perspective what I would want is each set of changes,
> file system, networking, arch, etc split into separate patches. For
> example you have a number of patches just adding header files. You could
> merge the header file with the hook additions. Then you have a natural
> code split up which should be easier to review..
Filesystem part to fsdevel, socket operation part to netdev. That's OK.
But I wonder where to post the rest part.
Since the patches for passing "struct vfsmount" to LSM has been rejected,
TOMOYO has been unable to use LSM.
Thus, I proposed this patch set as a non-LSM version, but it bothers me
where to post this patch. If you know, please teach me where to post.

> > --- linux-2.6.25-rc8-mm1.orig/include/linux/init_task.h
> > +++ linux-2.6.25-rc8-mm1/include/linux/init_task.h
> > @@ -197,6 +197,10 @@ extern struct group_info init_groups;
> >  	INIT_IDS							\
> >  	INIT_TRACE_IRQFLAGS						\
> >  	INIT_LOCKDEP							\
> > +	/***** TOMOYO Linux start. *****/        \
> > +	.domain_info = &KERNEL_DOMAIN,           \
> > +	.tomoyo_flags = 0,                       \
> > +	/***** TOMOYO Linux end. *****/          \
> >  }
> 
> ifdef's ?

Or security_initcall()?

> > @@ -1278,6 +1283,10 @@ struct task_struct {
> >  	int latency_record_count;
> >  	struct latency_record latency_record[LT_SAVECOUNT];
> >  #endif
> > +	/***** TOMOYO Linux start. *****/
> > +	struct domain_info *domain_info;
> > +	u32 tomoyo_flags;
> > +	/***** TOMOYO Linux end. *****/
> >  };
> 
> ifdefs? 
>
I see.

Thank you.

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Daniel Walker]

On Mon, 2008-04-07 at 22:56 +0900, Tetsuo Handa wrote:
> Daniel Walker wrote:
> > From a reviews perspective what I would want is each set of changes,
> > file system, networking, arch, etc split into separate patches. For
> > example you have a number of patches just adding header files. You could
> > merge the header file with the hook additions. Then you have a natural
> > code split up which should be easier to review..
> Filesystem part to fsdevel, socket operation part to netdev. That's OK.
> But I wonder where to post the rest part.
> Since the patches for passing "struct vfsmount" to LSM has been rejected,
> TOMOYO has been unable to use LSM.
> Thus, I proposed this patch set as a non-LSM version, but it bothers me
> where to post this patch. If you know, please teach me where to post.

Not sure .. You might look through the MAINTAINERS file and see if
anyone maintains the sections of code your changing. Usually LKML and
Andrew are pretty good bets especially when your not sure who the
patches should go to.

Daniel

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Paul Moore]

On Friday 04 April 2008 8:23:12 am Tetsuo Handa wrote:
> This file contains modifications against kernel source code
> needed to use TOMOYO Linux 1.6.
>
> Although LSM hooks are provided for performing access control,
> TOMOYO Linux 1.6 doesn't use LSM because of the following reasons.

Hello,

I understand your frustration with the existing LSM hooks/API and your 
reasoning for abandoning LSM in favor of a new set of hooks, however, I 
think this sets a dangerous precedence which could result in an 
abundance of security related hooks scattered throughout the kernel.  I 
would much rather see the LSM API extended/tweaked to support the needs 
of SAKURA and TOMOYO than ignored and duplicated; I suspect several 
others will say the same.

You have made good progress with TOMOYO so far and if I can remember 
correctly you really only have one hurdle left, the VFS portion.  
Please continue to seek a solution to this that fits within the LSM 
framework.

Thank you.

-- 
paul moore
linux @ hp

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Casey Schaufler]

--- Paul Moore <paul.moore@hp.com> wrote:

> On Friday 04 April 2008 8:23:12 am Tetsuo Handa wrote:
> > This file contains modifications against kernel source code
> > needed to use TOMOYO Linux 1.6.
> >
> > Although LSM hooks are provided for performing access control,
> > TOMOYO Linux 1.6 doesn't use LSM because of the following reasons.
> 
> Hello,
> 
> I understand your frustration with the existing LSM hooks/API and your 
> reasoning for abandoning LSM in favor of a new set of hooks, however, I 
> think this sets a dangerous precedence which could result in an 
> abundance of security related hooks scattered throughout the kernel.  I 
> would much rather see the LSM API extended/tweaked to support the needs 
> of SAKURA and TOMOYO than ignored and duplicated; I suspect several 
> others will say the same.

The same.



Casey Schaufler
casey@schaufler-ca.com

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Toshiharu Harada]

On 4/8/2008 12:40 AM, Paul Moore wrote:
> On Friday 04 April 2008 8:23:12 am Tetsuo Handa wrote:
>> This file contains modifications against kernel source code
>> needed to use TOMOYO Linux 1.6.
>>
>> Although LSM hooks are provided for performing access control,
>> TOMOYO Linux 1.6 doesn't use LSM because of the following reasons.
> 
> Hello,
> 
> I understand your frustration with the existing LSM hooks/API and your 
> reasoning for abandoning LSM in favor of a new set of hooks, however, I 
> think this sets a dangerous precedence which could result in an 
> abundance of security related hooks scattered throughout the kernel.  I 
> would much rather see the LSM API extended/tweaked to support the needs 
> of SAKURA and TOMOYO than ignored and duplicated; I suspect several 
> others will say the same.
> 
> You have made good progress with TOMOYO so far and if I can remember 
> correctly you really only have one hurdle left, the VFS portion.  
> Please continue to seek a solution to this that fits within the LSM 
> framework.
> 
> Thank you.

Thank you for your comments and concern.

I realized that we should have included the reason why we decided to
post non-LSM version. Let me explain the reason and the history.

We started developing TOMOYO Linux as original patch sets against
2.4 vanilla kernel. We understand the role of LSM, so we ported
TOMOYO Linux to use LSM and submitted it to the LKML on 13 June 2007.
We kept working to reflect feedbacks from the community and believe
no critical Nack remains.

http://lwn.net/Articles/238049/
http://lwn.net/Articles/246930/
http://lwn.net/Articles/252652/
http://lwn.net/Articles/254503/
http://lwn.net/Articles/258905/
http://lwn.net/Articles/263179/
http://lwn.net/Articles/264187/
http://lwn.net/Articles/276603/

Still there remains an issue of LSM limitation (vfsmount parameter
isn’t passed to LSM).

LWN article 239962 says, "At the 2006 summit, Linus took a clear
position that the use of pathnames for security policies seemed
reasonable to him". Current LSM implementation is sufficient for SELinux
and other label based MACs but not for pathname-based MACs.
This has been argued in the AppAmor thread for quite a long time.
Though proposals had been posted by AppArmor and TOMOYO Linux project,
none has been merged until now.

We apologize for the confusion we caused in the last posting,
but we don't want to give up returning our work to the mainline. 

We cordially request LSM changes to pass vfsmount parameters.

Finally, the following links are our answers to the Linux Weather Forecast. (http://www.linux-foundation.org/en/Linux_Weather_Forecast/security#TOMOYO_Linux)

http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
http://sourceforge.jp/projects/tomoyo/document/fosdem2008.pdf
http://sourceforge.jp/projects/tomoyo/document/PacSec2007-handout.pdf

Regards,
Toshiharu Harada
NTT DATA CORPORATION

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Stephen Smalley]

On Wed, 2008-04-09 at 17:37 +0900, Toshiharu Harada wrote:
> On 4/8/2008 12:40 AM, Paul Moore wrote:
> > On Friday 04 April 2008 8:23:12 am Tetsuo Handa wrote:
> >> This file contains modifications against kernel source code
> >> needed to use TOMOYO Linux 1.6.
> >>
> >> Although LSM hooks are provided for performing access control,
> >> TOMOYO Linux 1.6 doesn't use LSM because of the following reasons.
> > 
> > Hello,
> > 
> > I understand your frustration with the existing LSM hooks/API and your 
> > reasoning for abandoning LSM in favor of a new set of hooks, however, I 
> > think this sets a dangerous precedence which could result in an 
> > abundance of security related hooks scattered throughout the kernel.  I 
> > would much rather see the LSM API extended/tweaked to support the needs 
> > of SAKURA and TOMOYO than ignored and duplicated; I suspect several 
> > others will say the same.
> > 
> > You have made good progress with TOMOYO so far and if I can remember 
> > correctly you really only have one hurdle left, the VFS portion.  
> > Please continue to seek a solution to this that fits within the LSM 
> > framework.
> > 
> > Thank you.
> 
> Thank you for your comments and concern.
> 
> I realized that we should have included the reason why we decided to
> post non-LSM version. Let me explain the reason and the history.
> 
> We started developing TOMOYO Linux as original patch sets against
> 2.4 vanilla kernel. We understand the role of LSM, so we ported
> TOMOYO Linux to use LSM and submitted it to the LKML on 13 June 2007.
> We kept working to reflect feedbacks from the community and believe
> no critical Nack remains.
> 
> http://lwn.net/Articles/238049/
> http://lwn.net/Articles/246930/
> http://lwn.net/Articles/252652/
> http://lwn.net/Articles/254503/
> http://lwn.net/Articles/258905/
> http://lwn.net/Articles/263179/
> http://lwn.net/Articles/264187/
> http://lwn.net/Articles/276603/
> 
> Still there remains an issue of LSM limitation (vfsmount parameter
> isn’t passed to LSM).
> 
> LWN article 239962 says, "At the 2006 summit, Linus took a clear
> position that the use of pathnames for security policies seemed
> reasonable to him". Current LSM implementation is sufficient for SELinux
> and other label based MACs but not for pathname-based MACs.
> This has been argued in the AppAmor thread for quite a long time.
> Though proposals had been posted by AppArmor and TOMOYO Linux project,
> none has been merged until now.
> 
> We apologize for the confusion we caused in the last posting,
> but we don't want to give up returning our work to the mainline. 
> 
> We cordially request LSM changes to pass vfsmount parameters.

Don't cordially request it - submit patches to make it happen.  Or work
with others who have been submitting such patches.

There are two options:
1) Submit patches to pass down the vfsmounts to the vfs helpers so that
they can be passed to the existing security_inode hooks. -or-
2) Submit patches to add new security hooks to the callers where the
vfsmount is already available (some have suggested moving the existing
security_inode hooks to the callers, but that would cause problems for
SELinux as I've posted elsewhere, so adding new hooks is preferable, and
then SELinux can just default to the dummy functions for those new
hooks).

-- 
Stephen Smalley
National Security Agency

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Toshiharu Harada]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On 4/9/2008 9:49 PM, Stephen Smalley wrote:
>> We cordially request LSM changes to pass vfsmount parameters.
> 
> Don't cordially request it - submit patches to make it happen.  Or work
> with others who have been submitting such patches.

You are (always) right. :)

> There are two options:
> 1) Submit patches to pass down the vfsmounts to the vfs helpers so that
> they can be passed to the existing security_inode hooks. -or-
> 2) Submit patches to add new security hooks to the callers where the
> vfsmount is already available (some have suggested moving the existing
> security_inode hooks to the callers, but that would cause problems for
> SELinux as I've posted elsewhere, so adding new hooks is preferable, and
> then SELinux can just default to the dummy functions for those new
> hooks).

Thank you for your suggestions. I drew a diagram. Is this correct?

Regards,
Toshiharu Harada
NTT DATA CORPORATION

[-- Attachment #2: options.png --]
[-- Type: image/png, Size: 40962 bytes --]

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Stephen Smalley]

On Thu, 2008-04-10 at 14:57 +0900, Toshiharu Harada wrote:
> On 4/9/2008 9:49 PM, Stephen Smalley wrote:
> >> We cordially request LSM changes to pass vfsmount parameters.
> > 
> > Don't cordially request it - submit patches to make it happen.  Or work
> > with others who have been submitting such patches.
> 
> You are (always) right. :)

Definitely not always.

> > There are two options:
> > 1) Submit patches to pass down the vfsmounts to the vfs helpers so that
> > they can be passed to the existing security_inode hooks. -or-
> > 2) Submit patches to add new security hooks to the callers where the
> > vfsmount is already available (some have suggested moving the existing
> > security_inode hooks to the callers, but that would cause problems for
> > SELinux as I've posted elsewhere, so adding new hooks is preferable, and
> > then SELinux can just default to the dummy functions for those new
> > hooks).
> 
> Thank you for your suggestions. I drew a diagram. Is this correct?

I think the text above is self-explanatory; I'm not sure what the
diagram adds.  Also, Matthew Wilcox pointed out a third option that you
ought to consider, and you can look to the example of audit filesystem
watches there, which leverages inotify internally.

If that isn't feasible for some reason, then option (2) should be fairly
straightforward - you just define and insert some new security hooks in
the callers where the vfsmount is already available.

-- 
Stephen Smalley
National Security Agency

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Toshiharu Harada]

On 4/10/2008 9:51 PM, Stephen Smalley wrote:
>>> There are two options:
>>> 1) Submit patches to pass down the vfsmounts to the vfs helpers so that
>>> they can be passed to the existing security_inode hooks. -or-
>>> 2) Submit patches to add new security hooks to the callers where the
>>> vfsmount is already available (some have suggested moving the existing
>>> security_inode hooks to the callers, but that would cause problems for
>>> SELinux as I've posted elsewhere, so adding new hooks is preferable, and
>>> then SELinux can just default to the dummy functions for those new
>>> hooks).
>> Thank you for your suggestions. I drew a diagram. Is this correct?
> 
> I think the text above is self-explanatory; I'm not sure what the
> diagram adds.  Also, Matthew Wilcox pointed out a third option that you
> ought to consider, and you can look to the example of audit filesystem
> watches there, which leverages inotify internally.
The diagram was meant to help clarifying things not to add/change
the information. I also like texts but IMO diagrams are useful
for starting arguments over networks.

Yes. Regarding the third option, Tetsuo is preparing to respond
(Matthew, sorry for snail response. it's on the way).

> If that isn't feasible for some reason, then option (2) should be fairly
> straightforward - you just define and insert some new security hooks in
> the callers where the vfsmount is already available.

My diagram worked very well for me. I noticed theoretically
there are four options.

option (1) "pass down the vfsmounts to the vfs helpers"
           (let "vfsmount" bridge namespace and filesystems)
+ LSM needs less changes
- VFS and filesystems need more changes

option (2) "add new security hooks to the callers"
           (adding hooks in namespace)
+ VFS and filesystems need very little changes
- LSM needs to be added new hooks

option (3) "pathname based policy and inode based access control" (by Wilcox)
           (self-explanatory)
+ does not need changes for LSM nor VFS
- can not keep consistency of policy and results

option (4) "introduce completely orthogonal access control besides LSM"
           (like devcgroup, r/o bind mounts (in mm tree))
+ does not need LSM changes
+ pathname based MAC can coexists with label based MAC
- should not ... (the LAST method)


Regarding option 3, Tetsuo will explain difficulties in
another message. TOMOYO Linux project is planning to
make patches of option 2 because it's the most straightforward way
as you suggested. Also we will be carefully watching the
discussion of "vfs: add helpers to check r/o bind mounts".

Regards,
Toshiharu Harada
NTT DATA CORPORATION

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Matthew Wilcox]

On Wed, Apr 09, 2008 at 05:37:38PM +0900, Toshiharu Harada wrote:
> LWN article 239962 says, "At the 2006 summit, Linus took a clear
> position that the use of pathnames for security policies seemed
> reasonable to him". Current LSM implementation is sufficient for SELinux
> and other label based MACs but not for pathname-based MACs.
> This has been argued in the AppAmor thread for quite a long time.
> Though proposals had been posted by AppArmor and TOMOYO Linux project,
> none has been merged until now.

How about an approach which doesn't require the vfsmount to be passed
down?

When the rule is put in place, say "No modifications to /etc/passwd",
look up the inode and major:minor of /etc/passwd.  If there's a rename,
look up the new inode number.  If it's mounted elsewhere, it doesn't
matter, they still can't modify it because it has the same
major:minor:inode.

Is this workable?

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Stephen Smalley]

On Wed, 2008-04-09 at 07:11 -0600, Matthew Wilcox wrote:
> On Wed, Apr 09, 2008 at 05:37:38PM +0900, Toshiharu Harada wrote:
> > LWN article 239962 says, "At the 2006 summit, Linus took a clear
> > position that the use of pathnames for security policies seemed
> > reasonable to him". Current LSM implementation is sufficient for SELinux
> > and other label based MACs but not for pathname-based MACs.
> > This has been argued in the AppAmor thread for quite a long time.
> > Though proposals had been posted by AppArmor and TOMOYO Linux project,
> > none has been merged until now.
> 
> How about an approach which doesn't require the vfsmount to be passed
> down?
> 
> When the rule is put in place, say "No modifications to /etc/passwd",
> look up the inode and major:minor of /etc/passwd.  If there's a rename,
> look up the new inode number.  If it's mounted elsewhere, it doesn't
> matter, they still can't modify it because it has the same
> major:minor:inode.
> 
> Is this workable?

Sounds similar to audit watches, e.g. see audit_add_watch() and
audit_handle_ievent().  That leverages inotify internally.

-- 
Stephen Smalley
National Security Agency

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Tetsuo Handa]

Sorry for slow response.

Matthew Wilcox wrote:
> When the rule is put in place, say "No modifications to /etc/passwd",
> look up the inode and major:minor of /etc/passwd.  If there's a rename,
> look up the new inode number.  If it's mounted elsewhere, it doesn't
> matter, they still can't modify it because it has the same
> major:minor:inode.

If write access is denied because of a rule "No modifications to /etc/passwd",
a rule "Allow modifications to /tmp/passwd" can no longer be enforced after
"mount --bind /etc/ /tmp/" or "mount --bind /etc/passwd /tmp/passwd" or
"mv /etc/passwd /tmp/passwd" or "ln /etc/passwd /tmp/passwd" is done.

"No modifications" (i.e. "forbid modifications") and
"Allow modifications" (i.e. "don't forbid modifications") are incompatible
rules as long as the rules are described using pathnames but the judgment is
done using inodes (or labels).

If rules are described like "No modifications to passwd_t",
it is correct to deny modifications of the file when the file
with passwd_t was renamed or bind-mounted or hard-linked.
Those who want to do access restriction based on the entity of the file
prefer rules described using inodes (or labels).

If rules are described like "No modifications to /etc/passwd" and
"Allow modifications to /tmp/passwd", it is wrong to deny modifications of
the file when /etc/passwd was renamed or bind-mounted or hard-linked to
/tmp/passwd .
Those who want to do access restriction based on the location of the file
prefer rules described using pathnames.

SELinux and Smack are the former.
AppArmor and TOMOYO Linux are the latter.

> Is this workable?
I'm afraid it is unlikely.

Thank you.

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Matthew Wilcox]

On Fri, Apr 11, 2008 at 11:12:27PM +0900, Tetsuo Handa wrote:
> Matthew Wilcox wrote:
> > When the rule is put in place, say "No modifications to /etc/passwd",
> > look up the inode and major:minor of /etc/passwd.  If there's a rename,
> > look up the new inode number.  If it's mounted elsewhere, it doesn't
> > matter, they still can't modify it because it has the same
> > major:minor:inode.
> 
> If write access is denied because of a rule "No modifications to /etc/passwd",
> a rule "Allow modifications to /tmp/passwd" can no longer be enforced after
> "mount --bind /etc/ /tmp/" or "mount --bind /etc/passwd /tmp/passwd" or
> "mv /etc/passwd /tmp/passwd" or "ln /etc/passwd /tmp/passwd" is done.

That's a fundamental limitation of pathname-based security though.
If the same file exists in two places, you have to resolve the question
of which rule overrides the other.

In my role as a sysadmin, I would consider it a flaw if someone could
edit a file I'd marked uneditable -- simply by creating a hard-link to it.
If we look at existing systems, such as the immutable bit, those apply to
inodes, not to paths, so they can't be evaded.  If a system such as TOMOYA
allows evasion this easily, then it doesn't seem like an improvement.

So when considering your problem, I worked from the point of view of the
attacker "Oh, I can't modify /etc/passwd?  In that case, I'll create
a new name to the same file", and then figured out a defense to it.
I did not consider the case where the admin /wants/ to allow access
through different pathnames to the same file that's denied access.
That doesn't seem like a secure system to me.

In short, if a file is named as protected, I think the admin clearly
means to protect that file -- no matter what name is used to address it.

> If rules are described like "No modifications to passwd_t",
> it is correct to deny modifications of the file when the file
> with passwd_t was renamed or bind-mounted or hard-linked.
> Those who want to do access restriction based on the entity of the file
> prefer rules described using inodes (or labels).
> 
> If rules are described like "No modifications to /etc/passwd" and
> "Allow modifications to /tmp/passwd", it is wrong to deny modifications of
> the file when /etc/passwd was renamed or bind-mounted or hard-linked to
> /tmp/passwd .
> Those who want to do access restriction based on the location of the file
> prefer rules described using pathnames.

My impression of pathname-based security was that it was preferred
because it's easier to administer than setting labels and making sure
everything has the right capabilities.  But from what you're saying,
it seems like it's no additional security at all.

Let's take an example.  We have the two rules "nobody can edit
/etc/passwd" and "root can edit /tmp/passwd".  A daemon running as root
is compromised.  Instead of being able to simply write to /etc/passwd,
the attacker has to "ln /etc/passwd /tmp" first.  There's no additional
security here, just obfuscation.

So I say a 'DENY' rule must always override an 'ALLOW' rule where two
filenames happen to map to the same file.  Or it's just snake-oil.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Tetsuo Handa]

----- part 1 -----

Matthew Wilcox wrote:
> In my role as a sysadmin, I would consider it a flaw if someone could
> edit a file I'd marked uneditable -- simply by creating a hard-link to it.

That depends on the *language* you used for marking.

I feel it is a flaw if the policy says "you can read a file reached by
resolving /tmp/ro_file" and "you can read/write a file reached by resolving
/tmp/rw_file" but the access control mechanism says "you cannot write a file
reached by resolving /tmp/rw_file because this file is a hard link of
/tmp/ro_file".
Both statements "you can read a file reached by resolving /tmp/ro_file" and
"you can read/write a file reached by resolving /tmp/rw_file" have to be
adhered by the access control mechanism. If not, I dismiss such access control
mechanism.

I feel it is a flaw if the policy says "you can read a file with ro_file_t" and
"you can read/write a file with rw_file_t" but the access control mechanism
says "you cannot write a file with rw_file_t".

Those who use policy based access control must understand what the policy says.
Pathname language does not refer to the entity of a file.
It refers to one of routes to reach to a file.
Don't expect pathname language to refer to the entity of a file.
If you use pathnames as the language to describe rules in policy,
you must understand what the pathname language refers to and accept it.
If you cannot accept it, don't use pathname language in policy.
Use label (or inode number) as the language to describe rules in policy
(like SELinux).

> In short, if a file is named as protected, I think the admin clearly
> means to protect that file -- no matter what name is used to address it.

If "named" in your statement used pathname, the admin didn't clearly mean to
protect that file.
If "named" in your statement used inode number (or label), the admin clearly
meant to protect that file.

----- part 2 -----

> If the same file exists in two places, you have to resolve the question
> of which rule overrides the other.

Your suggestion to use pathname in policy file but judge based on inode number
is incompatible.

What users see and approve as the policy is pathnames, and they expect
the policy to be adhered. But if the policy cannot be adhered by some reason
(e.g. hard link problems), access control mechanism must ask users for
explicit approval *before* the policy is loaded.
It is no good to override the rules without asking users for explicit approval.
If the rules are implicitly overridden and the system became malfunction,
users will dismiss such access control mechanism.

If you suggest to use inode number in policy file (and users see and approve
as the policy) and judge based on inode number, it is correct, and that is
LIDS (Linux Intrusion Detecting System).

> Let's take an example.  We have the two rules "nobody can edit
> /etc/passwd" and "root can edit /tmp/passwd".  A daemon running as root
> is compromised.  Instead of being able to simply write to /etc/passwd,
> the attacker has to "ln /etc/passwd /tmp" first.  There's no additional
> security here, just obfuscation.

It seems to me that you are assuming that pathname based access control uses
black listing. Pathname based access control uses while listing.
So, unless permission to do "ln /etc/passwd /tmp" is explicitly defined in
the policy, the attacker cannot do "ln /etc/passwd /tmp".

The character of pathname based policy is that pathname doesn't reflect
the past state. But please be patient and continue reading before you complain
"Pathname based access control is completely helpless for security".
Pathname based access control has a role in security.

----- part 3 -----

I don't want to start label-vs-pathname battle again.
But I must explain that security is not so simple that can be covered by
only label (or inode number) based access control.

Correctness of userland application code plays some part of security,
correctness of user's operation plays some part of security,
correctness of kernel code plays some part of security,
correctness of file's label plays some part of security,
correctness of file's pathname plays some part of security,
and more...

What SELinux people are talking about is "correctness of file's label is
important".
But I want to talk about "correctness of file's pathname is also important".

Do you think pathname has nothing to do with system's security?
The answer is no. Names have meaning. Names are very important.

The system's availability depends on whether essential files are in place.

You can write policy that allows mounting procfs on /sys/ and sysfs on /proc/ .
But if you actually do such mounts, the system will no longer work as expected.
/proc/ is expected that procfs is mounted and /sys/ is expected that sysfs
is mounted.

Let's consider that buggy program1 needs to create /etc/config1 and
rename /etc/config1 to /etc/config1.old .
You can write policy that allows creating and renaming files in /etc/ .
But if the granularity is "allow creating and renaming files in /etc/ ",
it can lead to unexpected behavior.
If program1 created /etc/config1 and renamed /etc/config1 to /etc/config1.old ,
that's no problem.
If program1 created /etc/config1 and renamed /etc/config1 to /etc/nologin ,
that's problematic. You know, /etc/nologin is a marker that indicates
non-root users are not permitted to login to the system.
You should have written policy that only allows "create /etc/config1" and
"rename /etc/config1 to /etc/config1.old" rather than
"create files in /etc/ directory" and "rename files in /etc/ directory"
to make sure that program1 won't intervene other user's login.

No problem because labels are not changed?
OK. Let's consider that malicious admin1 is permitted to create /forcefsck
and run /sbin/reboot to do maintenance task.
You can write policy that allows creating files in / .
If malicious admin1 creates /forcefsck and runs /sbin/reboot ,
that's no problem.
If malicious admin1 creates /.autorelabel and runs /sbin/reboot ,
that's problematic. You know, files that are not in place will lose their
labels since relabeling operation takes place upon bootup.
You should have written policy that only allows "create /forcefsck" rather than
"create files in / directory" to make sure that admin1 won't tamper labels.

What if /etc/passwd is renamed to /etc/my_passwd?
Label (or inode number) is not changed. But users can no longer login.
Still no problems?

What if /bin/cat and /usr/bin/md5sum are exchanged?
Label (or inode number) is not changed. But many scripts stops working.
Still no problems?

What if /etc/ is bind mounted to /bin/ ?
Label (or inode number) is not changed. But programs won't work.
Still no problems?

No way...

It is a label's (or inode's) advantage that the result of access request is not
affected by rename/link/bind-mount operations.
But that is different from "I can rename/link/bind-mount files freely because
rename/link/bind-mount won't affect the result of access request".
The system behaves differently if essential files are not in place.
To keep the system available, don't allow rename/link/bind-mount operations
freely from the beginning, even if the labels (or inode numbers) are preserved.

----- part 4 -----

Operations that changes pathnames (i.e. rename/link/bind-mount ) are
unnecessary for almost all files in a system. Only a few files such as
/etc/passwd.$$ are subjected to rename/link/bind-mount operations.

When defining pathname based policy, firstly, separate files that are subjected
to rename/link/bind-mount operations and files that are not.
Secondly, write policy that allows rename/link/bind-mount operations with
the granularity of /foo/bar rather than /foo/ to minimize the uncertain part
in the pathname.

> So when considering your problem, I worked from the point of view of the
> attacker "Oh, I can't modify /etc/passwd?  In that case, I'll create
> a new name to the same file", and then figured out a defense to it.

Don't expect that /etc/passwd is allowed to freely rename/link/bind-mount from
the beginning. It is not allowed by default, and is allowed only if it is
needed for the system to work properly.

You might think that "Why do you spend resources in restricting names that
can exist within a mount tree? You can save a lot of resources if you don't
use pathnames for restricting access.", and the below is my answer.

"Applications depend on pathnames, not on inode's number or labels.
 Thinking little of pathnames leads to serious result."

SELinux (label based access control) tries to keep correctness of
file's attributes by restricting operation that changes attributes.
TOMOYO Linux (pathname based access control) tries to keep correctness of
file's pathnames by restricting operation that changes names.
SELinux and TOMOYO Linux are both security tools.
But they play different part in security.

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Serge E. Hallyn]

Quoting Matthew Wilcox (matthew@wil.cx):
> On Fri, Apr 11, 2008 at 11:12:27PM +0900, Tetsuo Handa wrote:
> > Matthew Wilcox wrote:
> > > When the rule is put in place, say "No modifications to /etc/passwd",
> > > look up the inode and major:minor of /etc/passwd.  If there's a rename,
> > > look up the new inode number.  If it's mounted elsewhere, it doesn't
> > > matter, they still can't modify it because it has the same
> > > major:minor:inode.
> > 
> > If write access is denied because of a rule "No modifications to /etc/passwd",
> > a rule "Allow modifications to /tmp/passwd" can no longer be enforced after
> > "mount --bind /etc/ /tmp/" or "mount --bind /etc/passwd /tmp/passwd" or
> > "mv /etc/passwd /tmp/passwd" or "ln /etc/passwd /tmp/passwd" is done.
> 
> That's a fundamental limitation of pathname-based security though.
> If the same file exists in two places, you have to resolve the question
> of which rule overrides the other.

In the past, Crispin has given clear, concise explanations of a few of
the things pathname based access control in fact excels at.  Crispin,
can you recite those again so we can think constructively about which
(if any) of the currently considered options are or are not sufficient?

I.e. what would be a motivation for a rule like 'no modifications to
/etc/passwd', and what precisely would and would not be accepted ways to
get around it (and why)?

thanks,
-serge

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Crispin Cowan]

Serge E. Hallyn wrote:
> Quoting Matthew Wilcox (matthew@wil.cx):
>   
>> On Fri, Apr 11, 2008 at 11:12:27PM +0900, Tetsuo Handa wrote:
>>     
>>> Matthew Wilcox wrote:
>>>       
>>>> When the rule is put in place, say "No modifications to /etc/passwd",
>>>> look up the inode and major:minor of /etc/passwd.  If there's a rename,
>>>> look up the new inode number.  If it's mounted elsewhere, it doesn't
>>>> matter, they still can't modify it because it has the same
>>>> major:minor:inode.
>>>>         
>>> If write access is denied because of a rule "No modifications to /etc/passwd",
>>> a rule "Allow modifications to /tmp/passwd" can no longer be enforced after
>>> "mount --bind /etc/ /tmp/" or "mount --bind /etc/passwd /tmp/passwd" or
>>> "mv /etc/passwd /tmp/passwd" or "ln /etc/passwd /tmp/passwd" is done.
>>>       
>> That's a fundamental limitation of pathname-based security though.
>> If the same file exists in two places, you have to resolve the question
>> of which rule overrides the other.
>>     
> In the past, Crispin has given clear, concise explanations of a few of
> the things pathname based access control in fact excels at.  Crispin,
> can you recite those again so we can think constructively about which
> (if any) of the currently considered options are or are not sufficient?
>
> I.e. what would be a motivation for a rule like 'no modifications to
> /etc/passwd', and what precisely would and would not be accepted ways to
> get around it (and why)?
>   
As I just posted, a rule of "no mods to /some/pathname" is broken, which 
is why AppArmor has no such construct.

Things that pathname-based access control is good at:

    * *System Integrity:* Many of the vital components of a UNIX system
      are stored in files with Well Known Names such as /etc/shadow,
      /var/www/htdocs/index.html and /home/crispin/.ssh/known_hosts. The
      contents of the actual data blocks is less important than the
      integrity of what some random process gets when it asks for these
      resources by name. Preserving the integrity of what responds to
      the Well Known Name is thus easier if you restrict access based on
      the name.
    * *Dynamic Access Control:* A special case of the above pertains to
      files that may or may not exist. If you don't *have* a /etc/hosts
      file, it is still important to have a rule that controls whether
      it can be created. This is hard to do in label-based systems,
      because the file does not exist to put a label on, so you have to
      kludge it by either creating the file with zero length and
      labeling it, or by creating more complex policy for the parent
      /etc directory, and that's hard given the number of uses for /etc
      such as /etc/motd. In a name based scheme, you simply don't
      provide write permission to "/etc/hosts" unless you mean it, and
      it can be enforced even if such a file does not exist.
    * *Ad Hoc Generalization:* Label-based access control generalizes
      policy in that the policy treats all files and resources that
      share a label the same. If you want to make a new generalization
      that encompasses *part* of the files that share a label, but *not
      all* of those files, then you have to "split the label", relabel
      the file system, and revise the policy accordingly. Name-based
      access control lets you create ad hoc generalizations, so that
      *my* policy can grant access to "/var/www/*.pl" without regard to
      whatever labels or rules some other policy has applied to the same
      directory tree.
    * *Familiar Interface:* Administrators are accustomed to
      administering the box in terms of the names of the files that
      matter. A name-based policy is therefore somewhat more familiar
      than a policy with label abstractions, where they then have to go
      look at the restorecon file to discover what files will/should
      have what labels.
    * *Practical Concerns:* Not all file systems support labels, and so
      label-based schemes become coarse grained when they run into them.
      Name based schemes remain granular when specifying access down
      into the internals of such file systems. Legacy Linux file systems
      like ext2 don't matter much any more, but persistent file systems
      that will never have label support include NFSv3 file systems
      (nearly every Network Appliance NAS server out there) and FAT32
      file system (most every USB storage device).

A lot of what's going on is the duality of the one:many relationships 
between labels and names:

    * Labels: one label represents many files
          o this property is why ad hoc generalization fails in label
            based systems
    * Names: many names can represent a single file
          o This property is why deny rules fail in name based systems

Therefore, I am not claiming name-based access controls to be the 
ultimate. Rather, there are duals for all of the above that induce 
circumstances where label-based systems are superior. Each class of 
system has strengths and weaknesses. These are name-based strengths.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
The Olympic Games: Symbolizing oppression and corruption for over a hundred years

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Stephen Smalley]

On Sun, 2008-04-13 at 19:05 -0700, Crispin Cowan wrote:
> Serge E. Hallyn wrote:
> > Quoting Matthew Wilcox (matthew@wil.cx):
> >   
> >> On Fri, Apr 11, 2008 at 11:12:27PM +0900, Tetsuo Handa wrote:
> >>     
> >>> Matthew Wilcox wrote:
> >>>       
> >>>> When the rule is put in place, say "No modifications to /etc/passwd",
> >>>> look up the inode and major:minor of /etc/passwd.  If there's a rename,
> >>>> look up the new inode number.  If it's mounted elsewhere, it doesn't
> >>>> matter, they still can't modify it because it has the same
> >>>> major:minor:inode.
> >>>>         
> >>> If write access is denied because of a rule "No modifications to /etc/passwd",
> >>> a rule "Allow modifications to /tmp/passwd" can no longer be enforced after
> >>> "mount --bind /etc/ /tmp/" or "mount --bind /etc/passwd /tmp/passwd" or
> >>> "mv /etc/passwd /tmp/passwd" or "ln /etc/passwd /tmp/passwd" is done.
> >>>       
> >> That's a fundamental limitation of pathname-based security though.
> >> If the same file exists in two places, you have to resolve the question
> >> of which rule overrides the other.
> >>     
> > In the past, Crispin has given clear, concise explanations of a few of
> > the things pathname based access control in fact excels at.  Crispin,
> > can you recite those again so we can think constructively about which
> > (if any) of the currently considered options are or are not sufficient?
> >
> > I.e. what would be a motivation for a rule like 'no modifications to
> > /etc/passwd', and what precisely would and would not be accepted ways to
> > get around it (and why)?
> >   
> As I just posted, a rule of "no mods to /some/pathname" is broken, which 
> is why AppArmor has no such construct.
> 
> Things that pathname-based access control is good at:
> 
>     * *System Integrity:* Many of the vital components of a UNIX system
>       are stored in files with Well Known Names such as /etc/shadow,
>       /var/www/htdocs/index.html and /home/crispin/.ssh/known_hosts. The
>       contents of the actual data blocks is less important than the
>       integrity of what some random process gets when it asks for these
>       resources by name. Preserving the integrity of what responds to
>       the Well Known Name is thus easier if you restrict access based on
>       the name.

I think some might argue that the integrity of the data in /etc/shadow
and your .ssh files is very important, not just their names.  And as
names are themselves just data contained by directories, the integrity
of the names is a particular case of the data integrity problem.  And
ultimately data integrity requires information flow control to preserve.

>     * *Dynamic Access Control:* A special case of the above pertains to
>       files that may or may not exist. If you don't *have* a /etc/hosts
>       file, it is still important to have a rule that controls whether
>       it can be created. This is hard to do in label-based systems,
>       because the file does not exist to put a label on, so you have to
>       kludge it by either creating the file with zero length and
>       labeling it, or by creating more complex policy for the parent
>       /etc directory, and that's hard given the number of uses for /etc
>       such as /etc/motd. In a name based scheme, you simply don't
>       provide write permission to "/etc/hosts" unless you mean it, and
>       it can be enforced even if such a file does not exist.

I'd view this as another example of practical or legacy concerns, as it
wouldn't pose a problem if either of the following were true:
- /etc was further partitioned into multiple subdirectories (seemingly
true in an increasing number of cases, so we seem to be moving in that
direction regardless) so that inheritance from parent directory would
suffice, or
- specific programs were used to create or update the individual files
(true for some of the files in /etc, and generally helpful for ensuring
proper data formatting and applying basic sanity checks on the content)
so that the files created by them could be labeled based on the creating
domain or via appropriate instrumentation of the programs to set the
attributes (the latter is not fundamentally different than the situation
for DAC ownership/mode or ACLs).

Also, note that in the case of SELinux, we do have a solution to the
above situation, namely restorecond, which leverages the kernel's
inotify mechanism.

As an example where the name-based schemes have difficulties with
"dynamic" data, files created at runtime in /tmp and other shared
directories often have security-irrelevant names, yet protecting them
from tampering by others can be very relevant to security.  There the
attribute-based schemes have the advantage.

>     * *Ad Hoc Generalization:* Label-based access control generalizes
>       policy in that the policy treats all files and resources that
>       share a label the same. If you want to make a new generalization
>       that encompasses *part* of the files that share a label, but *not
>       all* of those files, then you have to "split the label", relabel
>       the file system, and revise the policy accordingly. Name-based
>       access control lets you create ad hoc generalizations, so that
>       *my* policy can grant access to "/var/www/*.pl" without regard to
>       whatever labels or rules some other policy has applied to the same
>       directory tree.

We might argue about whether ad hoc policy writing is the best approach.
Regardless, the corresponding weakness here for the path-based schemes
is that they force you into writing policy in terms of the filesystem
layout and names, which may have little or no bearing on the actual
security characteristics of the files.

>     * *Familiar Interface:* Administrators are accustomed to
>       administering the box in terms of the names of the files that
>       matter. A name-based policy is therefore somewhat more familiar
>       than a policy with label abstractions, where they then have to go
>       look at the restorecon file to discover what files will/should
>       have what labels.

restorecon /path/to/file doesn't require the user to deal with anything
other than a pathname.  The file contexts configuration is entirely
hidden from the user by that interface.

>     * *Practical Concerns:* Not all file systems support labels, and so
>       label-based schemes become coarse grained when they run into them.
>       Name based schemes remain granular when specifying access down
>       into the internals of such file systems. Legacy Linux file systems
>       like ext2 don't matter much any more, but persistent file systems
>       that will never have label support include NFSv3 file systems
>       (nearly every Network Appliance NAS server out there) and FAT32
>       file system (most every USB storage device).

At present this is a limitation, although we do support per-mount
labeling of such filesystems, which is really all we can guarantee in
terms of protection anyway - anything further is misleading as the
server or device won't ensure any finer grained separation for us.  But
labeled NFS support is in progress, and one should never let legacy code
cripple one's approach.  Making compatibility allowances for legacy code
is quite reasonable, and is precisely what we do in terms of supporting
default type transitions, per-mount labels, etc, but that isn't the same
thing as completely constraining your design to only what is supported
by existing code.

> A lot of what's going on is the duality of the one:many relationships 
> between labels and names:
> 
>     * Labels: one label represents many files
>           o this property is why ad hoc generalization fails in label
>             based systems
>     * Names: many names can represent a single file
>           o This property is why deny rules fail in name based systems
> 
> Therefore, I am not claiming name-based access controls to be the 
> ultimate. Rather, there are duals for all of the above that induce 
> circumstances where label-based systems are superior. Each class of 
> system has strengths and weaknesses. These are name-based strengths.

The weaknesses from my POV are:
- no system-wide view of the subjects and objects and thus of the
policy,
- no uniform abstraction for handling objects (not everything has a
pathname), leading to inconsistent or incomplete control,
- no useful information for runtime objects,
- forcing policy to be written in terms of individual objects and
filesystem layout rather than security properties.

-- 
Stephen Smalley
National Security Agency

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> 
> ...
> 
> I think some might argue that the integrity of the data in /etc/shadow
> and your .ssh files is very important, not just their names.

I believe that the key word here is "just". If you go back to
the Orange Book you will see that the combination of the object
and the name by which it is referenced is important. The audit
requirements are most interesting, as they make it clear that
without a relevant name associated with the object an audit
record has no value.

The Orange Book Unix evaluations raised enormous issues regarding
the file system name space. I know that at least two vendors
stated that the name of the object was its device/inode pair and
that the pathname stuff was there strictly for user convenience
and was not security relevent. This is of course hogwash, but
was logically consistant in the context of security policy
documentation. These same vendors had to then make completely
distinct arguments about their audit systems in order to meet
the name identification requirements there.

The question of protections on the object named /etc/passwd came
up time and time again. The notion that /etc/passwd could be a
symlink to /home/smalley/heeheehee really gave evaluators the
whillies. As did the chroot environment, where /roots/crispin/etc/passwd
could magicly become /etc/passwd. One reason that the object
access model is so firmly ingrained is that it allows the
security documentation to wave it's paw and say "bah" when
these questions arise.

> And as
> names are themselves just data contained by directories, the integrity
> of the names is a particular case of the data integrity problem.  And
> ultimately data integrity requires information flow control to preserve.

Good example of my point. The argument is true, and the implications
important, but the conclusion is not satisfactory.

> >     * *Dynamic Access Control:* A special case of the above pertains to
> >       files that may or may not exist. If you don't *have* a /etc/hosts
> >       file, it is still important to have a rule that controls whether
> >       it can be created. This is hard to do in label-based systems,
> >       because the file does not exist to put a label on, so you have to
> >       kludge it by either creating the file with zero length and
> >       labeling it, or by creating more complex policy for the parent
> >       /etc directory, and that's hard given the number of uses for /etc
> >       such as /etc/motd. In a name based scheme, you simply don't
> >       provide write permission to "/etc/hosts" unless you mean it, and
> >       it can be enforced even if such a file does not exist.
> 
> I'd view this as another example of practical or legacy concerns, as it
> wouldn't pose a problem if either of the following were true:
> - /etc was further partitioned into multiple subdirectories (seemingly
> true in an increasing number of cases, so we seem to be moving in that
> direction regardless) so that inheritance from parent directory would
> suffice, or
> - specific programs were used to create or update the individual files
> (true for some of the files in /etc, and generally helpful for ensuring
> proper data formatting and applying basic sanity checks on the content)
> so that the files created by them could be labeled based on the creating
> domain or via appropriate instrumentation of the programs to set the
> attributes (the latter is not fundamentally different than the situation
> for DAC ownership/mode or ACLs).

Yes, a proper design of the administrative data and interfaces
would solve the problem of /etc/passwd right quick. It would not
address the general issue which is assuring that access is controlled
based on the names that people use.

> Also, note that in the case of SELinux, we do have a solution to the
> above situation, namely restorecond, which leverages the kernel's
> inotify mechanism.

Well, I don't see that addressing the case where /etc/passwd is
a symlink unless restorecond is more sophisticated than I understand
it to be (correct me if I'm wrong) and I certainly can't see it
being used on every file on a multiple pedabyte filesystem.

> As an example where the name-based schemes have difficulties with
> "dynamic" data, files created at runtime in /tmp and other shared
> directories often have security-irrelevant names, yet protecting them
> from tampering by others can be very relevant to security.  There the
> attribute-based schemes have the advantage.

Very true.
 
> ...

> The weaknesses from my POV are:
> - no system-wide view of the subjects and objects and thus of the
> policy,
> - no uniform abstraction for handling objects (not everything has a
> pathname), leading to inconsistent or incomplete control,
> - no useful information for runtime objects,
> - forcing policy to be written in terms of individual objects and
> filesystem layout rather than security properties.

These are all legitimate concerns, but it is really hard to say
that they outweigh the value of controlling access to /etc/passwd
by specifying that you want to control access to /etc/passwd.
The real problem lies in the perfectly reasonable but nontheless
untrue assumptions that users, administrators, and developers
make about the relationship between names and objects on *ix
filesystems. The object model is more correct, and the dickins
easier to write kernel code for I might add. The problem is that
the object model is not what is exposed by the syscall interface,
it's the filesystem namespace. I have oft considered an OS (casex?)
that exposes the device/inode pair and leaves all the pathname
stuff to application space, but I doubt it would be popular
because the namespace is riddled with handy features.

We could fix the filesystem namespace, and then the issue would
evaporate, but I think too many people would think it was fixed
in the veterenary sense.


Casey Schaufler
casey@schaufler-ca.com

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Tetsuo Handa]

Casey Schaufler wrote:
> The question of protections on the object named /etc/passwd came
> up time and time again. The notion that /etc/passwd could be a
> symlink to /home/smalley/heeheehee really gave evaluators the
> whillies. As did the chroot environment, where /roots/crispin/etc/passwd
> could magicly become /etc/passwd.
Why do people continue speaking symlinks and chroots?
To avoid the effect of symlinks and chroots, AppArmor and TOMOYO Linux
derive pathnames from dentry and vfsmount.
If /etc/passwd was a symlink, the derived pathname will be /home/smalley/heeheehee.
If accessed from inside a chroot, the derived pathname will be /roots/crispin/etc/passwd.

It is true that namespace may differ between processes,
but I think that that is the matter of how to restrict namespace manipulation operations.
As I said, a system can't survive if namespace is madly manipulated.
To keep the system workable, /bin/ must be the directory for binary programs,
/etc/ must be the directory for configuration files, and so on in all namespaces.

It is true that the pathname may change while traversing up the dentry/vfsmount trees.
But the change does not occur infinitely.
As I said, a system can't survive if files and directories are madly renamed.
The possible changes are bounded by the policy.

At least, I want people not to speak symlinks and chroots when talking about
AppArmor and TOMOYO Linux.

Regards.

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Casey Schaufler]

--- Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:

> Casey Schaufler wrote:
> > The question of protections on the object named /etc/passwd came
> > up time and time again. The notion that /etc/passwd could be a
> > symlink to /home/smalley/heeheehee really gave evaluators the
> > whillies. As did the chroot environment, where /roots/crispin/etc/passwd
> > could magicly become /etc/passwd.
>
> Why do people continue speaking symlinks and chroots?

Because on any given Linux system you could have an arbitrarily
large number of different things that might be accessed by the
name "/etc/passwd" and a different, but similarly large number
of names other than "/etc/passwd" that can be used to access them.

> To avoid the effect of symlinks and chroots, AppArmor and TOMOYO Linux
> derive pathnames from dentry and vfsmount.
> If /etc/passwd was a symlink, the derived pathname will be
> /home/smalley/heeheehee.
> If accessed from inside a chroot, the derived pathname will be
> /roots/crispin/etc/passwd.

Which doesn't hold up under hard links, which I had carefully
avoided and that both AppArmor and TOMOYO Linux have to place
restrictions on for the systems to make sense.

> It is true that namespace may differ between processes,
> but I think that that is the matter of how to restrict namespace manipulation
> operations.
> As I said, a system can't survive if namespace is madly manipulated.

That's hardly the viewpoint of those who would have every
user mount their own version of /tmp.

> To keep the system workable, /bin/ must be the directory for binary programs,
> /etc/ must be the directory for configuration files, and so on in all
> namespaces.

Only for general purpose shell access. General purpose shell access
is decreasing in popularity.

> It is true that the pathname may change while traversing up the
> dentry/vfsmount trees.
> But the change does not occur infinitely.
> As I said, a system can't survive if files and directories are madly renamed.
> The possible changes are bounded by the policy.
> 
> At least, I want people not to speak symlinks and chroots when talking about
> AppArmor and TOMOYO Linux.

The issues with links, symlinks, chroots and mounts in the
context of a name based access control scheme will always
need to be addressed, just as the issues of unlabeled filesystems
and /tmp will have to be in label based scheme.


Casey Schaufler
casey@schaufler-ca.com

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Crispin Cowan]

Casey Schaufler wrote:
> --- Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote
>> Casey Schaufler wrote:
>>     
>>> The question of protections on the object named /etc/passwd came
>>> up time and time again. The notion that /etc/passwd could be a
>>> symlink to /home/smalley/heeheehee really gave evaluators the
>>> whillies. As did the chroot environment, where /roots/crispin/etc/passwd
>>> could magicly become /etc/passwd.
>>>       
>> Why do people continue speaking symlinks and chroots?
>>     
> Because on any given Linux system you could have an arbitrarily
> large number of different things that might be accessed by the
> name "/etc/passwd" and a different, but similarly large number
> of names other than "/etc/passwd" that can be used to access them.
>   
But that's not quite true.

"/etc/passwd" can indeed point anywhere, but it can only point to a 
single place at a time. I've alluded to this several times in pointing 
out that labels and names have dualistic many:one and one:many 
relationships to actual files.

This is Tetsuo's point: if you symlink or chroot /etc/shadow to point 
some place strange, then the redirection will be resolved *before* 
AppArmor and TOMOYO consider the security question of whether access 
should be allowed. Therefore, the fact that you re-directed it is 
irrelevant to security.

>> To avoid the effect of symlinks and chroots, AppArmor and TOMOYO Linux
>> derive pathnames from dentry and vfsmount.
>> If /etc/passwd was a symlink, the derived pathname will be
>> /home/smalley/heeheehee.
>> If accessed from inside a chroot, the derived pathname will be
>> /roots/crispin/etc/passwd.
>>     
> Which doesn't hold up under hard links, which I had carefully
> avoided and that both AppArmor and TOMOYO Linux have to place
> restrictions on for the systems to make sense.
>   
Hard links are indeed handled differently, but they are handled. I don't 
know what TOMOYO does. What AppArmor does is exploit the fact that you 
cannot hard link a directory, so the target of a hard link must be a 
file. From there, we can use the    dentry to disambiguate which file. 
So again, even though more than one name points to the inode, the name 
that was actually  used to get to this inode is unique, and we recover 
it and then consider the security question of whether you get to access 
that name.

>> It is true that namespace may differ between processes,
>> but I think that that is the matter of how to restrict namespace manipulation
>> operations.
>> As I said, a system can't survive if namespace is madly manipulated.
>>     
> That's hardly the viewpoint of those who would have every
> user mount their own version of /tmp.
>   
Well, AppArmor and TOMOYO don't do well if the namespace is madly 
manipulated. They remain secure, because they prohibit name space 
manipulations by confined processes. If what you wanted to do was lots 
of  name space manipulations, it makes (at least AppArmor) a poor choice 
for you.

>> It is true that the pathname may change while traversing up the
>> dentry/vfsmount trees.
>> But the change does not occur infinitely.
>> As I said, a system can't survive if files and directories are madly renamed.
>> The possible changes are bounded by the policy.
>>
>> At least, I want people not to speak symlinks and chroots when talking about
>> AppArmor and TOMOYO Linux.
>>     
> The issues with links, symlinks, chroots and mounts in the
> context of a name based access control scheme will always
> need to be addressed, just as the issues of unlabeled filesystems
> and /tmp will have to be in label based scheme.
>   
Agreed. Duality abounds in this space.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
The Olympic Games: Symbolizing oppressiiion and corruption for over a
hundred years

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Pavel Machek]

Hi!

> > The question of protections on the object named /etc/passwd came
> > up time and time again. The notion that /etc/passwd could be a
> > symlink to /home/smalley/heeheehee really gave evaluators the
> > whillies. As did the chroot environment, where /roots/crispin/etc/passwd
> > could magicly become /etc/passwd.
> Why do people continue speaking symlinks and chroots?
> To avoid the effect of symlinks and chroots, AppArmor and TOMOYO Linux
> derive pathnames from dentry and vfsmount.
> If /etc/passwd was a symlink, the derived pathname will be /home/smalley/heeheehee.
> If accessed from inside a chroot, the derived pathname will be /roots/crispin/etc/passwd.
> 
> It is true that namespace may differ between processes,
> but I think that that is the matter of how to restrict namespace manipulation operations.
> As I said, a system can't survive if namespace is madly manipulated.
> To keep the system workable, /bin/ must be the directory for binary programs,
> /etc/ must be the directory for configuration files, and so on in all namespaces.

Ehm? Where did you get those ideas?

I'm free to name my directories any way I want, and keep config files
in /pavlix_config, thank you... There is even distro that does
something like that, IIRC...

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Tetsuo Handa]

Pavel Machek wrote:
> > It is true that namespace may differ between processes,
> > but I think that that is the matter of how to restrict namespace manipulation operations.
> > As I said, a system can't survive if namespace is madly manipulated.
> > To keep the system workable, /bin/ must be the directory for binary programs,
> > /etc/ must be the directory for configuration files, and so on in all namespaces.
> 
> Ehm? Where did you get those ideas?
> 
> I'm free to name my directories any way I want, and keep config files
> in /pavlix_config, thank you... There is even distro that does
> something like that, IIRC...
> 
We can make processes have different namespace by using clone() with CLONE_NEWNS.
But even if some process got a different namespace, it need to follow conventional rules.
Optional files (e.g. /pavlix_config) need not to follow conventional rules.
What I'm talking about is essetial files (e.g. /bin/sh and /etc/passwd).
Can your system continue running even if essetial files are not in place
(like /bin/sh moved to /etc/sh and /etc/passwd moved to /bin/passwd) ?
I don't think so...

Thanks.

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Pavel Machek]

> 
> Pavel Machek wrote:
> > > It is true that namespace may differ between processes,
> > > but I think that that is the matter of how to restrict namespace manipulation operations.
> > > As I said, a system can't survive if namespace is madly manipulated.
> > > To keep the system workable, /bin/ must be the directory for binary programs,
> > > /etc/ must be the directory for configuration files, and so on in all namespaces.
> > 
> > Ehm? Where did you get those ideas?
> > 
> > I'm free to name my directories any way I want, and keep config files
> > in /pavlix_config, thank you... There is even distro that does
> > something like that, IIRC...
> > 
> We can make processes have different namespace by using clone() with CLONE_NEWNS.
> But even if some process got a different namespace, it need to follow conventional rules.
> Optional files (e.g. /pavlix_config) need not to follow conventional rules.
> What I'm talking about is essetial files (e.g. /bin/sh and
> /etc/passwd).

Why would I need to follow rules?

> Can your system continue running even if essetial files are not in place
> (like /bin/sh moved to /etc/sh and /etc/passwd moved to /bin/passwd) ?

Why not? They are just a names, they can be changed as log as you
change them everywhere. Which is rather easy for small
systems... think openembedded.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Serge E. Hallyn]

Quoting Pavel Machek (pavel@ucw.cz):
> > 
> > Pavel Machek wrote:
> > > > It is true that namespace may differ between processes,
> > > > but I think that that is the matter of how to restrict namespace manipulation operations.
> > > > As I said, a system can't survive if namespace is madly manipulated.
> > > > To keep the system workable, /bin/ must be the directory for binary programs,
> > > > /etc/ must be the directory for configuration files, and so on in all namespaces.
> > > 
> > > Ehm? Where did you get those ideas?
> > > 
> > > I'm free to name my directories any way I want, and keep config files
> > > in /pavlix_config, thank you... There is even distro that does
> > > something like that, IIRC...
> > > 
> > We can make processes have different namespace by using clone() with CLONE_NEWNS.
> > But even if some process got a different namespace, it need to follow conventional rules.
> > Optional files (e.g. /pavlix_config) need not to follow conventional rules.
> > What I'm talking about is essetial files (e.g. /bin/sh and
> > /etc/passwd).
> 
> Why would I need to follow rules?
> 
> > Can your system continue running even if essetial files are not in place
> > (like /bin/sh moved to /etc/sh and /etc/passwd moved to /bin/passwd) ?
> 
> Why not? They are just a names, they can be changed as log as you
> change them everywhere. Which is rather easy for small
> systems... think openembedded.
> 									Pavel

This is getting silly - if you change them "everywhere" then you can
change them in your security profiles too :)

Anyway this thread has degenerated again.

Crispin, thanks for posting those use cases.

Now the next step IMO is for someone (Tetsuo?) to take one of those use
cases and run through each of the four (was it 4?) proposed methods for
handling the pathnames.  One paragraph describing how the use case in
general would be handled, then a list of shortcomings for the solution.

-serge

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Crispin Cowan]

Stephen Smalley wrote:
> On Sun, 2008-04-13 at 19:05 -0700, Crispin Cowan wrote:
>   
>> Things that pathname-based access control is good at:
>>
>>     * *System Integrity:* Many of the vital components of a UNIX system
>>       are stored in files with Well Known Names such as /etc/shadow,
>>       /var/www/htdocs/index.html and /home/crispin/.ssh/known_hosts. The
>>       contents of the actual data blocks is less important than the
>>       integrity of what some random process gets when it asks for these
>>       resources by name. Preserving the integrity of what responds to
>>       the Well Known Name is thus easier if you restrict access based on
>>       the name.
>>     
> I think some might argue that the integrity of the data in /etc/shadow
> and your .ssh files is very important, not just their names.
I understand how the confidentiality of secrets like the contents of 
/etc/shadow and your .ssh files is important, but how can the integrity 
of these data objects be important? Back them up if you care ...

>   And as
> names are themselves just data contained by directories, the integrity
> of the names is a particular case of the data integrity problem.
That's just access control for the containing directory, and/or access 
control to the raw partition, which is also  controlled by name-based 
access control to /dev

>   And
> ultimately data integrity requires information flow control to preserve.
>   
You've argued that before, and I've never been convinced. Rather, it 
looked a lot like a stretched definition trying really hard to turn 
integrity into an information flow problem.The most information flow 
that I will buy in the integrity problem is taint analysis of software 
inputs; that software should validate inputs before acting on it.

>>     * *Dynamic Access Control:* A special case of the above pertains to
>>       files that may or may not exist. If you don't *have* a /etc/hosts
>>       file, it is still important to have a rule that controls whether
>>       it can be created. This is hard to do in label-based systems,
>>       because the file does not exist to put a label on, so you have to
>>       kludge it by either creating the file with zero length and
>>       labeling it, or by creating more complex policy for the parent
>>       /etc directory, and that's hard given the number of uses for /etc
>>       such as /etc/motd. In a name based scheme, you simply don't
>>       provide write permission to "/etc/hosts" unless you mean it, and
>>       it can be enforced even if such a file does not exist.
>>     
> I'd view this as another example of practical or legacy concerns, as it
> wouldn't pose a problem if either of the following were true:
> - /etc was further partitioned into multiple subdirectories (seemingly
> true in an increasing number of cases, so we seem to be moving in that
> direction regardless) so that inheritance from parent directory would
> suffice, or
>   
If you want to move this particular benefit to the "practical" bucket, I 
have no issue with that. It is a core part of the name-based argument 
that it is a practical solution for system administrators who     
experience the system through names.

> - specific programs were used to create or update the individual files
> (true for some of the files in /etc, and generally helpful for ensuring
> proper data formatting and applying basic sanity checks on the content)
> so that the files created by them could be labeled based on the creating
> domain or via appropriate instrumentation of the programs to set the
> attributes (the latter is not fundamentally different than the situation
> for DAC ownership/mode or ACLs).
>   
Security architecture for a clean&pure architecture are an interesting 
problem, but certainly are not the LSM problem.

> Also, note that in the case of SELinux, we do have a solution to the
> above situation, namely restorecond, which leverages the kernel's
> inotify mechanism.
>   
IMHO that is a slow and racy solution. If one applied the kind of 
standards that AppArmor is being asked to pass to restorecond, it would 
have a tough time too.

> As an example where the name-based schemes have difficulties with
> "dynamic" data, files created at runtime in /tmp and other shared
> directories often have security-irrelevant names,
Presumably you mean that the name is not meaningfully predictable with 
respect tot he application. Yes, sometimes this is a problem, and 
AppArmor doesn't presently deal with it well.

>  yet protecting them
> from tampering by others can be very relevant to security.  There the
> attribute-based schemes have the advantage.
>   
John Johansen has some designs he has been working on to let an AA 
profile require a UID match as well as a name match. To the extent that 
file ownership is a kind of label, this is a small step towards a hybrid 
model that leverages the strengths of both name and label based access 
controls.

>>     * *Ad Hoc Generalization:* Label-based access control generalizes
>>       policy in that the policy treats all files and resources that
>>       share a label the same. If you want to make a new generalization
>>       that encompasses *part* of the files that share a label, but *not
>>       all* of those files, then you have to "split the label", relabel
>>       the file system, and revise the policy accordingly. Name-based
>>       access control lets you create ad hoc generalizations, so that
>>       *my* policy can grant access to "/var/www/*.pl" without regard to
>>       whatever labels or rules some other policy has applied to the same
>>       directory tree.
>>     
> We might argue about whether ad hoc policy writing is the best approach.
>   
Another way of saying "ad hoc policy writing" is "incremental policy 
development."

If you can anticipate everything you need in your data center and get it 
right ahead of time, then you don't need ad hoc policy. If circumstances 
change on you and you need to adapt, then your policy is necessarily ad hoc.

> Regardless, the corresponding weakness here for the path-based schemes
> is that they force you into writing policy in terms of the filesystem
> layout and names, which may have little or no bearing on the actual
> security characteristics of the files.
>   
I assert that the pathname has a strong correspondence to the integrity 
sensitivity of the file, and a weaker correspondence to the 
confidentiality sensitivity of the file, e.g. a backup copy of your 
actual /etc/shadow file is still sensitive if it gets disclosed to 
someone intent on password cracking.

This is not a severe problem for AppArmor in practice because of the 
default-deny nature of the policy: only grant read access to the files 
you intend to allow to be read. It is fairly difficult to accidentally 
disclose a file in an AppArmor policy unless you engage in really sloppy 
practice like dropping copies of sensitive files in publicly readable 
places like /tmp

>>     * *Familiar Interface:* Administrators are accustomed to
>>       administering the box in terms of the names of the files that
>>       matter. A name-based policy is therefore somewhat more familiar
>>       than a policy with label abstractions, where they then have to go
>>       look at the restorecon file to discover what files will/should
>>       have what labels.
>>     
> restorecon /path/to/file doesn't require the user to deal with anything
> other than a pathname.
Yes it does. To understand your security policy, you have to understand 
both the SELinux policy about labels & types and which are allowed to 
access each other, and also the restorecon specification that determines 
what labels will be applied to which files.

>>     * *Practical Concerns:* Not all file systems support labels, and so
>>       label-based schemes become coarse grained when they run into them.
>>       Name based schemes remain granular when specifying access down
>>       into the internals of such file systems. Legacy Linux file systems
>>       like ext2 don't matter much any more, but persistent file systems
>>       that will never have label support include NFSv3 file systems
>>       (nearly every Network Appliance NAS server out there) and FAT32
>>       file system (most every USB storage device).
>>     
> At present this is a limitation, although we do support per-mount
> labeling of such filesystems, which is really all we can guarantee in
> terms of protection anyway
That's what I meant by granular: you get access to the whole NFS mount, 
or none of it.

>  - anything further is misleading as the
> server or device won't ensure any finer grained separation for us.
I don't understand this issue. The enforcement here is t contain the 
program executing on the NFS *client* to permit it to only mangle the 
parts of the NFS mount that you want it to mangle. That the server won't 
enforce anything for you is irrelevant when the threat is the confined 
application.

>> A lot of what's going on is the duality of the one:many relationships 
>> between labels and names:
>>
>>     * Labels: one label represents many files
>>           o this property is why ad hoc generalization fails in label
>>             based systems
>>     * Names: many names can represent a single file
>>           o This property is why deny rules fail in name based systems
>>
>> Therefore, I am not claiming name-based access controls to be the 
>> ultimate. Rather, there are duals for all of the above that induce 
>> circumstances where label-based systems are superior. Each class of 
>> system has strengths and weaknesses. These are name-based strengths.
>>     
>
> The weaknesses from my POV are:
> - no system-wide view of the subjects and objects and thus of the
> policy,
>   
... and no *requirement* to construct a system-wide consistent view of 
security policy.

> - no uniform abstraction for handling objects (not everything has a
> pathname), leading to inconsistent or incomplete control,
>   
*Strawman* argument: AppArmor doesn't try to apply pathnames to 
everything, just the file system. The "uniform abstraction" is to 
specify security policy in the native terms of the resource being 
mediated. Files are named as /path/to/some/files/*.html and network 
resources are named in terms of ports and network addresses reminiscent 
of firewall rules.

In contrast, SELinux *does* apply the labeled model to everything. That 
has the strength that you are dealing with the same abstraction all the 
time, and the weakness that the mapping from the label abstraction to 
the stuff that admins and users have to actually deal with is arcane.

> - forcing policy to be written in terms of individual objects and
> filesystem layout rather than security properties.
>   
Name-based access control makes the overt assumption that the name of an 
object corresponds to its security properties. If your data layout does 
*not* make such an assumption, then you have some very strange data 
layout putting highly sensitive objects next to non-sensitive objects.

Note also that the SELinux restorecon mechanism also makes the 
assumption that path names correspond to security properties: in fact, 
that is precisely its function, to take a path name and use it to apply 
a security property (a label). Naturally I have no objection to 
inferring a security property from the path name :) I just object to the 
racy way that restorecon does it, combined with the complaint that 
AppArmor is wrong for doing exactly the same thing in a different way.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
The Olympic Games: Symbolizing oppression and corruption for over a
hundred years

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Stephen Smalley]

On Mon, 2008-04-14 at 21:59 -0700, Crispin Cowan wrote:
> Stephen Smalley wrote:
> > On Sun, 2008-04-13 at 19:05 -0700, Crispin Cowan wrote:
> >   
> >> Things that pathname-based access control is good at:
> >>
> >>     * *System Integrity:* Many of the vital components of a UNIX system
> >>       are stored in files with Well Known Names such as /etc/shadow,
> >>       /var/www/htdocs/index.html and /home/crispin/.ssh/known_hosts. The
> >>       contents of the actual data blocks is less important than the
> >>       integrity of what some random process gets when it asks for these
> >>       resources by name. Preserving the integrity of what responds to
> >>       the Well Known Name is thus easier if you restrict access based on
> >>       the name.
> >>     
> > I think some might argue that the integrity of the data in /etc/shadow
> > and your .ssh files is very important, not just their names.
> I understand how the confidentiality of secrets like the contents of 
> /etc/shadow and your .ssh files is important, but how can the integrity 
> of these data objects be important? Back them up if you care ...

If you aren't concerned with unauthorized data flow into
your /etc/shadow and .ssh files, then I think we'll just have to stop
right there in our discussion, as we evidently don't have a common point
of reference in what we mean by "security".  Personally I'd be troubled
if an unauthorized entity can ultimately feed data to such files, even
if indirectly by tricking a privileged process into conveying the data
to its ultimate target, a not-so-uncommon pattern.

> >   And as
> > names are themselves just data contained by directories, the integrity
> > of the names is a particular case of the data integrity problem.
> That's just access control for the containing directory, and/or access 
> control to the raw partition, which is also  controlled by name-based 
> access control to /dev
> 
> >   And
> > ultimately data integrity requires information flow control to preserve.
> >   
> You've argued that before, and I've never been convinced. Rather, it 
> looked a lot like a stretched definition trying really hard to turn 
> integrity into an information flow problem.The most information flow 
> that I will buy in the integrity problem is taint analysis of software 
> inputs; that software should validate inputs before acting on it.

In some cases, you can simply prohibit a security-relevant process from
taking untrustworthy inputs.  Like blocking privileged processes from
following untrustworthy symlinks to counter malicious symlink attacks or
from reading any files other than ones created by the admin.  In other
cases, you need to allow untrustworthy inputs to ultimately flow to the
security-relevant process, but you want to force them through some kind
of validation as you say above, which you can do by enforcing a
processing pipeline that forces the data to go through a subsystem that
performs validation and/or sanitization before it ever reaches the
security-relevant process.  That's how integrity is an information flow
problem.  And this isn't a new idea, btw, it is one that was expressed
long ago in the Biba model, a variant of which happens to be implemented
and used in Vista, and is more usefully achievable via Type Enforcement
since there we can control the processing flow precisely and bind the
validation/sanitization subsystem to specific code.

> >  - anything further is misleading as the
> > server or device won't ensure any finer grained separation for us.
> I don't understand this issue. The enforcement here is t contain the 
> program executing on the NFS *client* to permit it to only mangle the 
> parts of the NFS mount that you want it to mangle. That the server won't 
> enforce anything for you is irrelevant when the threat is the confined 
> application.

Except that you have to consider what is happening on the server too,
given that the files are visible to local processes there, and what
happens on all of the clients.  And the aliasing problem that exists in
the local filesystem case becomes exacerbated in the NFS environment.

> > - no uniform abstraction for handling objects (not everything has a
> > pathname), leading to inconsistent or incomplete control,
> >   
> *Strawman* argument: AppArmor doesn't try to apply pathnames to 
> everything, just the file system. The "uniform abstraction" is to 
> specify security policy in the native terms of the resource being 
> mediated. Files are named as /path/to/some/files/*.html and network 
> resources are named in terms of ports and network addresses reminiscent 
> of firewall rules.
> 
> In contrast, SELinux *does* apply the labeled model to everything. That 
> has the strength that you are dealing with the same abstraction all the 
> time, and the weakness that the mapping from the label abstraction to 
> the stuff that admins and users have to actually deal with is arcane.

It isn't a strawman argument.  I know that AppArmor doesn't try to apply
pathnames to non-files.  Which leads it down the first case of
inconsistent" control - at the end of the day in looking at an AppArmor
policy you can't say anything about how information may have ultimately
flowed in violation of your confidentiality or integrity goals because
you have a lossy abstraction.  Whereas we can convey the same uniform
control over files, network IPC, local IPC, etc and make such
statements.

> > - forcing policy to be written in terms of individual objects and
> > filesystem layout rather than security properties.
> >   
> Name-based access control makes the overt assumption that the name of an 
> object corresponds to its security properties. If your data layout does 
> *not* make such an assumption, then you have some very strange data 
> layout putting highly sensitive objects next to non-sensitive objects.
> 
> Note also that the SELinux restorecon mechanism also makes the 
> assumption that path names correspond to security properties: in fact, 
> that is precisely its function, to take a path name and use it to apply 
> a security property (a label). Naturally I have no objection to 
> inferring a security property from the path name :) I just object to the 
> racy way that restorecon does it, combined with the complaint that 
> AppArmor is wrong for doing exactly the same thing in a different way.

Making that inference when a file is first installed (as from rpm) is
reasonable.  restorecon (the utility) is for the filesystem to the
initial install-time labeling state, which is why it uses the same
mapping.  Making that inference on every access in complete ignorance of
the actual runtime state of the system is what I object to.

-- 
Stephen Smalley
National Security Agency

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Crispin Cowan]

Stephen Smalley wrote:
> On Mon, 2008-04-14 at 21:59 -0700, Crispin Cowan wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> On Sun, 2008-04-13 at 19:05 -0700, Crispin Cowan wrote:  
>>>       
>>>> Things that pathname-based access control is good at:
>>>>
>>>>     * *System Integrity:* Many of the vital components of a UNIX system
>>>>       are stored in files with Well Known Names such as /etc/shadow,
>>>>       /var/www/htdocs/index.html and /home/crispin/.ssh/known_hosts. The
>>>>       contents of the actual data blocks is less important than the
>>>>       integrity of what some random process gets when it asks for these
>>>>       resources by name. Preserving the integrity of what responds to
>>>>       the Well Known Name is thus easier if you restrict access based on
>>>>       the name.
>>>>         
>>> I think some might argue that the integrity of the data in /etc/shadow
>>> and your .ssh files is very important, not just their names.
>>>       
>> I understand how the confidentiality of secrets like the contents of 
>> /etc/shadow and your .ssh files is important, but how can the integrity 
>> of these data objects be important? Back them up if you care ...
>>     
> If you aren't concerned with unauthorized data flow into
> your /etc/shadow and .ssh files, then I think we'll just have to stop
> right there in our discussion, as we evidently don't have a common point
> of reference in what we mean by "security".  Personally I'd be troubled
> if an unauthorized entity can ultimately feed data to such files, even
> if indirectly by tricking a privileged process into conveying the data
> to its ultimate target, a not-so-uncommon pattern.
>   
Of *course* AppArmor protects the integrity of /etc/shadow, and 
unauthorized parties are not permitted to feed data into that file 
unless explicit access is granted. The difference is in how it is done:

    * SELinux marks the inode with a label, and only processes with the
      right permissions can mess with the label.
          o Residual problem: someone could rename the inode and drop a
            new inode into place named "/etc/shadow". SELinux addresses
            this with access control on the parent directory.
    * AppArmor checks the name "/etc/shadow" so that you cannot access
      that name without explicit permission.
          o AppArmor cares about the integrity of what the OS returns
            when you access the name "/etc/shadow" and does not care a
            wit what happens to the inode that was *previously* named
            "/etc/shadow".

Now, without running off into the weeds again, tell me again why I 
should care about the *integrity* of an inode that was *previously* 
known as "/etc/shadow"?

>>>   And
>>> ultimately data integrity requires information flow control to preserve.
>>>   
>>>       
>> You've argued that before, and I've never been convinced. Rather, it 
>> looked a lot like a stretched definition trying really hard to turn 
>> integrity into an information flow problem.The most information flow 
>> that I will buy in the integrity problem is taint analysis of software 
>> inputs; that software should validate inputs before acting on it.
>>     
> In some cases, you can simply prohibit a security-relevant process from
> taking untrustworthy inputs.  Like blocking privileged processes from
> following untrustworthy symlinks to counter malicious symlink attacks or
> from reading any files other than ones created by the admin.  In other
> cases, you need to allow untrustworthy inputs to ultimately flow to the
> security-relevant process, but you want to force them through some kind
> of validation as you say above, which you can do by enforcing a
> processing pipeline that forces the data to go through a subsystem that
> performs validation and/or sanitization before it ever reaches the
> security-relevant process.  That's how integrity is an information flow
> problem.  And this isn't a new idea, btw, it is one that was expressed
> long ago in the Biba model, a variant of which happens to be implemented
> and used in Vista, and is more usefully achievable via Type Enforcement
> since there we can control the processing flow precisely and bind the
> validation/sanitization subsystem to specific code.
>   
Ok. I view the above as a marginal nice-to-have property that I don't 
actually care much about, because it is a large amount of work to manage 
for a small amount of integrity to gain. People who want that should use 
some kind of information flow controlling policy system like SELinux.

IMHO people with that need are a small minority, which is why I think it 
is over-strong to say that integrity "requires" information flow 
control. No it doesn't; the particular form of integrity you are talking 
about requires information flow control, but other forms do not.

>>>  - anything further is misleading as the
>>> server or device won't ensure any finer grained separation for us.
>>>       
>> I don't understand this issue. The enforcement here is t contain the 
>> program executing on the NFS *client* to permit it to only mangle the 
>> parts of the NFS mount that you want it to mangle. That the server won't 
>> enforce anything for you is irrelevant when the threat is the confined 
>> application.
>>     
> Except that you have to consider what is happening on the server too,
> given that the files are visible to local processes there, and what
> happens on all of the clients.
You don't have to consider any such thing when you are *only* concerned 
with confining the impact of the process running on the NFS client.

If you want to concern yourself with funny business coming from other 
clients, then you need to apply policy to those other clients. If you 
want to control funny business happening on the server, then you need to 
apply security policy to the server. But this is all irrelevant to 
secure confinement of the single NFS client process being confined.

> It isn't a strawman argument.  I know that AppArmor doesn't try to apply
> pathnames to non-files.  Which leads it down the first case of
> inconsistent" control - at the end of the day in looking at an AppArmor
> policy you can't say anything about how information may have ultimately
> flowed in violation of your confidentiality or integrity goals because
> you have a lossy abstraction.  Whereas we can convey the same uniform
> control over files, network IPC, local IPC, etc and make such
> statements.
>   
Conversely, at the end of the day you can't say much about what your 
SELinux policy enforces, because you can't understand it :)

Duality again: SELinux policy is easier for machines (semantic 
analyzers) to understand. AppArmor is easier for humans to understand.

>>> - forcing policy to be written in terms of individual objects and
>>> filesystem layout rather than security properties.  
>>>       
>> Note also that the SELinux restorecon mechanism also makes the 
>> assumption that path names correspond to security properties: in fact, 
>> that is precisely its function, to take a path name and use it to apply 
>> a security property (a label). Naturally I have no objection to 
>> inferring a security property from the path name :) I just object to the 
>> racy way that restorecon does it, combined with the complaint that 
>> AppArmor is wrong for doing exactly the same thing in a different way.
>>     
> Making that inference when a file is first installed (as from rpm) is
> reasonable.  restorecon (the utility) is for the filesystem to the
> initial install-time labeling state, which is why it uses the same
> mapping.  Making that inference on every access in complete ignorance of
> the actual runtime state of the system is what I object to.
>   
So associating a security property with a name is ok if you do it 
statically at some arbitrary point in time, but not if you consider it 
at the time of access? WtF? Isn't that a gigantic race condition?

To the contrary, I argue that the *current* name of a file is vastly 
more meaningful for security properties than the name the file had some 
months ago when someone ran restorecon over the file system.

I've said this before too: SELinux works well if your IT systems are 
static. AppArmor works better if your IT systems change, precisely 
because it evaluates the access based on the name at the time of access, 
rather than some historic name the file once had.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
The Olympic Games: Symbolizing oppressiiion and corruption for over a
hundred years

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Jamie Lokier]

Crispin Cowan wrote:
> Of *course* AppArmor protects the integrity of /etc/shadow, and 
> unauthorized parties are not permitted to feed data into that file 
> unless explicit access is granted. The difference is in how it is done:
> 
>    * SELinux marks the inode with a label, and only processes with the
>      right permissions can mess with the label.
>          o Residual problem: someone could rename the inode and drop a
>            new inode into place named "/etc/shadow". SELinux addresses
>            this with access control on the parent directory.

<small> I have actually hacked a system by renaming /etc/passwd in
this way.  /etc was owned by user "bin", and I had a login as "bin"
due to a misfeature in some program.  So I substituted another
/etc/passwd, and gave myself a root shell. </small>

The trouble with access control on the parent directory is that
occasionally some human accidentally forgets how important that is,
thinking that permissions on the /etc/shadow file are important.

Also *programs* care about a file with that name.  They reference it
by name, apply security decisions based on a process which starts with
that name.  So the name is the most relevant point of communication
between the policy setter and programs which need to be affected.

So I think AppArmor's approach is good here.

>    * AppArmor checks the name "/etc/shadow" so that you cannot access
>      that name without explicit permission.
>          o AppArmor cares about the integrity of what the OS returns
>            when you access the name "/etc/shadow" and does not care a
>            wit what happens to the inode that was *previously* named
>            "/etc/shadow".
> 
> Now, without running off into the weeds again, tell me again why I 
> should care about the *integrity* of an inode that was *previously* 
> known as "/etc/shadow"?

But insufficient here.

If you rename /etc/shadow legitimately, after changing a password,
there might be a program which still has a handle to the _old_ inode
and is still reading it, still comparing a password against its contents.

If policy was entirely name based, so modifications may be possible to
that file after it's renamed from /etc/shadow to /etc/shadow.bak,
_while_ some programs are still reading it (because it was /etc/shadow
when they opened it, and they got swapped for a moment), that's a failure.

So you *should* care about the integrity of an inode that was
previously known as /etc/shadow - at least until you can prove that
nobody is still dependent on it's earlier security properties.  That's
a garbage collection problem.

> So associating a security property with a name is ok if you do it 
> statically at some arbitrary point in time, but not if you consider it 
> at the time of access? WtF? Isn't that a gigantic race condition?

Both are race conditions.

> To the contrary, I argue that the *current* name of a file is vastly 
> more meaningful for security properties than the name the file had some 
> months ago when someone ran restorecon over the file system.

I agree that the current name is meaningful, but it's not watertight
when your systems change.  To avoid unexpected weaknesses, you'll need
to apply the intersection of permissions over a time period, using
name based policy but having it follow renames until you can prove
it's safe to release the following.

-- Jamie

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Stephen Smalley]

On Thu, 2008-04-17 at 00:49 -0700, Crispin Cowan wrote:
> Stephen Smalley wrote:
> > On Mon, 2008-04-14 at 21:59 -0700, Crispin Cowan wrote:
> >   
> >> Stephen Smalley wrote:
> >>     
> >>> On Sun, 2008-04-13 at 19:05 -0700, Crispin Cowan wrote:  
> >>>       
> >>>> Things that pathname-based access control is good at:
> >>>>
> >>>>     * *System Integrity:* Many of the vital components of a UNIX system
> >>>>       are stored in files with Well Known Names such as /etc/shadow,
> >>>>       /var/www/htdocs/index.html and /home/crispin/.ssh/known_hosts. The
> >>>>       contents of the actual data blocks is less important than the
> >>>>       integrity of what some random process gets when it asks for these
> >>>>       resources by name. Preserving the integrity of what responds to
> >>>>       the Well Known Name is thus easier if you restrict access based on
> >>>>       the name.
> >>>>         
> >>> I think some might argue that the integrity of the data in /etc/shadow
> >>> and your .ssh files is very important, not just their names.
> >>>       
> >> I understand how the confidentiality of secrets like the contents of 
> >> /etc/shadow and your .ssh files is important, but how can the integrity 
> >> of these data objects be important? Back them up if you care ...
> >>     
> > If you aren't concerned with unauthorized data flow into
> > your /etc/shadow and .ssh files, then I think we'll just have to stop
> > right there in our discussion, as we evidently don't have a common point
> > of reference in what we mean by "security".  Personally I'd be troubled
> > if an unauthorized entity can ultimately feed data to such files, even
> > if indirectly by tricking a privileged process into conveying the data
> > to its ultimate target, a not-so-uncommon pattern.
> >   
> Of *course* AppArmor protects the integrity of /etc/shadow, and 
> unauthorized parties are not permitted to feed data into that file 
> unless explicit access is granted. The difference is in how it is done:
> 
>     * SELinux marks the inode with a label, and only processes with the
>       right permissions can mess with the label.
>           o Residual problem: someone could rename the inode and drop a
>             new inode into place named "/etc/shadow". SELinux addresses
>             this with access control on the parent directory.
>     * AppArmor checks the name "/etc/shadow" so that you cannot access
>       that name without explicit permission.
>           o AppArmor cares about the integrity of what the OS returns
>             when you access the name "/etc/shadow" and does not care a
>             wit what happens to the inode that was *previously* named
>             "/etc/shadow".
> 
> Now, without running off into the weeds again, tell me again why I 
> should care about the *integrity* of an inode that was *previously* 
> known as "/etc/shadow"?

Jamie responded to this last question, but let me also touch on what you
still seem to be missing above.  You are only looking at the direct
check when a process tries to write to the file, not any chain of events
that led a process to write to the file and how that process and that
data it is writing might have been influenced by that chain of events.
It is precisely there that security problems often arise, and I think
you'll see that if you go looking at past flaws.  Both SELinux and
AppArmor mediate that direct write, but only SELinux allows you to
control the entire chain of events and help protect the process from
unsafe influence, because that relies on information flow control.

> >>>   And
> >>> ultimately data integrity requires information flow control to preserve.
> >>>   
> >>>       
> >> You've argued that before, and I've never been convinced. Rather, it 
> >> looked a lot like a stretched definition trying really hard to turn 
> >> integrity into an information flow problem.The most information flow 
> >> that I will buy in the integrity problem is taint analysis of software 
> >> inputs; that software should validate inputs before acting on it.
> >>     
> > In some cases, you can simply prohibit a security-relevant process from
> > taking untrustworthy inputs.  Like blocking privileged processes from
> > following untrustworthy symlinks to counter malicious symlink attacks or
> > from reading any files other than ones created by the admin.  In other
> > cases, you need to allow untrustworthy inputs to ultimately flow to the
> > security-relevant process, but you want to force them through some kind
> > of validation as you say above, which you can do by enforcing a
> > processing pipeline that forces the data to go through a subsystem that
> > performs validation and/or sanitization before it ever reaches the
> > security-relevant process.  That's how integrity is an information flow
> > problem.  And this isn't a new idea, btw, it is one that was expressed
> > long ago in the Biba model, a variant of which happens to be implemented
> > and used in Vista, and is more usefully achievable via Type Enforcement
> > since there we can control the processing flow precisely and bind the
> > validation/sanitization subsystem to specific code.
> >   
> Ok. I view the above as a marginal nice-to-have property that I don't 
> actually care much about, because it is a large amount of work to manage 
> for a small amount of integrity to gain. People who want that should use 
> some kind of information flow controlling policy system like SELinux.
> 
> IMHO people with that need are a small minority, which is why I think it 
> is over-strong to say that integrity "requires" information flow 
> control. No it doesn't; the particular form of integrity you are talking 
> about requires information flow control, but other forms do not.

I'd be curious to be pointed to any integrity model that doesn't have
the above "marginal" property.  It is rather fundamental - when it comes
to enforcing data integrity, you generally have some transform
(validation, sanitization, formatting, etc) that you want applied to the
data to move it from lower integrity to higher integrity, and there are
three properties you want to hold:
1) The subsystem that performs the transform or validation must be
protected against bypass and tampering,
2) The transformed/validated data at each stage must be protected
against tampering,
3) The transform must be correct.

Only the last property requires verification of the subsystem code; the
first two can be directly enforced by the underlying system.  But this
does require information flow control.

It shows up all the time in the form of protected subsystems.

> >>>  - anything further is misleading as the
> >>> server or device won't ensure any finer grained separation for us.
> >>>       
> >> I don't understand this issue. The enforcement here is t contain the 
> >> program executing on the NFS *client* to permit it to only mangle the 
> >> parts of the NFS mount that you want it to mangle. That the server won't 
> >> enforce anything for you is irrelevant when the threat is the confined 
> >> application.
> >>     
> > Except that you have to consider what is happening on the server too,
> > given that the files are visible to local processes there, and what
> > happens on all of the clients.
> You don't have to consider any such thing when you are *only* concerned 
> with confining the impact of the process running on the NFS client.
> 
> If you want to concern yourself with funny business coming from other 
> clients, then you need to apply policy to those other clients. If you 
> want to control funny business happening on the server, then you need to 
> apply security policy to the server. But this is all irrelevant to 
> secure confinement of the single NFS client process being confined.

It is relevant when looking at the overall threat model and what you
realistically have to take into account from a real adversary who isn't
going to be limited by your strawman threat model.

> > It isn't a strawman argument.  I know that AppArmor doesn't try to apply
> > pathnames to non-files.  Which leads it down the first case of
> > inconsistent" control - at the end of the day in looking at an AppArmor
> > policy you can't say anything about how information may have ultimately
> > flowed in violation of your confidentiality or integrity goals because
> > you have a lossy abstraction.  Whereas we can convey the same uniform
> > control over files, network IPC, local IPC, etc and make such
> > statements.
> >   
> Conversely, at the end of the day you can't say much about what your 
> SELinux policy enforces, because you can't understand it :)
> 
> Duality again: SELinux policy is easier for machines (semantic 
> analyzers) to understand. AppArmor is easier for humans to understand.

SELinux policy can be analyzed.  AppArmor policy gives the appearance of
being easily understood, but is actually meaningless in terms of any
higher level security goal.

> >>> - forcing policy to be written in terms of individual objects and
> >>> filesystem layout rather than security properties.  
> >>>       
> >> Note also that the SELinux restorecon mechanism also makes the 
> >> assumption that path names correspond to security properties: in fact, 
> >> that is precisely its function, to take a path name and use it to apply 
> >> a security property (a label). Naturally I have no objection to 
> >> inferring a security property from the path name :) I just object to the 
> >> racy way that restorecon does it, combined with the complaint that 
> >> AppArmor is wrong for doing exactly the same thing in a different way.
> >>     
> > Making that inference when a file is first installed (as from rpm) is
> > reasonable.  restorecon (the utility) is for the filesystem to the
> > initial install-time labeling state, which is why it uses the same
> > mapping.  Making that inference on every access in complete ignorance of
> > the actual runtime state of the system is what I object to.
> >   
> So associating a security property with a name is ok if you do it 
> statically at some arbitrary point in time, but not if you consider it 
> at the time of access? WtF? Isn't that a gigantic race condition?

I'll try and explain again.  When a file is installed onto the system
initially (and here we are talking about a file from a package, not a
runtime file being created by a user/application), we have no intrinsic
knowledge of its security properties from the installer's security
properties, and thus we must consult an external data source - in our
case, the file contexts configuration or package metadata.  This relies
on secure creation and distribution of the packages in the first place,
of course, which is a dependency that has to be addressed separately.
At that time, using the pathname of the file as a key for looking up the
context in which to install the file makes sense; it is already the key
for the file.

For runtime operation of the system, we want to use the runtime state of
the system to determine the security properties of data created by
applications and users rather than the pathnames.  And thus SELinux
relies on policy in most cases to automatically label files based on the
security properties of the creating process and related objects, and
when needed, on instrumentation in the applications to explicitly label
files based on more specific application knowledge.

Relabeling of any kind is never desirable - the goal is always to label
the data correctly at creation time and preserve that label for the
lifecycle of the object.  Relabeling is a practical accommodation to
incomplete coverage.  It should always be minimized, and as coverage
grows, it becomes less necessary.

restorecon (the utility) is an administrator's way of forcing a given
file or files back to the initial state, presumably based on his
knowledge that they ought to be in that initial state.  It is only for
fixing up mislabeled files, not for runtime enforcement of anything.

restorecond (the daemon) is entirely an accommodation to usability to
deal with the incomplete coverage of policy and/or application support,
although the latter has come a long way since SELinux was first
introduced.  restorecond isn't necessary for using SELinux, but can be
helpful.  It isn't a fundamental part of the SELinux enforcement
mechanism, and we agree that you shouldn't rely on it to enforce a
security property - it is to fix up gaps left by incomplete coverage.

I think perhaps your confusion is that you think we are advocating
restorecond as a fundamental mechanism for enforcement rather than a
practical accommodation for optional use until coverage is more
complete.  It is a practical solution to the problem you posed earlier.

> To the contrary, I argue that the *current* name of a file is vastly 
> more meaningful for security properties than the name the file had some 
> months ago when someone ran restorecon over the file system.
> 
> I've said this before too: SELinux works well if your IT systems are 
> static. AppArmor works better if your IT systems change, precisely 
> because it evaluates the access based on the name at the time of access, 
> rather than some historic name the file once had.

On the contrary, SELinux enables the system to correctly track the real
runtime state of the system over time and to thus enforce the right
security properties over time.

In any event, my main goal here isn't really to argue about pathnames
vs. labels, but rather just to explain the role of information flow
control in protecting integrity and to clarify some misconceptions you
seem to have about SELinux.

-- 
Stephen Smalley
National Security Agency

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Toshiharu Harada]

> Serge E. Hallyn wrote:
>> Quoting Matthew Wilcox (matthew@wil.cx):
>>
>>> On Fri, Apr 11, 2008 at 11:12:27PM +0900, Tetsuo Handa wrote:
>>>
>>>> Matthew Wilcox wrote:
>>>>
>>>>> When the rule is put in place, say "No modifications to /etc/passwd",
>>>>> look up the inode and major:minor of /etc/passwd.  If there's a
>>>>> rename,
>>>>> look up the new inode number.  If it's mounted elsewhere, it doesn't
>>>>> matter, they still can't modify it because it has the same
>>>>> major:minor:inode.
>>>>>
>>>> If write access is denied because of a rule "No modifications to
>>>> /etc/passwd",
>>>> a rule "Allow modifications to /tmp/passwd" can no longer be
>>>> enforced after
>>>> "mount --bind /etc/ /tmp/" or "mount --bind /etc/passwd /tmp/passwd" or
>>>> "mv /etc/passwd /tmp/passwd" or "ln /etc/passwd /tmp/passwd" is done.
>>>>
>>> That's a fundamental limitation of pathname-based security though.
>>> If the same file exists in two places, you have to resolve the question
>>> of which rule overrides the other.
>>>
>> In the past, Crispin has given clear, concise explanations of a few of
>> the things pathname based access control in fact excels at.  Crispin,
>> can you recite those again so we can think constructively about which
>> (if any) of the currently considered options are or are not sufficient?
>>
>> I.e. what would be a motivation for a rule like 'no modifications to
>> /etc/passwd', and what precisely would and would not be accepted ways to
>> get around it (and why)?
>>
> As I just posted, a rule of "no mods to /some/pathname" is broken, which
> is why AppArmor has no such construct.

Traditional "talking by examples" is a good way and works in general,
but not always right for this case (I mean "label or path" discussion.
Yes, I've learned this from AppArmor thread. :)

> Things that pathname-based access control is good at:
>
>    * *System Integrity:* Many of the vital components of a UNIX system
>      are stored in files with Well Known Names such as /etc/shadow,
>      /var/www/htdocs/index.html and /home/crispin/.ssh/known_hosts. The
>      contents of the actual data blocks is less important than the
>      integrity of what some random process gets when it asks for these
>      resources by name. Preserving the integrity of what responds to
>      the Well Known Name is thus easier if you restrict access based on
>      the name.
>    * *Dynamic Access Control:* A special case of the above pertains to
>      files that may or may not exist. If you don't *have* a /etc/hosts
>      file, it is still important to have a rule that controls whether
>      it can be created. This is hard to do in label-based systems,
>      because the file does not exist to put a label on, so you have to
>      kludge it by either creating the file with zero length and
>      labeling it, or by creating more complex policy for the parent
>      /etc directory, and that's hard given the number of uses for /etc
>      such as /etc/motd. In a name based scheme, you simply don't
>      provide write permission to "/etc/hosts" unless you mean it, and
>      it can be enforced even if such a file does not exist.
>    * *Ad Hoc Generalization:* Label-based access control generalizes
>      policy in that the policy treats all files and resources that
>      share a label the same. If you want to make a new generalization
>      that encompasses *part* of the files that share a label, but *not
>      all* of those files, then you have to "split the label", relabel
>      the file system, and revise the policy accordingly. Name-based
>      access control lets you create ad hoc generalizations, so that
>      *my* policy can grant access to "/var/www/*.pl" without regard to
>      whatever labels or rules some other policy has applied to the same
>      directory tree.
>    * *Familiar Interface:* Administrators are accustomed to
>      administering the box in terms of the names of the files that
>      matter. A name-based policy is therefore somewhat more familiar
>      than a policy with label abstractions, where they then have to go
>      look at the restorecon file to discover what files will/should
>      have what labels.
>    * *Practical Concerns:* Not all file systems support labels, and so
>      label-based schemes become coarse grained when they run into them.
>      Name based schemes remain granular when specifying access down
>      into the internals of such file systems. Legacy Linux file systems
>      like ext2 don't matter much any more, but persistent file systems
>      that will never have label support include NFSv3 file systems
>      (nearly every Network Appliance NAS server out there) and FAT32
>      file system (most every USB storage device).
>
> A lot of what's going on is the duality of the one:many relationships
> between labels and names:
>
>    * Labels: one label represents many files
>          o this property is why ad hoc generalization fails in label
>            based systems
>    * Names: many names can represent a single file
>          o This property is why deny rules fail in name based systems
>
> Therefore, I am not claiming name-based access controls to be the
> ultimate. Rather, there are duals for all of the above that induce
> circumstances where label-based systems are superior. Each class of
> system has strengths and weaknesses. These are name-based strengths.

Agreed and I personally would love to stay discussions in this layer
forgetting existing implementations, including my own project of
TOMOYO Linux. The above summary of labels and names are very important,
but I would like to "raise" the layer of discussion.

The essence of MAC is limiting and restricting.
My version of the MAC *issues* are as follows:

- how to distinguish good(necessary) and bad(unnecessary) accesses
- how to describe the rule (the most important result is a policy language)
- how to keep Linux kernel aware of the rule and keep it safely
- how to administrate the whole picture (with human error in mind)

The first one belongs to a human responsible part and the
remainders belong to implementations. Let me note, label vs. names
issue resides in the implementation layer.

How to describe rules imply "what is the natural way for human
administrators" while keeping the Linux kernel implies
"what is the most solid and trusted way for Linux".
>From the fact is Linux works with names and inodes, I'm pretty sure
we will end up with some sort of hybrid system.

>From the above point of view, the option 2 which Stephen
kindly showed quite *practical* to me, because it allows
loose connection of the "namespace" and "inode". (If your
initial is not S.S, my PNG diagram posted on April 10 might help
to understand what I wrote here)


BTW I'm attending the ELC2008. Hope to see and talk in peace
with some of related people. :)

Regards,
Toshiharu Harada
NTT DATA CORPORATION

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Crispin Cowan]

Matthew Wilcox wrote:
> On Fri, Apr 11, 2008 at 11:12:27PM +0900, Tetsuo Handa wrote:
>   
>> If write access is denied because of a rule "No modifications to /etc/passwd",
>> a rule "Allow modifications to /tmp/passwd" can no longer be enforced after
>> "mount --bind /etc/ /tmp/" or "mount --bind /etc/passwd /tmp/passwd" or
>> "mv /etc/passwd /tmp/passwd" or "ln /etc/passwd /tmp/passwd" is done.
>>     
> That's a fundamental limitation of pathname-based security though.
> If the same file exists in two places, you have to resolve the question
> of which rule overrides the other.
>
> In my role as a sysadmin, I would consider it a flaw if someone could
> edit a file I'd marked uneditable -- simply by creating a hard-link to it.
> If we look at existing systems, such as the immutable bit, those apply to
> inodes, not to paths, so they can't be evaded.  If a system such as TOMOYA
> allows evasion this easily, then it doesn't seem like an improvement.
>   
You are discussing a straw-man, because AppArmor (and I think TOMOYO) do 
not operate that way.

It is not, and never has been, "mark /etc/passwd not writable". Please 
delete this broken concept from the discussion.

Rather, it is "can write to /tmp/ntpd/*". You *grant* permissions. You 
do *not* throw deny rules.

So if you grant write access to /tmp/mumble/barf you should expect it to 
always be accessible, regardless of whether someone creates an alias for it.

Please re-consider the rest of your analysis, because it doesn't work if 
there are only "allow" rules and no "deny" rules. You are correct that a 
pathname-based deny rule is trivially bypassable, that's why there 
aren't any :)

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
Botnets are the only commercially viable utility computing market

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Matthew Wilcox]

On Sun, Apr 13, 2008 at 06:41:19PM -0700, Crispin Cowan wrote:
> You are discussing a straw-man, because AppArmor (and I think TOMOYO) do 
> not operate that way.

Thanks for clarifying that.  I had to put a straw-man up for discussion
because nobody else had.  I'll continue this discussion in terms of
allow-rules.

> Rather, it is "can write to /tmp/ntpd/*". You *grant* permissions. You 
> do *not* throw deny rules.

So primarily we're concerned here with things that are running as root,
daemons and the like.  Normal unix file permissions (or ACLs, if you
must) are adequate to handle anything not running as uid 0.

I don't see what apparmour and tomoya buy us that namespaces can't.
Maybe a nicer interface, but that's something that a nice userspace
management interface can handle.

Create an empty namespace.  Create /tmp/ntpd in it.  Bind the outside
/tmp/ntpd onto that directory.  Presto, the equivalent to an allow-rule
of 'can write to /tmp/ntpd/*'.

The equivalent of 'can read, but not write /home/crispin/.ssh/id_rsa.pub'
will need r-o bind mounts, which Miklos seems to have become distracted
from by working on the hooks for TOMOYA.

Do you have a good example of something that apparmour can protect against
that namespaces can't?

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Crispin Cowan]

Matthew Wilcox wrote:
> On Sun, Apr 13, 2008 at 06:41:19PM -0700, Crispin Cowan wrote:
>   
>> Rather, it is "can write to /tmp/ntpd/*". You *grant* permissions. You 
>> do *not* throw deny rules.
>>     
> So primarily we're concerned here with things that are running as root,
> daemons and the like.  Normal unix file permissions (or ACLs, if you
> must) are adequate to handle anything not running as uid 0.
>   
That's not true. Both AppArmor and SELinux Targeted Policy address 
confinement of both root and non-root applications. Examples:

    * Confining even non-root applications keeps them from accessing
      world and group accessible files.
    * Many services run as nobody instead of root, and smarter ones
      create themselves a new UID to run as. Even so, confining them is
      useful because the least-privilege posture is much easier to
      specify and verify in a capability model (as SELinux and AppArmor
      are) than an ACL model (as permission bits on files are).
    * You may want to confine a desktop application. E.g. Pidgin is a
      great IM tool because it speaks so many protocols, but with that
      large functionality comes a large attack surface, and it has had
      vulnerabilities from time to time. A confined IM client can be
      configured to only have access to your IM files, and not e.g. your
      SSH private keys.


> I don't see what apparmour and tomoya buy us that namespaces can't.
>   
Controlled overlap. You can use AppArmor to confine every *individual* 
piece of a web site shopping cart, and yet they still can interact with 
each other by sharing files. You cannot do that with namespaces.

Conversely, it is very convenient to use namespaces to set up private 
virtual domains, and that is not at all convenient to do with AppArmor, 
TOMOYO, or SELinux.

The correct answer is to use namespaces for total isolation (virtual 
domain hosting) and LSM confinement tools for security within a virtual 
domain.

> Maybe a nicer interface, but that's something that a nice userspace
> management interface can handle.
>   
Not true. Ease of management of access control is about the security 
model. Cute GUIs help, but not much.

> Create an empty namespace.  Create /tmp/ntpd in it.  Bind the outside
> /tmp/ntpd onto that directory.  Presto, the equivalent to an allow-rule
> of 'can write to /tmp/ntpd/*'.
>   
Now get ntpd to show you that you need to do this, in one pass. If you 
already know all of the files to be accessed, and you are going to write 
the security policy by hand, then the two approaches might be kind of 
comparable. But that's not how AppArmor policies are created. This is 
not a minor distinction.

> The equivalent of 'can read, but not write /home/crispin/.ssh/id_rsa.pub'
> will need r-o bind mounts, which Miklos seems to have become distracted
> from by working on the hooks for TOMOYA.
>
> Do you have a good example of something that apparmour can protect against
> that namespaces can't?
>   
See above. The major classes of things that namespaces can't do are:

    * deliberate overlap
    * learning mode
    * wild cards, e.g. 'can read /var/www/**.html' to grant access to
      all of the HTML files in the tree, but not the .pl source code files

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
The Olympic Games: Symbolizing oppressiiion and corruption for over a
hundred years

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Al Viro]

On Mon, Apr 14, 2008 at 08:21:42PM -0700, Crispin Cowan wrote:

> See above. The major classes of things that namespaces can't do are:
> 
>    * deliberate overlap

How do you think new namespaces are created[1] and how, in your opinion, do
they look right after that?

[1] no, "openvz crowd posts a patch revealing yet another offense against
Occam's Razor" is not the right answer to this question.

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Serge E. Hallyn]

Quoting Toshiharu Harada (haradats@nttdata.co.jp):
> On 4/8/2008 12:40 AM, Paul Moore wrote:
>> On Friday 04 April 2008 8:23:12 am Tetsuo Handa wrote:
>>> This file contains modifications against kernel source code
>>> needed to use TOMOYO Linux 1.6.
>>>
>>> Although LSM hooks are provided for performing access control,
>>> TOMOYO Linux 1.6 doesn't use LSM because of the following reasons.
>> Hello,
>> I understand your frustration with the existing LSM hooks/API and your 
>> reasoning for abandoning LSM in favor of a new set of hooks, however, I 
>> think this sets a dangerous precedence which could result in an abundance 
>> of security related hooks scattered throughout the kernel.  I would much 
>> rather see the LSM API extended/tweaked to support the needs of SAKURA and 
>> TOMOYO than ignored and duplicated; I suspect several others will say the 
>> same.
>> You have made good progress with TOMOYO so far and if I can remember 
>> correctly you really only have one hurdle left, the VFS portion.  Please 
>> continue to seek a solution to this that fits within the LSM framework.
>> Thank you.
>
> Thank you for your comments and concern.
>
> I realized that we should have included the reason why we decided to
> post non-LSM version.

First let me point out that reviewing patches is always a lot of work.
What you've done here by posting an entirely new 30-patch implementation
of tomoyo when (I hope) you're not even serious about that is to
basically tell us our time means nothing to you...

If you *are* serious about it, than to whatever extent I can, which
isn't very much, I say nack.

Like you say there appear to be no real remaining objections to the LSM,
only to the VFS part.  You're going to try to get around the VFS
objections by not being an LSM?

Look right now TOMOYO is an out of tree patch.  You want to get it in
tree.  Don't be too hung up on getting it all in at once.  Why not
push a subset of the patch without the vfs controls, which will help
to motivate the vfs controls you need?  You can (1) keep a much smaller
out of tree patch with your implementation of the vfs controls for your
current customrs/installations, and/or (2) implement a temporary
non-pathname-based alternative, say using xattrs to tag files at setup
time - probably insufficient, but sufficient for people to play.

The smaller patch would also be easier to review.

> Let me explain the reason and the history.

We remember the history.  On the one hand we feel for you, but on the
other hand many of us have gone through the same thing, and if you'll
notice Casey went through the same thing and persisted.

> We started developing TOMOYO Linux as original patch sets against
> 2.4 vanilla kernel. We understand the role of LSM, so we ported
> TOMOYO Linux to use LSM and submitted it to the LKML on 13 June 2007.
> We kept working to reflect feedbacks from the community and believe
> no critical Nack remains.

Right, at this point it's mainly a question of finding a way to upstream
tomoyo.  (That's mainly *your* burden, but we do try to help :)

> http://lwn.net/Articles/238049/
> http://lwn.net/Articles/246930/
> http://lwn.net/Articles/252652/
> http://lwn.net/Articles/254503/
> http://lwn.net/Articles/258905/
> http://lwn.net/Articles/263179/
> http://lwn.net/Articles/264187/
> http://lwn.net/Articles/276603/
>
> Still there remains an issue of LSM limitation (vfsmount parameter
> isn?t passed to LSM).
>
> LWN article 239962 says, "At the 2006 summit, Linus took a clear
> position that the use of pathnames for security policies seemed
> reasonable to him".

Yes, but he didn't say you could implement it in a way that offends the
affected maintainers.  Nor did he say it's those maintainers'
responsibility to find you an acceptable solution.  They are in fact
being very nice by offering you suggestions.

Also, isn't Miklos helping you to try and find an acceptable approach?

> Current LSM implementation is sufficient for SELinux
> and other label based MACs but not for pathname-based MACs.
> This has been argued in the AppAmor thread for quite a long time.
> Though proposals had been posted by AppArmor and TOMOYO Linux project,
> none has been merged until now.

You're trying to make it sound like you've spent night and day for years
trying to work with the relevant people to come up with something
reasonable.  Yet for instance in the thread 
	"vfs: add helpers to check r/o bind mounts"
(april 2) where iiuc two reasonable approaches are discussed, you don't
even take part.

> We apologize for the confusion we caused in the last posting,
> but we don't want to give up returning our work to the mainline. 

I'm glad to hear that.  Please keep trying.

> We cordially request LSM changes to pass vfsmount parameters.

Again let me point out there is a difference between saying "Linus said
we can have pathname-based access control, but you won't implement it
for me" and doing the hard work to come up with something reasonable.
I know you've tried a few times, but from what I've seen your impression
of the work you've put into it is far different from my impression of
it.

-serge

Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Toshiharu Harada]

On 4/9/2008 10:22 PM, Serge E. Hallyn wrote:
> First let me point out that reviewing patches is always a lot of work.
> What you've done here by posting an entirely new 30-patch implementation
> of tomoyo when (I hope) you're not even serious about that is to
> basically tell us our time means nothing to you...
> 
> If you *are* serious about it, than to whatever extent I can, which
> isn't very much, I say nack.
You are right. I appreciate your comments and thank you.

> Like you say there appear to be no real remaining objections to the LSM,
> only to the VFS part.  You're going to try to get around the VFS
> objections by not being an LSM?
What annoyed us was the fact we didn't know how the merge would take place.
No nacks can mean no interests and does not mean the ack.
Coding issues/problems can be corrected, but we didn't know how to react with
different way of thinking and concepts. We were at a loss rather than
being frustrated.

BUT I know every those things can't be an excuse. I feel sorry for our
last posting. I apology you all and promise we will never do that.
(I don't mean we will stop submitting)

> Look right now TOMOYO is an out of tree patch.  You want to get it in
> tree.  Don't be too hung up on getting it all in at once.  Why not
> push a subset of the patch without the vfs controls, which will help
> to motivate the vfs controls you need?  You can (1) keep a much smaller
> out of tree patch with your implementation of the vfs controls for your
> current customrs/installations, and/or (2) implement a temporary
> non-pathname-based alternative, say using xattrs to tag files at setup
> time - probably insufficient, but sufficient for people to play.
Yes.

> The smaller patch would also be easier to review.
Yes.

>> Let me explain the reason and the history.
> 
> We remember the history.  On the one hand we feel for you, but on the
> other hand many of us have gone through the same thing, and if you'll
> notice Casey went through the same thing and persisted.
Yes, it was ... really surprising. (I was even scared)

>> We started developing TOMOYO Linux as original patch sets against
>> 2.4 vanilla kernel. We understand the role of LSM, so we ported
>> TOMOYO Linux to use LSM and submitted it to the LKML on 13 June 2007.
>> We kept working to reflect feedbacks from the community and believe
>> no critical Nack remains.
> 
> Right, at this point it's mainly a question of finding a way to upstream
> tomoyo.  (That's mainly *your* burden, but we do try to help :)
It's a great pleasure to receive comments from people.

> Yes, but he didn't say you could implement it in a way that offends the
> affected maintainers.  Nor did he say it's those maintainers'
> responsibility to find you an acceptable solution.  They are in fact
> being very nice by offering you suggestions.
I couldn't agree with you more. I'll never quote that. :)

> Also, isn't Miklos helping you to try and find an acceptable approach?
We started following the thread and found it's very close to
our case. We will watch and join the discussion.

>> Current LSM implementation is sufficient for SELinux
>> and other label based MACs but not for pathname-based MACs.
>> This has been argued in the AppAmor thread for quite a long time.
>> Though proposals had been posted by AppArmor and TOMOYO Linux project,
>> none has been merged until now.
> 
> You're trying to make it sound like you've spent night and day for years
> trying to work with the relevant people to come up with something
> reasonable.  Yet for instance in the thread 
> 	"vfs: add helpers to check r/o bind mounts"
> (april 2) where iiuc two reasonable approaches are discussed, you don't
> even take part.
Right and I am ashamed of it now.

>> We apologize for the confusion we caused in the last posting,
>> but we don't want to give up returning our work to the mainline. 
> 
> I'm glad to hear that.  Please keep trying.
Thank you. (T_T) (crying)

>> We cordially request LSM changes to pass vfsmount parameters.
I wish I could revoke the above statement...

> Again let me point out there is a difference between saying "Linus said
> we can have pathname-based access control, but you won't implement it
> for me" and doing the hard work to come up with something reasonable.
> I know you've tried a few times, but from what I've seen your impression
> of the work you've put into it is far different from my impression of
> it.
Roger. (_ _) (bowing)

Best regards,
Toshiharu