Milton Yates wrote: > > 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. > > Is this Data oriented security ? ;o)
Yes if you consider "Data" as content associated with file's pathnames. No if you consider "Data" as content associated with i-node objects. I think this new version is "Action" oriented security. Although the new version inherits some of TOMOYO's characteristic points (e.g. check various parameters which can be represented as string and numeric data), usage of the new version became completely different. I came to strongly feel that I should not call the new version TOMOYO. Otherwise, users and researchers who know TOMOYO shall be confused by the paradigm changes. Therefore, I decided to give the new version a new name and created a new project on SourceForge.jp. > > You can continue using TOMOYO 1.x/2.x if TOMOYO 1.x/2.x fits better. > > My question then is will TOMOYO 1.x/2.x be discontinued in the near > future? I'm not planning to discontinue TOMOYO 1.x/2.x in the near future. > So what general use cases do you think this new version will respond to? A developer who was interested in TOMOYO suggested us to (1) Implement as a loadable kernel module that can be added to RHEL4/5 kernels. (2) Allow use of blacklisting. As I have explained in "[tomoyo-users-en 220] AKARI 1.0 released." http://sourceforge.jp/projects/tomoyo/lists/archive/users-en/2010-October/000219.html , (1) was achieved as AKARI. (2) was achieved by inverting syntax from "what domain is allowed to do what action on what resource" to "what action on what resource is allowed by what domain". The syntax looked like below. read /path/to/file1 permissive by <kernel> /sbin/init /sbin/mingetty /bin/login /bin/bash by <kernel> /sbin/init /sbin/mingetty /bin/login /bin/bash /bin/cat write /path/to/file2 enforcing by <kernel> /sbin/init /sbin/mingetty /bin/login /bin/bash execute /path/to/file3 enforcing by <kernel> /sbin/init /sbin/mingetty /bin/login /bin/bash But the problem of this syntax was, it is difficult to specify domainnames correctly because there is no persistent list of domainnames. Without knowing the list of possible domainnames, it is impossible to write rules. I thought that it is a bothering task to understand possible domainnames when writing rules with this syntax. This new version was rewritten with changing from "what action on what resource is allowed by what domain" to "which action with what condition should be inspected and should be allowed/denied with what condition" (where condition consists with not only domainname but also various parameters), with another change that the domain transition does not happen unless explicitly defined (so that users will not be bothered by domainnames they do not know). The new version has an aspect of surveying how much user's needs are there with incomprehensive MAC implementation which was unpopular among security folks. Therefore, I named the new version "CaitSith" which stands for "Characteristic action inspection tool. See if this helps.". I'll move http://tomoyo.sourceforge.jp/testing/ to http://caitsith.sourceforge.jp/ . While CaitSith allows you to check (e.g.) only read/write/execute permissions, it also allows you to check more permissions if needed. For example, if you want to restrict read access of /etc/shadow and don't care diverted access, you can write only "read" rules acl read path="/etc/shadow" 0 allow .... 1 deny .... 2 allow .... 3 deny .... . If you want to also restrict diverted access as much as possible, you can write other rules (e.g. "rename"/"mount"). I tweet again; it is label based MAC which can restrict diverted access better. But CaitSith might be useful when resources are not rename()able ((e.g.) network address and port number). For example, you can write network rules like acl inet_stream_bind port=80 0 allow task.exe="/usr/sbin/httpd" 1 deny . Since management of domains became optional, acl execute task.exe="/usr/sbin/httpd" 0 allow path="/usr/bin/id" 0 allow path="/usr/sbin/suexec" 1 deny would deny execution of programs other than /usr/bin/id and /usr/sbin/suexec from /usr/sbin/httpd program and acl execute path="/usr/sbin/suexec" 0 allow task.exe="/usr/sbin/httpd" 1 deny would deny execution of /usr/sbin/suexec program from other than /usr/sbin/httpd program. In these examples, you don't need to care about domainname which /usr/sbin/httpd belongs to. > I was probably not clear enough on this. The idea would be that, instead > of having a set of ALLOW/AUDIT/DENY rules for _each_ resource operation > (so N acl to write), we could have a set of ALLOW/AUDIT/DENY of _many_ > resource operations at once (so 1 acl to write + the grouping of the > resources/operations). Grouping resources are supported by "string_group", (which is called "path_group" in TOMOYO 1.x/2.x), "number_group" and "ip_group" (which is called "address_group" in TOMOYO 1.x/2.x). But how do you plan to group operations (because acceptable conditions depend on operations)? For example, it is impossible to group like acl create/write/chmod/chown/chgrp/unlink/rename 0 allow path="/tmp/\{\*\}/\*" 1 allow perm=0644 2 allow task.uid=0 3 deny because variable "path" is not available to "rename" and variable "perm" is available to only "create" and "chmod" out of create/write/chmod/chown/chgrp/unlink/rename operations. > Sorry to keep pestering you about acl grouping, No problem. _______________________________________________ tomoyo-users-en mailing list [email protected] http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
