TOMOYO
ForkMilton Yates wrote:
> This seems to be a big change, a change that effectively changes the MAC
> paradigm of TOMOYO, where it will become more resource oriented and
> role-based.
Exactly. Since this is a big change, I feel that it may be no longer TOMOYO and
it should acquire a new name. But people are expecting me to keep the name
TOMOYO. Hmm...
TOMOYO is "ACL" based. But what does this "ACL" stand for?
"access control list"? "action control list"? "action check list"?
Traditionally, ACL stands for "access control list" and is associated with the
entity of resource (called i-node object). But the problem of "access control
list" is that it can describe only "who can read and/or write and/or execute
me". I agree that label based MAC implementations (e.g. SELinux and SMACK) can
control "who can read and/or write and/or execute me" better than name based
MAC implementations (e.g. TOMOYO and AppArmor). But I continued explicating
that "what side effects can happen if we failed to reject this request?"
Some examples of side effects:
If /var/www/html/.htaccess was renamed to /var/www/html/index.html , the
usage of the file's content will change although "who can read and/or write
and/or execute me" does not change.
If /sbin/init was renamed to /sbin/finalize , the system will no longer boot
although "who can read and/or write and/or execute me" does not change.
If /usr/sbin/sshd was executed with -o 'Banner /etc/shadow' command line
options, the content of /etc/shadow will be disclosed to unauthenticated ssh
clients although "who can read and/or write and/or execute me" does not
change.
These side effects cannot be avoided using "access control list" associated
with i-node object, for these side effects happen outside i-node object. Thus,
TOMOYO provided means to reject access requests as MAC implementation based on
knowledge of userspace, in order to avoid side effects as much as possible.
Since the knowledge is described in the form of string and number, TOMOYO is a
name based MAC and checks string and numeric parameters. (It seems to me that
AppArmor is now getting aware of this "outside i-node object" and is trying to
restrict (e.g.) environment variables.)
TOMOYO's "ACL" would stand for "action control list" or "action check list".
Then, what TOMOYO has been offering? There are two aspects.
One is ability to force domain transition patterns into tree form, in order
to distinguish contexts as fine-grained as possible.
The other is ability to enforce all processes from bootup till shutdown to do
only actions that are explicitly allowed by policy, in order to restrict
process's behaviour as much as possible.
The thoughts that offer these aspects are:
The major factor that determines security is the behaviour of user programs
and users. Therefore, we need to restrict behaviour of user programs and
users in order to prevent attackers from doing undesirable things (e.g.
abusing buffer overflow and OS command injection).
To restrict behaviour of user programs and users as much as possible,
we need to identify contexts as much as possible and allow only behaviours
that are essential to each context. Thus, we ask policy developers (e.g.
system administrators) enumerate all possible behaviour patterns. In exchange
of entailing the burden of enumerating all possible behaviour patterns in
the target system, we provide a sense of ease that access requests that do
not match possible behaviour patterns will not be allowed in the target
system. System administrators will accept the inevitable damages caused
within restrictions where only behaviours that are essential to each context
are allowed.
> My understanding after a first read of the documentation is that this
> new policy syntax will be great and make MUCH easier the creation of
> "allow all, tight control of a few resources" policies,
Yes. This change is targeted for people who don't want to be bothered by
additional process identifier (so-called "domains") used by MAC
implementations.
> especially in
> the context of phones like Android, it could be very powerful to protect
> your data and have fine grained access control over what process can
> access your marriage photos.
I think TOMOYO 1.x/2.x will fit better for Android, for Android is easier to
enumerate possible domain transition patterns than desktop and servers. One of
problems of TOMOYO 1.x/2.x is that it is impossible to enforce access control
without determining domain transition patterns. If you can determine domain
transition patterns, you will obtain a sense of ease that access requests that
do not match the domain transition patterns will not be allowed.
> But the fact that domain transitions are cut off, I understand we loose
> the domain chaining that enabled policy to change its behaviour based on
> execution ordering, which was powerful.
Domain transitions are still alive. I changed not to do domain transition by
default. Since the next version supports deny rule which allows use of
domainname as conditions, I considered that it is a safer choice not to do
domain transition unless explicitly asked to do so. Otherwise, users will
likely unexpectedly fail to match deny rule which uses domainnames.
> I have a hard time understanding how I could migrate my current policies
> to this model as it does not seem to fit.
You can continue using TOMOYO 1.x/2.x if TOMOYO 1.x/2.x fits better.
> My usage of TOMOYO is "allow
> all, tight control over processes and their behaviour on resources".
As I wrote above, the originally expected usage of TOMOYO was "tight control
over all processes and their behaviour on resources". If you can afford
enforcing all processes, it is the best utilization of power of TOMOYO.
> I would loose the order of execution control I had with current TOMOYO, or
> that would be limited to only one level if my understanding is correct.
Your understanding is correct. But if you can accept domain transition in
userspace, you can get similar domain transition chain
# ccs-pstree
init (1) /sbin/init
+- dhclient (2409) /etc/init.d/networking\000/sbin/ifup\000/bin/sh\000/sbin/dhclient
+- syslogd (2615) /sbin/syslogd
+- klogd (2618) /sbin/klogd
+- exim4 (2650) /usr/sbin/exim4
+- inetd (2656) /usr/sbin/inetd
+- nmbd (2660) /usr/sbin/nmbd
+- smbd (2662) /usr/sbin/smbd
+- smbd (2667) /usr/sbin/smbd
+- sshd (2669) /usr/sbin/sshd
+- sshd (2762) /usr/sbin/sshd
+- bash (2764) /usr/sbin/sshd\000/bin/bash
+- ccs-pstree (2794) /usr/sbin/sshd\000/bin/bash\000/usr/sbin/ccs-pstree
+- atd (2678) /usr/sbin/atd
+- cron (2682) /usr/sbin/cron
+- apache2 (2687) /usr/sbin/apache2
+- apache2 (2689) /usr/sbin/apache2
+- apache2 (2692) /usr/sbin/apache2
+- apache2 (2693) /usr/sbin/apache2
+- bash (2750) /sbin/getty\000/bin/login\000/bin/bash
+- getty (2751) /sbin/getty
+- getty (2752) /sbin/getty
+- getty (2753) /sbin/getty
+- getty (2754) /sbin/getty
+- getty (2755) /sbin/getty
by using execute handler functionality
0 acl execute task.type!=execute_handler
0 allow handler="/path/to/handler" transition=NULL
0 acl manual_domain_transition
0 allow task.type=execute_handler
1 deny
and let /path/to/handler to do
read from /proc/ccs/self_domain
append "\000" + "name of requested program"
write to /proc/ccs/self_domain
execute "requested program"
(using http://sourceforge.jp/projects/tomoyo/svn/view/branches/domain-transition-delegation-example.c?root=tomoyo&revision=5960&content-type=text%2Fplain&pathrev=5960
as a proof-of-concept execute handler program).
> I guess some more sample policies would be neat to have in the
> documentation. (Possible example: how to restrict wget so he gets RO
> access to /usr/lib/lib*.so (needed libs) and RW access to
> /home/\*/Download/\* only, and could not do anything else)
Of course I will add more examples.
> Other point, I think the grouping issue we discussed before would still
> apply here. For example we could have:
> $acl_priority aclgroup $groupname
> audit $audit_index
> $cond_priority $decision $conditions_to_allow_or_deny
>
>
> with a definition of the aclgroup somewhere, like:
>
> aclgroup $groupname
> $acl_priority acl $operation1 $conditions_to_filter
> $acl_priority acl $operation2 $conditions_to_filter
> $acl_priority acl $operation3 $conditions_to_filter
> $acl_priority acl $operation4 $conditions_to_filter
> $acl_priority acl $operation5 $conditions_to_filter
> $acl_priority acl $operation6 $conditions_to_filter
> $acl_priority acl $operation7 $conditions_to_filter
Since parameters which can be checked as conditions depend on operation,
$operation1 == $operation2 == $operation3 == $operation4 == $operation5 ==
$operation6 == $operation7 is required.
As a result, it will look something like
aclgroup $operation $groupname
$acl_priority acl $conditions_to_filter
$acl_priority acl $conditions_to_filter
$acl_priority acl $conditions_to_filter
$acl_priority acl $conditions_to_filter
$acl_priority acl $conditions_to_filter
$acl_priority acl $conditions_to_filter
$acl_priority acl $conditions_to_filter
and becomes more simplified
aclgroup $operation $groupname $conditions_to_filter
and becomes after all
$acl_priority acl $conditions_to_filter
.