[TOMOYO #7 29/30] Kconfig and Makefile.

[Tetsuo Handa]

This file contains Kconfig and Makefile.

Signed-off-by: Kentaro Takeda <takedakn@xxxxxxxxxxxxx>
Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
Signed-off-by: Toshiharu Harada <haradats@xxxxxxxxxxxxx>
---
 fs/Kconfig.ccs      |  112 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 fs/Makefile-2.6.ccs |    5 ++
 2 files changed, 117 insertions(+)

--- /dev/null
+++ linux-2.6.25-rc8-mm1/fs/Kconfig.ccs
@@ -0,0 +1,112 @@
+config SAKURA
+	bool "SAKURA (Domain-Free Mandatory Access Control) support"
+	default y
+	help
+	  Say Y here to support the Domain-Free Mandatory Access Control.
+
+	  SAKURA stands for
+	  "Security Advancement Know-how Upon Read-only Approach".
+	  As the name shows, SAKURA was originally a methodology to make
+	  root fs read-only to avoid tampering the system files.
+	  But now, SAKURA is not only a methodology but also a kernel patch
+	  that improves the system security with less effort.
+
+	  SAKURA can restrict operations that affect systemwide.
+
+config TOMOYO
+	bool "TOMOYO (Domain-Based Mandatory Access Control) support"
+	default y
+	help
+	  Say Y here to support the Domain-Based Mandatory Access Control.
+
+	  TOMOYO stands for "Task Oriented Management Obviates Your Onus".
+	  TOMOYO is intended to provide the Domain-Based MAC
+	  utilizing task_struct.
+
+	  The word "domain" in TOMOYO is a class that a process
+	  (i.e. task_struct) belong to.
+	  The domain of a process changes whenever the process
+	  executes a program.
+	  This allows you to classify at the finest level.
+	  The access permission is granted to domains, not to processes.
+	  Policy is defined as "Which domain can access to which resource.".
+	  There is no concept of "user id" nor "role" like RBAC.
+
+	  The biggest feature of TOMOYO is that TOMOYO has "learning mode".
+	  The learning mode can automatically generate policy definition,
+	  and dramatically reduces the policy definition labors.
+
+	  TOMOYO is much simpler and easier than SELinux.
+
+	  TOMOYO is applicable to figuring out the system's behavior, for
+	  TOMOYO uses the canonicalized absolute pathnames and
+	  TreeView style domain transitions.
+
+	  You can make custom root fs with minimum files
+	  to run minimum applications with TOMOYO.
+
+config TOMOYO_MAX_ACCEPT_ENTRY
+	int "Default maximal count for learning mode"
+	default 2048
+	range 0 2147483647
+	depends on TOMOYO
+	help
+	  This is the default value for maximal ACL entries
+	  that are automatically appended into policy at "learning mode".
+	  Some programs access thousands of objects, so running
+	  such programs in "learning mode" dulls the system response
+	  and consumes much memory.
+	  This is the safeguard for such programs.
+
+config TOMOYO_MAX_GRANT_LOG
+	int "Default maximal count for grant log"
+	default 1024
+	range 0 2147483647
+	depends on TOMOYO
+	help
+	  This is the default value for maximal entries for
+	  access grant logs that the kernel can hold on memory.
+	  You can read the log via /proc/ccs/grant_log.
+	  If you don't need access grant logs,
+	  you may set this value to 0.
+
+config TOMOYO_MAX_REJECT_LOG
+	int "Default maximal count for reject log"
+	default 1024
+	range 0 2147483647
+	depends on TOMOYO
+	help
+	  This is the default value for maximal entries for
+	  access reject logs that the kernel can hold on memory.
+	  You can read the log via /proc/ccs/reject_log.
+	  If you don't need access reject logs,
+	  you may set this value to 0.
+
+config SYAORAN
+	tristate "SYAORAN (Tamper-Proof Device Filesystem) support"
+	default m
+	help
+	  Say Y or M here to support the Tamper-Proof Device Filesystem.
+
+	  SYAORAN stands for
+	  "Simple Yet All-important Object Realizing Abiding Nexus".
+	  SYAORAN is a filesystem for /dev with Mandatory Access Control.
+
+	  SAKURA can make root fs read-only, but the system can't work
+	  if /dev is read-only. Therefore you need to mount a writable
+	  filesystem (such as tmpfs) for /dev if root fs is read-only.
+
+	  But the writable /dev means that files on /dev might be tampered.
+	  For example, if /dev/null is deleted and re-created as a symbolic
+	  link to /dev/hda by an attacker, the contents of the IDE HDD
+	  will be destroyed at a blow.
+
+	  Also, TOMOYO controls file access by pathnames,
+	  not by security labels.
+	  Therefore /dev/null, for example, might be tampered
+	  if a process have write permission to /dev/null .
+
+	  SYAORAN can ensure /dev/null is a character device file
+	  with major=1 minor=3.
+
+	  You can use SAKURA to make /dev not unmountable.
--- /dev/null
+++ linux-2.6.25-rc8-mm1/fs/Makefile-2.6.ccs
@@ -0,0 +1,5 @@
+obj-y += tomoyo_domain.o
+obj-$(CONFIG_SAKURA) += ccs_common.o realpath.o sakura_mount.o sakura_chroot.o sakura_umount.o sakura_maymount.o sakura_pivot.o sakura_bind.o
+obj-$(CONFIG_TOMOYO) += ccs_common.o realpath.o tomoyo_cond.o tomoyo_file.o tomoyo_exec.o tomoyo_network.o tomoyo_signal.o tomoyo_capability.o tomoyo_audit.o tomoyo_env.o
+obj-$(CONFIG_SYAORAN) += syaoran.o
+syaoran-objs := syaoran_2.6.o

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/