LinuxCon North America 2012 (San Diego)
CaitSith a new type of rule based in-kernel access control
Tetsuo Handa, NTT
(C) 2012 NTT Open Source Software Center 2012/8/29-2012/8/31 Who am I?
A retired employed programmer My involvement with Linux 2001.10-2003.3 Developing user space applications that run on Linux systems. 2003.4-2012.3 Developing kernel mechanisms for improving security of Linux systems. 2012.4- Providing user support service for troubleshooting Linux systems.
1 What do I speak today?
Security, especially access control in kernel space.
May I?
Yes.
May I?
No. User space Kernel space Subject(processes), Action, Object(resources) That's all. However, it is extremely difficult to develop rules that match user's needs.
Subject Action Object
2 Players?
Security mechanisms which come on my talk.
SELinux SubDomain SAKURA TOMOYO CERBERUS SYAORAN YUE
TOMOYO 1.x
TOMOYO 2.x
RWXfilter AppArmor AKARI code inheritance CaitSith idea feedback 3 TOMOYO is a registered trademark of NTT DATA CORPORATION in Japan. Structure of this presentation?
Chapter 1 --- Introduction: Summarized description of what has happened before CaitSith For users who are interested in in-kernel access control. Chapter 2 --- Things I experienced with continuing enhancement of access control functionality For developers who are developing access control modules. Chapter 3 --- Things I experienced with continuing enhancement of ease of use For users who are seeking for simpler in-kernel access control modules. Chapter 4 --- CaitSith For users who are interested in my proposal.
4 Chapter 1
Introduction: Summarized description of what has happened before CaitSith
5 Everyone's security varies?
What people associate with the word "security" depends on their skill levels and beliefs. Give people choices, rather than forcing the only one. My belief is that visualization is important. Many of today's security issues come from invisibleness. Traceability leads to satisfaction.
6 Attempts for doing access control in the kernel space
Threats are in the behavior of the user space. But, doing access control in the user space is problematic. It can be bypassed when deprived of control. Its level and granularity varies. Let's do access control in the kernel space, in addition to access control in the user space. Although what in-kernel access control can do is limited, in- kernel access control can provide a baseline restriction and will be useful.
7 Mandatory Access Control(MAC)
Implementation that does access control in the kernel space. It cannot be bypassed because it is done in the kernel space. Currently, SELinux, SMACK, TOMOYO and AppArmor are in the Linux mainline kernel. They are all **whitelisting** approach which uses Linux Security Modules (LSM) interface. They do access control from the point of view of **subjects**.
can only
on
8 Distributor's kernels enable some of them, but...
Many people are still disabling SELinux.
9 Distributor's kernels enable some of them, but...
Even AppArmor which was claimed to be easier than SELinux is disabled.
10 Distributor's kernels enable some of them, but...
What about SMACK?
Not disabled yet, for SMACK is not enabled without user's explicit configuration.
11 Distributor's kernels enable some of them, but...
What about TOMOYO?
Not disabled yet, for TOMOYO is not enabled without user's explicit configuration.
12 Distributor's kernels enable some of them, but...
Reasons to disable them? Fears to use without understanding their configuration. Fears to miss permissions in the whitelisting approach. There are a lot of documentation. Too long, didn't read. They are for developers, not for users.
13 "all or nothing" problem
Ideally, access control is enforced on all subjects and all objects.
In reality, it is considered as "Well done" if access control is enforced on some specific subjects.
When troubles occur, they will have no choice but to **disable entirely** unless they know how to configure policy and current policy configurations.
14 Reasons why TOMOYO insisted on manageability for users?
No resource to distribute ready-made policy. TOMOYO has no background distributors compared to SELinux(RedHat) and AppArmor(SUSE/Ubuntu). Unable to troubleshoot if ready-made policy is used. TOMOYO would follow the same way where SELinux and AppArmor stray into. What people want to allow/deny varies. It is impossible to develop ready-made policy that can cover everybody's needs. Have to disable upon troubles if there is only one switch. "all or nothing" problem
15 Problems with developing policy configuration
An "access control" restricts access requests based on rules defined beforehand. It is an implicit requirement that users can define rules beforehand. However, to define rules beforehand, users have to be familiar with internal structure of Linux systems. Not many users are familiar with Linux internal because it is a world where they usually don't care. However, paying attention for burden of defining rules has generally been viewed as unimportant. TOMOYO had been paying attention for this burden.
16 TOMOYO had been struggled in order to keep TOMOYO enabled.
Made possible to enable/disable on a per-action basis using profiles. This allows users to choose the action coverage based on their skills. Made possible to enable/disable on a per-domain basis using profiles. This allows users to choose the subjects coverage based on their skills.
17 TOMOYO had been struggled in order to keep TOMOYO enabled.
Made possible to handle policy violations interactively. This allows users to judge unexpected access requests on a case-by-case basis. Made possible to understand all states using tree style domain transitions. This allows users to understand what's going on.
18 Meanwhile, I received unexpected requests from RHEL users...
"I want to apply access control on specific resources (files), rather than applying on specific processes." TOMOYO was allowing users to enable/disable access control on a per-action basis and a per-domain basis, but was not allowing users to enable/disable access control on a per-file basis.
19 After all, did existing MAC implementations respond to user's needs?
User's needs are not always whitelisting nor from the point of view of processes. Some wants to apply from the point of view of resources. Some are not interested in managing domains. These are limitations for TOMOYO.
We might want to try a fundamental course-changing move. That's the trigger for developing CaitSith.
20 Chapter 2
Things I experienced with continuing enhancement of access control functionality
21 SAKURA (2003.4-)
An attempt for protecting Linux systems without policy management.
SELinux SubDomain SAKURA TOMOYO CERBERUS SYAORAN YUE
TOMOYO 1.x
TOMOYO 2.x
RWXfilter AppArmor AKARI code inheritance CaitSith idea feedback 22 SAKURA
I tried SELinux, but I soon gave up because SELinux was too difficult to use. Can't we omit policy management by specializing for protection from tampering? Code name: "Security Advancement Know-how Upon Read- only Approach for Linux" Topics on SAKURA Protection from tampering via read-only mounting System-wide access restriction Spontaneous permission abandonment via modification of user space programs
23 Protection from tampering via read-only mounting
Mounting filesystems as read-only wherever possible in order to reduce the risk of tampering files. I modified the kernel to report pathnames which failed with - EROFS error in order to help separating read-only directories and writable directories. Mount all partitions except partitions which need to be writable (e.g. /var and /tmp) read-only, and store read-only partitions into read-only medium in order to protect from direct tampering attacks (e.g. writing to block device files which corresponds to read-only mounted partitions).
24 System-wide access restriction
Mounting a writable filesystem over a read-only filesystem ruins tamper-proof protection. Restrict namespace related actions (e.g. mount, chroot, pivot_root) for system-wide. An example configuration looks like below. allow_mount devpts /dev/pts/ devpts 0x0 allow_mount any / --remount 0x0 allow_mount securityfs /sys/kernel/security/ securityfs 0x0 allow_mount none /proc/sys/fs/binfmt_misc/ binfmt_misc 0x0
allow_chroot /etc/avahi/ Note that the name of allow_chroot /var/empty/sshd/ processes are not specified.
25 Spontaneous permission abandonment via modification of user space programs
To make system-wide access restriction more efficient, I added spontaneous permission abandonment by appending a original field to task_struct of Linux 2.4 kernels. Allow user space programs to discard permissions to call execve(), chroot(), pivot_root(), mount() and a permission to regain effective UID = 0 on a per-task_struct basis. Temporal discard which the permissions will be regained after successful execve() request. Permanent discard which the permissions will not be regained after execve() request. We could not afford resource to modify user space programs and this feature was removed in TOMOYO 1.4. => But a more wider spontaneous permission abandonment feature was added to Linux 3.5 as "seccomp mode 2". 26 SYAORAN (2004.10-)
Tamper-proof filesystem for /dev partition.
SELinux SubDomain SAKURA TOMOYO CERBERUS SYAORAN YUE
TOMOYO 1.x
TOMOYO 2.x
RWXfilter AppArmor AKARI code inheritance CaitSith idea feedback 27 SYAORAN
SAKURA made it possible to mount / partition as read-only, but /dev cannot be mounted as read-only. Existing /dev filesystems (e.g. devfs and devtmpfs) allowed modification of directory entries via requests from user space. Tampering files in /dev partition is a severe problem. What happens if /dev/null has attributes of /dev/zero ? Code name: "Simple Yet All-important Object Realizing Abiding Nexus" Topics on SYAORAN Tamper-proof filesystem for /dev partition
28 Tamper-proof filesystem for /dev partition
I developed a dedicated filesystem for /dev by adding attribute checking logic to tmpfs filesystem. By using this filesystem, we can enforce combination of filenames and their attributes. For example, /dev/null always has char-1-3 and /dev/zero always has char-1-5.
29 Tamper-proof filesystem for /dev partition
Configuration file looks like below. #filename perm owner group flags type major minor pts 755 0 0 0 d shm 755 0 0 0 d null 666 0 0 0 c 1 3 zero 666 0 0 0 c 1 5 random 644 0 0 0 c 1 8 urandom 644 0 0 0 c 1 9 tty 666 0 0 0 c 5 0 tty0 600 0 0 12 c 4 0 tty1 600 0 0 12 c 4 1
Note that the permitted actions (create/delete/chmod/chown/chgrp) are restricted 30 Managing policy is inevitable?
By using SYAORAN for /dev and using SAKURA for wherever possible, the risk of tampering files can be reduced. Although the combination of SAKURA and SYAORAN made it impossible to tamper files stored into read-only medium, storing into read-only medium also makes it impossible to handle software updates. To make it possible to handle software updates while protecting from tampering, we should consider also using policy based protection. => Leads to TOMOYO.
31 TOMOYO (2003.7-)
An attempt for implementing manageable policy.
SELinux SubDomain SAKURA TOMOYO CERBERUS SYAORAN YUE
TOMOYO 1.x
TOMOYO 2.x
RWXfilter AppArmor AKARI code inheritance CaitSith idea feedback 32 TOMOYO
SELinux's policy is too difficult to use. Can't we develop original policy that covers only what we need? Let's generate policy that allows only behavior of processes which we ever observed. Code name: "Task Oriented Management Obviates Your Onus on Linux" Topics on TOMOYO System-wide domain transition tracing function Access request tracing function on a per-domain basis Access request restricting function on a per-domain basis
33 System-wide domain transition tracing function
Append a original field to task_struct of Linux 2.4 kernels. Form a tree style state transition using the fork()/execve() mechanism. Use each state in the tree as a domain.
34 Access request tracing function on a per-domain basis
Started as an access analysis tool. Trace open() and execve() requests using pathnames and sort the output by domain as a key.
Caveat: These screenshots include other requests because these are taken using TOMOYO 1.8 on CentOS 6.3.
35 Access request tracing function on a per-domain basis
36 Access request tracing function on a per-domain basis
37 Access request restricting function on a per- domain basis
I attempted to generate SELinux's policy from the output. I gave up because I could not map TOMOYO's pathnames into SELinux's labels. Instead, I added function to restrict access requests based on the observed output At this time, I didn't distinguish requests for modifying directory entries. In other words, the granularity was similar to DAC's rwx.
38 CERBERUS (2004.1-)
One of advanced usages of TOMOYO, which protects from login brute force attacks.
SELinux SubDomain SAKURA TOMOYO CERBERUS SYAORAN YUE
TOMOYO 1.x
TOMOYO 2.x
RWXfilter AppArmor AKARI code inheritance CaitSith idea feedback 39 CERBERUS
SSH brute force attacks can break protection by MAC. Why not to enforce extra authentications? Code name: "Chained Enforceable Re-authentication Barrier Ensures Really Unbreakable Security" Topics on CERBERUS Anti brute force technique via multiplexed user authentication.
40 Anti brute force technique via multiplexed user authentication.
I noticed that we can deploy user authentications for multiple times, by using TOMOYO's tree style state transition.
SSH login session, as well as other SSH server programs, can form tree style domain transition
Login shell
Some Domain
Some Domain
Some Domain
Some Domain 41 Anti brute force technique via multiplexed user authentication.
I noticed that we can deploy user authentications for multiple times, by using TOMOYO's tree style state transition.
Built-in This stage can be passed authentication by brute force attack by SSH server These stages can enforce different Restricted type of authentication login shell Mandatory extra authentication 1 Restricted temporary shell Mandatory extra authentication 2 Normal shell 42 YUE (2004.1-)
One of advanced usages of TOMOYO, which divides privileges for administrative jobs.
SELinux SubDomain SAKURA TOMOYO CERBERUS SYAORAN YUE
TOMOYO 1.x
TOMOYO 2.x
RWXfilter AppArmor AKARI code inheritance CaitSith idea feedback 43 YUE
The root privileges are needed for doing administrative jobs. But only one root user can exist. Why not to divide privileges using TOMOYO's tree style state transition? Code name: "Your User-role Enforcer" Topics on YUE Privilege division technique like Role Based Access Control (RBAC)
44 Privilege division technique like Role Based Access Control (RBAC)
I noticed that we can divide privileges for administrative jobs into arbitrary groups, by using TOMOYO's tree style state transition.
Even if the login shell is the same, Login program running different programs forms (e.g. /bin/login) different sub-tree Login shell Therefore, in TOMOYO, any domain at that moment represents the role Some Domain of the moment
Some Domain
Some Domain
Some Domain
45 Privilege division technique like Role Based Access Control (RBAC)
I noticed that we can divide privileges for administrative jobs into arbitrary groups, by using TOMOYO's tree style state transition.
Login program (e.g. /bin/login) /bin/bash and /bin/tcsh are examples for splitting subtree Login shell
/bin/bash Grant permissions Domain for needed for administrating httpd managing httpd /bin/tcsh Domain for Grant permissions administrating ftpd needed for managing ftpd
46 TOMOYO 1.x (2005.11-)
The origin of my various derivative works.
SELinux SubDomain SAKURA TOMOYO CERBERUS SYAORAN YUE
TOMOYO 1.x
TOMOYO 2.x
RWXfilter AppArmor AKARI code inheritance CaitSith idea feedback 47 TOMOYO 1.0 (2005.11-2006.3)
A version which was published as a GPL open source software with outcomes since 2003.4. SAKURA which handles restriction of namespace manipulation on system-wide basis TOMOYO which handles restriction of access requests on a per-domain basis SYAORAN which protects /dev partition CERBERUS which protects from login brute force attacks YUE which divides privileges for administrative jobs
48 TOMOYO 1.1 (2006.4-2006.9)
User space programs behaves differently depending on names. Gear towards more strictly restricting names which affects program's behavior, in addition to restricting whether the pathname is readable/writable/executable or not. Differentiate directory entry modification actions (i.e. mkdir, rmdir, create, unlink, mksock, mkfifo, mkchar, mkblock, link, symlink, rename, truncate) from "write" action. Made it possible to handle policy violations interactively. Give users a chance to handle unexpected events which sometimes occur upon running software updater(e.g. yum/apt).
49 TOMOYO 1.2 (2006.9-2006.11)
Check invocation name (a.k.a. argv[0]) upon checking program's execute permission. Because multi-call programs (e.g. busybox) behave differently depending on the invocation name. Check current process's user ID etc. and file's owner ID etc. upon checking permissions. Checking only pathname is not sufficient.
50 TOMOYO 1.3 (2006.11-2006.3)
Made it possible to specify whether to enforce access control or not, on a per-domain basis by introducing profile number which takes an integer between 0 and 255. Profile number allowed users to use TOMOYO like SELinux's targeted policy. Profile number also allowed users to use different functionality on different programs. Made it possible to suppress/reset domain transitions as needed. Support various patterns of domain transition.
51 TOMOYO 1.4 (2007.4-2007.9)
Support pathname subtraction operator. Generally, filenames starting with a dot should be treated differently. /var/www/html/\*\-.\* For example, differentiate /var/www/html/.htaccess from /var/www/html/index.html Support x86_64 architecture. Started developing an LSM version called TOMOYO 2.x and started challenges for inclusion into Linux mainline kernel. TOMOYO Linux project had a BoF session at Ottawa Linux Symposium 2007.
52 TOMOYO 1.5 (2007.9-2008.3)
Improved usability in order to differentiate TOMOYO from AppArmor. At that time, TOMOYO was challenging for inclusion into Linux mainline kernel. But since both TOMOYO and AppArmor used pathnames in their policy configuration, TOMOYO and AppArmor are regarded as "no need to include both implementations into Linux mainline". I tried to show how attentive TOMOYO is. Made possible to run TOMOYO 1.x in parallel with SELinux. The label based MAC and the name based MAC play complementary role. Thus, these should be able to run in parallel.
53 TOMOYO 1.6 (2008.4-)
Various functionality/usability enhancements check argv[]/envp[] upon program execution support execute handler which intercepts program execution request and validates/sanitizes argv[]/envp[] etc. This can silently terminate a process if the process issued suspicious execve() request (e.g. /bin/sh without appropriate argv[]/envp[]) support stateful acl and many more This is the base code for RWXfilter and TOMOYO 2.2.
54 TOMOYO 1.7 (2009.9-)
Current stable version. Checks not only pathnames but also various attributes passed together. Changed module name of TOMOYO 1.x to CCSecurity since TOMOYO 2.2 was included into Linux mainline kernel. Took occasion to review the division of the roles. Integrate system-wide access restrictions (SAKURA) into a per-domain access restrictions (TOMOYO). Integrate access restrictions in /dev filesystem (SYAORAN) into a per-domain access restrictions (TOMOYO).
55 System-wide access restriction vs. A per-domain access restriction
Why did I treat system-wide access restriction and a per- domain access restriction separately? Mainly enthusiasm for the code names. In order to restrict more precisely, why not to specify on a per- domain basis rather than system-wide basis, for TOMOYO 1.x can apply access restrictions to all processes? I thought (at that time) "Definitely". As a background of this decision, I was targeting for more finer grained restriction in order to support LXC (pivot_root) users. Since TOMOYO 2.2 supported only TOMOYO (a per- domain access restriction), I removed SAKURA (system- wide access restriction) from TOMOYO 1.7.
56 Access restriction by filesystems vs. Access restriction by domains
Why did I have to restrict at filesystem layer? Now, TOMOYO can check not only filenames but also file's attributes. Should I continue maintaining /dev filesystem? I thought (at that time) "Not worth maintaining". I removed SYAORAN filesystem from TOMOYO 1.7, for SYAORAN filesystem conflicts with udev approach.
57 TOMOYO 1.8 (2010.11-)
Current latest version which supports Linux 2.6.27-3.5 kernels. Reviewed internal structures, removed redundant/legacy functionality, renamed keywords in the policy syntax. Made it possible to preserve kernel ABI by introducing hooks into fork() and exit() (instead of appending original fields to task_struct which results in kernel ABI breakage). It became possible to treat like distributor's stock kernels. This is the base code for AKARI and CaitSith.
58 TOMOYO 2.x (2007.6-)
The mainlined version of TOMOYO 1.x.
SELinux SubDomain SAKURA TOMOYO CERBERUS SYAORAN YUE
TOMOYO 1.x
TOMOYO 2.x
RWXfilter AppArmor AKARI code inheritance CaitSith idea feedback 59 TOMOYO 2.2 (2009.6-2010.10)
A version which was mainlined in Linux 2.6.30 kernel. Only core function of TOMOYO 1.6 is implemented. Addition of missing LSM hooks for file related actions has completed by Linux 2.6.33 kernel.
60 TOMOYO 2.3 (2010.10-2011.10)
A version which was included into Linux 2.6.36-3.0 kernels. Major functionality regarding file related actions in TOMOYO 1.7 is implemented.
61 TOMOYO 2.4 (2011.10-2012.1)
A version which was included into Linux 3.1 kernel. A version which has practically usable function. Major functionality regarding file related actions in TOMOYO 1.8 is implemented.
62 TOMOYO 2.5 (2012.1-)
A version which is included into Linux 3.2 and later kernels. It is possible to backport this version up to Linux 2.6.33 kernel without modifying outside of security/tomoyo/ directory. Major functionality in TOMOYO 1.8 is implemented. Not yet implemented functionality execute handler Checking permission of incoming network packets. capability (Maybe seccomp mode 2 can substitute?) Checking permission of binary loader programs. Running with other LSM modules in parallel.
63 Things I achieved
In-kernel access control which takes into account side effects in the user space Preserving only "whether the file is readable/writable/executable or not" is not sufficient. Firewall which checks various parameters which are represented in the form of string or numeric values. Know all possible behaviors from boot to shutdown. Covers all processes Use task_struct for defining domains. Sense of safety that can cover all processes TOMOYO 1.8 is used in Android devices. Focuses on preventing from unwanted behaviors.
64 Things I struggled
Implement functionality which will be useful, while keeping psychological barrier as low as possible.
First step(2005.11) I made it possible to enable/disable on a per-action basis.
Profiles
65 Things I struggled
Second step(2006.11) Even though TOMOYO can apply restrictions on all processes, user's skill are not catching up. I made it possible to enable/disable access restrictions on a per-domain basis. This also made it Profiles possible to use build-up approach by switching profiles after the policy is developed.
66 Things I struggled
Third step(2011) Even if restricting only file related actions, it is too difficult to switch all files to enforcing mode at once.
Profiles
67 Things I struggled
Third step(2011) I considered profiles on a per-filename basis. I didn't implement because it will become too messy.
Profiles
68 Things I struggled
Third step(2011) I considered blacklisting approach. I didn't implement because it conflicts access control modes in the profiles The permissive mode is defined as "check access requests but do not reject", but blacklisting will make the permissive mode no longer permissive. It is impossible to apply blacklisting approach before defining domains. How should TOMOYO handle blacklist when TOMOYO automatically generated domains? => Leads to CaitSith
69 Chapter 3
Things I experienced with continuing enhancement of ease of use
70 RWXfilter (2010.2-2010.4)
The trigger for seriously considering Linux user's real opinions.
SELinux SubDomain SAKURA TOMOYO CERBERUS SYAORAN YUE
TOMOYO 1.x
TOMOYO 2.x
RWXfilter AppArmor AKARI code inheritance CaitSith idea feedback 71 A request from RHEL users.
SELinux is too difficult for us to use. Please develop a single function access control mechanism that can be loaded into RHEL kernels as a loadable kernel module. I decided to implement a loadable kernel module that makes use of LSM interface. Please allow users to apply access control on only specific files. I decided to filter only "read/write/execute" actions in order to minimize barrier for users. Code name: "Read/Write/Execute filter", or in short "RWXfilter".
72 Dilemmas
Existing MAC implementations assume "define domains first, and then associate permissions/resources to domains". But it is difficult to apply such approach to all processes. But it ruins the value of MAC if there is a process which such approach is not applied. But we cannot impose on users the burden of managing every process only for applying access control on some specific resources.
73 I reversed the viewpoints.
Switch from "define domains first, and then associate actions/resources" to "define resources first, and then associate actions/domains".
Capability model Access control list model
can only can be
on by
only
74 Policy syntax for RWXfilter
"Resource" "Access Control Mode" "Action1" by "Domain1 which action1 is allowed" "Action2" by "Domain2 which action2 is allowed" "Action3" by "Domain3 which action3 is allowed" "Resource" is TOMOYO's pathname representation. "Access Control Mode" is either "permissive" or "enforcing". "ActionX" is one of "read", "write" or "execute". "DomainX which actionX is allowed" is TOMOYO's domainname representation.
75 An example of RWXfilter's policy
/etc/shadow enforcing read by
76 Consequence
RWXfilter was shelved because I could not establish commercial support. But RWXfilter triggered me to explorer the possibility of access controls from different point of view. => Leads to CaitSith. I established an approach for appending another LSM module as a loadable kernel module without disabling SELinux. I demonstrated Yama with TOMOYO 2.x at Linux Security Summit held in conjunction with LinuxCon North America 2010 (Boston). => Leads to AKARI.
77 AKARI (2010.10-)
The loadable kernel module version of TOMOYO 1.8.
SELinux SubDomain SAKURA TOMOYO CERBERUS SYAORAN YUE
TOMOYO 1.x
TOMOYO 2.x
RWXfilter AppArmor AKARI code inheritance CaitSith idea feedback 78 Origination
TOMOYO 2.x remains unsupported in Fedora and RHEL kernels. https://bugzilla.redhat.com/show_bug.cgi?id=542986 Replacing the kernel package is a strong psychological barrier. Can't we somehow try TOMOYO more easily?
79 What did I think?
There are functionality which cannot be implemented as a loadable kernel module, for some hooks are not provided by LSM. TOMOYO started as an access analysis tool. For analysis purpose, it would be acceptable that some functionality cannot be implemented? Just try to get used to it. => I applied the approach which I established via RWXfilter to TOMOYO 1.8.
80 Consequence
We now can use major functionality of TOMOYO 1.8 on Fedora and RHEL kernels. Especially useful for analysis purpose because AKARI is a loadable kernel module similar to RWXfilter. http://akari.sourceforge.jp/ Access Keeping And Regulating Instrument.
81 Chapter 4
CaitSith
82 CaitSith (2012.4-)
The most powerfully and flexibly configurable policy syntax derived from 9 years of my experience.
SELinux SubDomain SAKURA TOMOYO CERBERUS SYAORAN YUE
TOMOYO 1.x
TOMOYO 2.x
RWXfilter AppArmor AKARI code inheritance CaitSith idea feedback 83 Starting point for CaitSith
Threats are in the behavior of the user space. But the threats are getting to shift to areas where in-kernel access control cannot deal with. For example, mails/tweets by error exposed to or shared by unexpected peers because of bugs in the user space applications. It's a limitation for in-kernel access control. The "seccomp mode 2" became available in Linux 3.5. => Maybe we no longer need to go off the deep end at the kernel side.
84 What is the way MAC needs to be?
Things I experienced with continuing enhancement of access control functionality: A per-domain basis access control can do better than system wide access control, as long as access control is applied on all domains. => If there is a domain which access control is not applied, it becomes a hole which would not have existed if system wide access control is used. In reality, there are usually domains which access control is not applied. => But system wide access control alone is not sufficient.
85 What is the way MAC needs to be?
Things I experienced with continuing enhancement of access control functionality: There are users who want to restrict access using blacklisting approach rather than whitelisting approach. => Blacklisting approach is difficult for TOMOYO because TOMOYO automatically creates domain.
86 What is the way MAC needs to be?
Things I experienced with continuing enhancement of ease of use: There are users who want to restrict access from the point of view of resources rather than that of processes. => Access controls which depends on "define domains first" cannot handle this request. There are users who want to restrict access on specific resources. => Access controls which depends on whitelisting cannot handle this request.
87 What is the way MAC needs to be?
My conclusion: It's time to break dependence on domains (Domain Type Enforcement) and whitelisting. Let's consider from scratch.
88 How can I take advantage of both approaches?
TOMOYO which was made from the point of view of **subjects** and focused on enhancing functionality
can only
on
RWXfilter which was made from the point of view of **objects** and focused on enhancing usability
can be
by
only
89 Why not to use Action as a key?
Capability model + Access control list model => Action check list model
Check if is Grant or deny the request if requested. Check if by by and on are true.
is requested. Grant or deny the request if Check if on on is true. is requested. Grant or deny the request if Check if by by is true. and on is requested. Grant or deny the request.
90 My proposed syntax
acl "Action" "Whether to check Action or not" audit "Audit pattern specifier" "Decision1" "Whether to use Decision1 or not" "Decision2" "Whether to use Decision2 or not" "Decision3" "Whether to use Decision3 or not" Specify Action as a key, and enumerate conditions as needed. Not using mandatory (positional) parameters All parameters (including domains) are optional. Split into two phases: "whether to check or not" and "whether to grant/deny or not". Not using profiles because there is no need to specify enabled/disabled.
91 Characteristic points of proposed syntax
Supports both whitelisting approach and blacklisting approach. Supports both the point of view of subjects and the point of view of objects, using actions as a key. Allows users to fully utilize TOMOYO's parameter validation capabilities. Allows users to apply single function restrictions like RWXfilter. Allows users to easily apply system wide restriction because action is the key.
=> Above topics are explained later using example policy.
92 How does policy file look like? POLICY_VERSION=20120401 quota memory audit 16777216 quota memory query 1048576 quota audit[1] allowed=0 denied=1024 unmatched=1024
0 acl modify_policy audit 1 1 deny task.uid!=0 1 deny task.euid!=0 100 allow task.exe="/usr/sbin/caitsith-loadpolicy" 100 allow task.exe="/usr/sbin/caitsith-queryd" 10000 deny
93 How does policy file look like? POLICY_VERSION=20120401 quota memory audit 16777216 Header part defines quota quota memory query 1048576 and groups quota audit[1] allowed=0 denied=1024 unmatched=1024
0 acl modify_policy
audit 1 Body part defines rules 1 deny task.uid!=0 1 deny task.euid!=0 100 allow task.exe="/usr/sbin/caitsith-loadpolicy" 100 allow task.exe="/usr/sbin/caitsith-queryd" 10000 deny
94 How does policy file look like? POLICY_VERSION=20120401
quota memory audit 16777216 Version of policy syntax quota memory query 1048576 quota audit[1] allowed=0 denied=1024 unmatched=1024
Allow up to 16MB of kernel memory 0 acl modify_policy for spooling audit logs audit 1 1 deny task.uid!=0 1 deny task.euid!=0 100 allow task.exe="/usr/sbin/caitsith-loadpolicy" 100 allow task.exe="/usr/sbin/caitsith-queryd" 10000 deny
95 How does policy file look like? POLICY_VERSION=20120401 quota memory audit 16777216 quota memory query 1048576 quota audit[1] allowed=0 denied=1024 unmatched=1024
0 acl modify_policy Apply audit log quota audit 1 defined in audit[1] line 1 deny task.uid!=0 1 deny task.euid!=0 100 allow task.exe="/usr/sbin/caitsithAllow spooling-loadpolicy up to 0" logs when matched "allow" line, up to 1024 logs 100 allow task.exe="/usr/sbin/caitsithwhen matched-queryd "deny"" line, up to 10000 deny 1024 logs when did not match "allow" line nor "deny" line
96 How does policy file look like? POLICY_VERSION=20120401 quota memory audit 16777216 Checking priority when there are multiple acl quota memoryblocks with query the same 1048576 action quota audit[1] allowed=0 denied=1024 unmatched=1024
0 acl modify_policy audit 1 1 deny task.uid!=0 Additional conditions for checking whether 1 deny task.euid!=0 to check this action or not. 100 allow task.exe="/usr/sbinUnconditionally/caitsith-loadpolicy checked "if omitted 100 allow task.exe="/usr/sbin/caitsith-queryd" Name of action to check. In this example, 10000changing deny policy configuration
97 How does policy file look like? POLICY_VERSION=20120401 quota memory audit 16777216 quota memory query 1048576 quotaDecision audit[1] priority allowed=0 when there denied=1024 are multiple unmatched=1024 decision lines within this acl block 0 acl modify_policy audit 1 1 deny task.uid!=0 1 deny task.euid!=0 100 allow task.exe="/usr/sbin/caitsith-loadpolicy" 100 allow task.exe="/usr/sbin/caitsith-queryd" 10000 deny
98 How does policy file look like? POLICY_VERSION=20120401 quota memory audit 16777216 quota memory query 1048576 quota audit[1] allowed=0 denied=1024 unmatched=1024
Decision is either "allow" or "deny" 0 acl modify_policy audit 1 1 deny task.uid!=0 1 deny task.euid!=0 100 allow task.exe="/usr/sbin/caitsith-loadpolicy" 100 allow task.exe="/usr/sbin/caitsith-queryd" 10000 deny
99 How does policy file look like? POLICY_VERSION=20120401 quota memory audit 16777216 quota memory query 1048576 quota audit[1] allowed=0 denied=1024 unmatched=1024
Additional conditions for deciding whether 0 acl modify_policy to apply the decision or not. audit 1 The decision is unconditionally applied if 1 deny task.uid!=0 omitted 1 deny task.euid!=0 100 allow task.exe="/usr/sbin/caitsith-loadpolicy" 100 allow task.exe="/usr/sbin/caitsith-queryd" 10000 deny
100 How does policy file look like? POLICY_VERSION=20120401 quota memory audit 16777216This acl block defines below rules. (1) Deny changing policy configuration if quota memory query 1048576 current thread's user id or effective quota audit[1] allowed=0 denied=1024user id is notunmatched=1024 0 (2) Allow changing policy configuration if /proc/self/exe is either 0 acl modify_policy /usr/sbin/caitsith-loadpolicy or /usr/sbin/caitsith-queryd audit 1 (3) Deny changing policy configuration 1 deny task.uid!=0 otherwise 1 deny task.euid!=0 100 allow task.exe="/usr/sbin/caitsith-loadpolicy" 100 allow task.exe="/usr/sbin/caitsith-queryd" 10000 deny
101 How does audit log look like?
Trying to modify policy configuration by bash will be denied. # echo '1000 acl modify_policy' > /proc/caitsith/policy -bash: echo: write error: Operation not permitted And a denied log will be generated.
0 acl modify_policy Doesn't match audit 1 Doesn't match 1 deny task.uid!=0 1 deny task.euid!=0 Doesn't match 100 allow task.exe="/usr/sbin/caitsith-loadpolicy" 100 allow task.exe="/usr/sbin/caitsith-queryd" 10000 deny Matches Doesn't match
102 How does audit log look like?
Below is a denied log generated by trying to modify policy configuration by bash. #2012/07/11 14:06:21# global-pid=3584 result=denied priority=0 / modify_policy task.pid=3584 task.ppid=3582 task.uid=0 task.gid=0 task.euid=0 task.egid=0 task.suid=0 task.sgid=0 task.fsuid=0 task.fsgid=0 task.type!=execute_handler task.exe="/bin/bash" task.domain="/usr/sbin/sshd"
This log is readable from /proc/caitsith/audit and is saved by caitsith-auditd program
103 How does audit log look like?
Below is a denied log generated by trying to modify policy configuration by bash. #2012/07/11 14:06:21# global-pid=3584 result=denied priority=0 / modify_policy task.pid=3584 task.ppid=3582 task.uid=0 task.gid=0 task.euid=0 task.egid=0 task.suid=0 task.sgid=0 task.fsuid=0 task.fsgid=0 task.type!=execute_handler task.exe="/bin/bash" task.domain="/usr/sbin/sshd"
Result is one of "allowed" or "denied" or "unmatched" This log was generated by "0 acl modify_policy" block
104 How does audit log look like?
Below is a denied log generated by trying to modify policy configuration by bash. #2012/07/11 14:06:21# global-pid=3584 result=denied priority=0 / modify_policy task.pid=3584 task.ppid=3582 task.uid=0 task.gid=0 task.euid=0 task.egid=0 task.suid=0 task.sgid=0 task.fsuid=0 task.fsgid=0 task.type!=execute_handler task.exe="/bin/bash" task.domain="/usr/sbin/sshd"
These are variables within the access request. These variables can be used as conditions as needed
105 How to update policy?
Trying to modify policy configuration by caitsith-loadpolicy will be allowed. # (echo '0 acl modify_policy'; echo '1 deny task.gid!=0') | /usr/sbin/caitsith-loadpolicy But an allowed log will not be generated. 0 acl modify_policy Doesn't match audit 1 Doesn't match 1 deny task.uid!=0 Matches 1 deny task.euid!=0 100 allow task.exe="/usr/sbin/caitsith-loadpolicy" 100 allow task.exe="/usr/sbin/caitsith-queryd" 10000 deny
106 How does user space daemon work? POLICY_VERSION=20120401 quota memory audit 16777216 quota memory query 1048576 quota audit[1] allowed=0 denied=1024 unmatched=1024
0 acl modify_policy Allow up to 1MB of kernel memory audit 1 for spooling access requests waiting for interactive judgment when 1 deny task.uid!=0 caitsith-queryd program is running 1 deny task.euid!=0 100 allow task.exe="/usr/sbin/caitsith-loadpolicy" 100 allow task.exe="/usr/sbin/caitsith-queryd" 10000 deny
107 How does user space daemon work? POLICY_VERSION=20120401 quota memory audit 16777216 quota memory query 1048576A denied log is generated and then access request is spooled for interactive judgment. If quota audit[1] allowed=0caitsith denied=1024-queryd allows, unmatched=1024 the permission check continues as if the access request did not match the "deny" line. The access request is 0 acl modify_policy denied otherwise audit 1 1 deny task.uid!=0 1 deny task.euid!=0 100 allow task.exe="/usr/sbin/caitsith-loadpolicy" 100 allow task.exe="/usr/sbin/caitsith-queryd" 10000 deny
108 How does user space daemon work?
Below is a query shown by caitsith-queryd program. #2012/07/11 14:06:21# global-pid=3584 result=denied priority=0 / modify_policy task.pid=3584 task.ppid=3582 task.uid=0 task.gid=0 task.euid=0 task.egid=0 task.suid=0 task.sgid=0 task.fsuid=0 task.fsgid=0 task.type!=execute_handler task.exe="/bin/bash" task.domain="/usr/sbin/sshd" Allow? ('Y'es/'N'o/'R'etry/'S'how policy/'A'dd to policy and retry):
Identical with audit log, except that a prompt line for manual decision is shown.
109 Characteristic points of proposed syntax
Supports both whitelisting approach and blacklisting approach.
1000 acl execute task.exe="/usr/sbin/httpd" audit 1 100 allow path="/var/www/cgi-bin/counter.cgi"
200 deny whitelisting approach ends with an unconditional "deny" line 2000 acl execute task.exe="/usr/sbin/httpd" audit 1 100 deny path="/bin/sh" 200 allow blacklisting approach ends with an unconditional "allow" line
110 Characteristic points of proposed syntax
Supports both the point of view of subjects and the point of view of objects, using actions as a key.
1000 acl execute task.exe="/usr/sbin/httpd" audit 1 100 allow path="/usr/sbin/suexec"
200 deny /usr/sbin/httpd can execute only /usr/sbin/suexec
2000 acl execute path="/usr/sbin/suexec" audit 1 100 allow task.exe="/usr/sbin/httpd" 200 deny /usr/sbin/suexec can be execute by only /usr/sbin/httpd 111 Characteristic points of proposed syntax
Supports both the point of view of subjects and the point of view of objects, using actions as a key.
1000 acl inet_stream_listen task.exe="/usr/sbin/sshd" audit 1 100 allow port=22
200 deny /usr/sbin/sshd can listen to TCP sockets at only port 22
2000 acl inet_stream_listen port=22 audit 1 100 allow task.exe="/usr/sbin/sshd" 200 deny TCP socket's port 22 can be listened by only /usr/sbin/sshd 112 Characteristic points of proposed syntax
Allows users to fully utilize TOMOYO's parameter validation capabilities. Check ioctl requests on /dev/kvm device
0 acl ioctl path.type=char path.dev_major=10 path.dev_minor=232 Only /usr/libexec/qemu-kvm can issue ioctl audit 1 requests on /dev/kvm device 100 deny task.exe!="/usr/libexec/qemu-kvm" 200 allow cmd=@PERMITTED_DEV_KVM_IOCTL_CMD_NUMBERS 300 deny
Only ioctl command numbers defined by "number_group PERMITTED_DEV_KVM_IOCTL_CMD_NUMBERS" lines in the header part of policy file are permitted
113 Characteristic points of proposed syntax
Allows users to apply single function restrictions like RWXfilter. Check TCP socket's Only port numbers defined by connect requests "number_group PERMITTED_INET_CONNECT_P 1000 acl inet_stream_connect ORTS" lines are permitted audit 1 100 deny port!=@PERMITTED_INET_CONNECT_PORTS 100 allow ip=@PERMITTED_INET_CONNECT_ADDRESSES 200 deny
Only IPv4/IPv6 addresses defined by "ip_group PERMITTED_INET_CONNECT_ADDRESSES" lines are permitted
114 Characteristic points of proposed syntax
Allows users to easily apply system wide restriction because action is the key.
100 acl mount Only /bin/mount can issue mount requests audit 1 0 deny task.exe!="/bin/mount" 1 allow target="/proc/" fstype="proc" flags=0x0 1 allow target="/sys/" fstype="sysfs" flags=0x0 1 allow target="/dev/pts/" fstype="devpts" flags=0x0 1 allow target="/dev/shm/" fstype="tmpfs" flags=0x0 1 allow target="/" fstype="--remount" flags=0x1 1 allow target="/" fstype="--remount" flags=0x400 2 deny
115 How to use CaitSith?
Installation steps are almost same with those of TOMOYO 1.8. Because CaitSith shares same kernel patches used by TOMOYO 1.8. Applying kernel patches is easy because most of hooks are already embedded into LSM.
Usage steps are (1) Define acl blocks you want to check (2) Edit decision lines in the blocks from audit logs (3) Terminate the blocks with unconditional deny (or allow) line
116 Please try CaitSith.
http://caitsith.sourceforge.jp/ Characteristic action inspection tool. See if this helps.
117