From jamie at tomoyolinux.co.uk Sat Aug 20 06:20:26 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Fri, 19 Aug 2011 22:20:26 +0100 Subject: [tomoyo-dev-en 304] ccs-editpolicy display of exception policy Message-ID: Hi Tetsuo, When initializing a fresh set of policy, I noticed a difference in how ccs-editpolicy (from latest 1.8.x release) displays exception policy. It changes depending on whether there is one namespace or more than one namespace. If there is only one namespace, then the exception policy screen looks like this: acl_group 0 file read @STUFF acl_group 0 file write @STUFF acl_group 0 file append @STUFF If there is more than one namespace, then similar lines are concatenated and the exception policy screen looks like this: acl_group 0 file read/write/append @STUFF Which one is the intended way to display? I'm guessing you meant for similar lines to always be concatenated regardless of how many namespaces there are. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Sat Aug 20 11:28:03 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 20 Aug 2011 11:28:03 +0900 Subject: [tomoyo-dev-en 305] Re: ccs-editpolicy display of exception policy In-Reply-To: References: Message-ID: <201108201128.FGF43206.PWtFGPtSPZEPOUNNtF@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > When initializing a fresh set of policy, I noticed a difference in how > ccs-editpolicy (from latest 1.8.x release) displays exception policy. > It changes depending on whether there is one namespace or more than > one namespace. Oops, I forgot to skip <$namespace> prefix. Fixed in revision 5355. Thank you. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Sat Aug 20 19:54:07 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 20 Aug 2011 19:54:07 +0900 Subject: [tomoyo-dev-en 306] Re: Documentation In-Reply-To: References: <201105160707.p4G77kSh085408@www262.sakura.ne.jp> <201105170552.p4H5qUkQ055635@www262.sakura.ne.jp> Message-ID: <201108201954.HBE39081.tPPNWUZGOFEtPSNPFt@I-love.SAKURA.ne.jp> I noticed that pages in tags/htdocs/news/ are almost copy&paste and have little amount of actual text. Therefore, I think merging these pages into tags/htdocs/news.html.en (like tags/htdocs/news2.html.en in revision 5364) would be nice. What do you think? From jamie at tomoyolinux.co.uk Sat Aug 20 20:20:44 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sat, 20 Aug 2011 12:20:44 +0100 Subject: [tomoyo-dev-en 307] Re: Documentation In-Reply-To: <201108201954.HBE39081.tPPNWUZGOFEtPSNPFt@I-love.SAKURA.ne.jp> References: <201105160707.p4G77kSh085408@www262.sakura.ne.jp> <201105170552.p4H5qUkQ055635@www262.sakura.ne.jp> <201108201954.HBE39081.tPPNWUZGOFEtPSNPFt@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > I noticed that pages in tags/htdocs/news/ are almost copy&paste and have little > amount of actual text. Therefore, I think merging these pages into > tags/htdocs/news.html.en (like tags/htdocs/news2.html.en in revision 5364) > would be nice. What do you think? My original reason for putting news into separate items under tags/htdocs/news/ was so that the archive didn't become a really really long page (but since we only have 1 or 2 new items a month it's not a huge problem). What do you plan to do when news2.html.en becomes too long? I suppose we could split it into two or more pages when it gets too long, but that's harder to do when not using a CMS or database. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Sat Aug 20 20:28:12 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 20 Aug 2011 20:28:12 +0900 Subject: [tomoyo-dev-en 308] Re: Documentation In-Reply-To: References: <201105170552.p4H5qUkQ055635@www262.sakura.ne.jp> <201108201954.HBE39081.tPPNWUZGOFEtPSNPFt@I-love.SAKURA.ne.jp> Message-ID: <201108202028.HCD35926.NWtSUFNPPOZFtEGPPt@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > What do you plan to do when news2.html.en becomes too long? I suppose > we could split it into two or more pages when it gets too long, I think splitting news.html into news-YYYY.html is sufficient. From jamie at tomoyolinux.co.uk Sat Aug 20 20:55:54 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sat, 20 Aug 2011 12:55:54 +0100 Subject: [tomoyo-dev-en 309] Re: Documentation In-Reply-To: <201108202028.HCD35926.NWtSUFNPPOZFtEGPPt@I-love.SAKURA.ne.jp> References: <201105170552.p4H5qUkQ055635@www262.sakura.ne.jp> <201108201954.HBE39081.tPPNWUZGOFEtPSNPFt@I-love.SAKURA.ne.jp> <201108202028.HCD35926.NWtSUFNPPOZFtEGPPt@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > I think splitting news.html into news-YYYY.html is sufficient. Sounds good :-) From haradats at gmail.com Sat Aug 20 20:58:02 2011 From: haradats at gmail.com (Toshiharu Harada) Date: Sat, 20 Aug 2011 20:58:02 +0900 Subject: [tomoyo-dev-en 310] Re: Documentation In-Reply-To: <201108201954.HBE39081.tPPNWUZGOFEtPSNPFt@I-love.SAKURA.ne.jp> References: <201105160707.p4G77kSh085408@www262.sakura.ne.jp> <201105170552.p4H5qUkQ055635@www262.sakura.ne.jp> <201108201954.HBE39081.tPPNWUZGOFEtPSNPFt@I-love.SAKURA.ne.jp> Message-ID: 2011/8/20 Tetsuo Handa : > I noticed that pages in tags/htdocs/news/ are almost copy&paste and have little > amount of actual text. Therefore, I think merging these pages into > tags/htdocs/news.html.en (like tags/htdocs/news2.html.en in revision 5364) > would be nice. What do you think? Yes, I noticed the same thing a while ago... Let me remind that Freshmeat site has a feature for announcing releases with RSS feeds. http://freshmeat.net/projects/tomoyo/releases IMHO, putting the above link in the project page is sufficient and useful for readers. Regards, Toshiharu Harada haradats ?? gmail.com From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Fri Aug 26 21:06:21 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Fri, 26 Aug 2011 21:06:21 +0900 Subject: [tomoyo-dev-en 311] "file execute" directive with optional "destination domain" argument. Message-ID: <201108262106.BBF69205.FPNZPNEtPWtFtPUSOG@I-love.SAKURA.ne.jp> I got an opinion that it is difficult to use exception policy's domain transition control directives because they need to match the pathname specified to "file execute" directives when selectively pick up. For example, if "file execute /bin/\*\-ls\-cat" is given, corresponding domain transition control directive needs to be like "no_keep_domain /bin/\*\-ls\-cat from any". As a currently available solution, I suggested to map such pathnames to something else using "aggregator" directive. But, if we can specify like below, it will become more convenient. file execute /bin/ls keep exec.realpath="/bin/ls" exec.argv[0]="ls" file execute /bin/cat keep exec.realpath="/bin/cat" exec.argv[0]="cat" file execute /bin/\*\-ls\-cat child file execute /usr/sbin/httpd exec.realpath="/usr/sbin/httpd" exec.argv[0]="/usr/sbin/httpd" In above examples, "keep" works as if keep_domain is specified, "child" works as if "no_reset_domain" and "no_initialize_domain" and "no_keep_domain" are specified, "" causes domain transition to domain upon successful execve() operation. For compatibility, this argument is omissible. If omitted, destination domain is calculated based on exception policy's domain transition control directives. file execute /bin/ls exec.realpath="/bin/ls" exec.argv[0]="ls" In order to avoid conflicts with conditional keywords, keyword for this argument can be one of below keep (for keeping current domain.) initialize (for initializing domain transition.) reset (for resetting domain transition.) $domainname (for jumping to specified domain. $domainname can be for example " /app1 /section1" because TOMOYO 1.8 can parse "ipc signal $signum $domainname $conditions" "task auto_domain_transition $domainname $conditions" "task manual_domain_transition $domainname $conditions" lines without problems because of domainname constraints.) and below keywords might be useful in addition to above. child (for jumping to current domain's child domain.) parent (for jumping to current domain's parent domain.) default (for calculating destination domain using exception policy's domain transition control directives.) If this argument was specified, execve() will fail if domain transition has failed, for I think this argument should be manually specified with destination domains explicitly defined. What do you think? From jamie at tomoyolinux.co.uk Sat Aug 27 06:19:54 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Fri, 26 Aug 2011 22:19:54 +0100 Subject: [tomoyo-dev-en 312] Re: "file execute" directive with optional "destination domain" argument. In-Reply-To: <201108262106.BBF69205.FPNZPNEtPWtFtPUSOG@I-love.SAKURA.ne.jp> References: <201108262106.BBF69205.FPNZPNEtPWtFtPUSOG@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > I got an opinion that it is difficult to use exception policy's domain > transition control directives because they need to match the pathname specified > to "file execute" directives when selectively pick up. For example, if > "file execute /bin/\*\-ls\-cat" is given, corresponding domain transition > control directive needs to be like "no_keep_domain /bin/\*\-ls\-cat from any". Just need to make sure I understand correctly. The aim in the example you gave is to prevent executions of /bin/ls and /bin/cat from undergoing domain transition, but allowing executions of everything else in /bin/ to undergo domain transition. The current situation is that in domain policy we can have: file execute /bin/cat file execute /bin/ls file execute /bin/\*\-ls\-cat and in exception policy we can have: keep_domain /bin/cat from any keep_domain /bin/ls from any no_initialize_domain /bin/\*\-ls\-cat from any no_keep_domain /bin/\*\-ls\-cat from any no_reset_domain /bin/\*\-ls\-cat from any and the domain tree will look like: /usr/bin/foo /bin/\*\-ls\-cat If we apply the suggested changes, in domain policy we then can have: file execute /bin/ls keep file execute /bin/cat keep file execute /bin/\*\-ls\-cat child and there is no need to add anything to exception policy, and the domain tree will look exactly like above. Is my understanding correct? From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Sat Aug 27 07:45:56 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 27 Aug 2011 07:45:56 +0900 Subject: [tomoyo-dev-en 313] Re: "file execute" directive with optional"destination domain" argument. In-Reply-To: References: <201108262106.BBF69205.FPNZPNEtPWtFtPUSOG@I-love.SAKURA.ne.jp> Message-ID: <201108270745.CFH69742.FtFWtUNPSPPPGZNEtO@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > Is my understanding correct? Yes. > and there is no need to add anything to exception policy, and the > domain tree will look exactly like above. Domain transition control directives in exception policy are evaluated only when '"file execute" entry which matches the request was not found' or 'a "file execute" entry which matches the request was found but the matched entry does not have this optional argument'. From jamie at tomoyolinux.co.uk Sat Aug 27 08:28:17 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sat, 27 Aug 2011 00:28:17 +0100 Subject: [tomoyo-dev-en 314] Re: "file execute" directive with optional"destination domain" argument. In-Reply-To: <201108270745.CFH69742.FtFWtUNPSPPPGZNEtO@I-love.SAKURA.ne.jp> References: <201108262106.BBF69205.FPNZPNEtPWtFtPUSOG@I-love.SAKURA.ne.jp> <201108270745.CFH69742.FtFWtUNPSPPPGZNEtO@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > Jamie Nguyen wrote: >> Is my understanding correct? > > Yes. Great. While I have no firm objections, here are some of my initial thoughts. In the example I gave, 5 lines are saved from exception policy. This is good, but personally, I find exception policy to be very powerful and I use it whenever possible. Supposing you have "keep_domain /bin/cat from any" in exception policy. If you change your mind and then want /bin/cat to cause a domain transition in many domains, it is a matter of deleting a single line. Supposing instead that you have "file execute /bin/cat keep" in many domains, changing your mind in this case requires many lines to be changed. A simple sed could be used of course, but the point I'm making is the convenience of exception policy. Correct me if I'm wrong, but two of the main reasons for the creation exception policy are for the centralization of policy and for the convenience of making changes to many domains. For example, instead of having "/dev/sr0" in many domains, you can have "@DVD_DRIVE" instead and only have to change one entry in exception policy if the device ever changes. Without centralizing into exception policy, many lines are required to be changed. Again, a simple sed could be used, but I personally feel that (in the interests of code simplicity) the addition of more directives/arguments/options into domain policy is not necessary when exception policy is coping just fine. Having said that, I'm ready to be convinced otherwise ;-) From haradats at gmail.com Sat Aug 27 08:56:49 2011 From: haradats at gmail.com (Toshiharu Harada) Date: Sat, 27 Aug 2011 08:56:49 +0900 Subject: [tomoyo-dev-en 315] Re: "file execute" directive with optional"destination domain" argument. In-Reply-To: References: <201108262106.BBF69205.FPNZPNEtPWtFtPUSOG@I-love.SAKURA.ne.jp> <201108270745.CFH69742.FtFWtUNPSPPPGZNEtO@I-love.SAKURA.ne.jp> Message-ID: Jamie's summary helped me. Thanks a lot >Jamie I have no firm objections as Jamie, either. But I've been wondering if TOMOYO really needs new directives while "aggregator" is available. I assume the new suggestions include several different purposes/advantages. What seems to be most important to you? >Tetsuo (Eliminating needs to synchronize the exception policy? I guess) 2011/8/27 Jamie Nguyen : > Tetsuo Handa wrote: >> Jamie Nguyen wrote: >>> Is my understanding correct? >> >> Yes. > > Great. While I have no firm objections, here are some of my initial thoughts. > > In the example I gave, 5 lines are saved from exception policy. This > is good, but personally, I find exception policy to be very powerful > and I use it whenever possible. Supposing you have "keep_domain > /bin/cat from any" in exception policy. If you change your mind and > then want /bin/cat to cause a domain transition in many domains, it is > a matter of deleting a single line. Supposing instead that you have > "file execute /bin/cat keep" in many domains, changing your mind in > this case requires many lines to be changed. A simple sed could be > used of course, but the point I'm making is the convenience of > exception policy. > > Correct me if I'm wrong, but two of the main reasons for the creation > exception policy are for the centralization of policy and for the > convenience of making changes to many domains. For example, instead of > having "/dev/sr0" in many domains, you can have "@DVD_DRIVE" instead > and only have to change one entry in exception policy if the device > ever changes. Without centralizing into exception policy, many lines > are required to be changed. Again, a simple sed could be used, but I > personally feel that (in the interests of code simplicity) the > addition of more directives/arguments/options into domain policy is > not necessary when exception policy is coping just fine. > > Having said that, I'm ready to be convinced otherwise ;-) >From another "ready to be convinced". :-) From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Sat Aug 27 15:01:53 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 27 Aug 2011 15:01:53 +0900 Subject: [tomoyo-dev-en 316] Re: "file execute" directive withoptional"destination domain" argument. In-Reply-To: References: <201108262106.BBF69205.FPNZPNEtPWtFtPUSOG@I-love.SAKURA.ne.jp> <201108270745.CFH69742.FtFWtUNPSPPPGZNEtO@I-love.SAKURA.ne.jp> Message-ID: <201108271501.GGI04618.WUOFPNPNttZtPESPGF@I-love.SAKURA.ne.jp> Toshiharu Harada wrote: > I assume the new suggestions include several > different purposes/advantages. What seems to be most > important to you? >Tetsuo (Eliminating needs to synchronize the > exception policy? I guess) Advantage 1: /usr/sbin/sshd file execute /bin/bash /usr/sbin/sshd //batch-session exec.argc=2 exec.argv[1]="-c" file execute /bin/bash /usr/sbin/sshd //root-session task.uid=0 file execute /bin/bash /usr/sbin/sshd //nonroot-session task.uid!=0 will allow transition to different domains based on conditions. Advantage 2: file execute /tmp/logrotate.\?\?\?\?\?\? will allow executing /tmp/logrotate.\?\?\?\?\?\? in domain without defining "aggregator /tmp/logrotate.\?\?\?\?\?\? /tmp/logrotate.tmp". Advantage 3: If we use "aggregator" entry, it affects all domains in the same namespace. It may not be always preferable when the "aggregator" matches many pathnames. For example, if we want to allow execution of /bin/\* other than /bin/su , aggregator /bin/\*\-su //bin-except-su /usr/sbin/sshd /bin/bash file execute //bin-except-su will allow it. But, within the same namespace, if we want to allow execution of /bin/\* other than /bin/su and /bin/ping , aggregator /bin/\*\-su\-ping //bin-except-su-and-ping /usr/sbin/sshd /bin/tcsh file execute //bin-except-su-and-ping will allow it. However, if the order is aggregator /bin/\*\-su //bin-except-su aggregator /bin/\*\-su\-ping //bin-except-su-and-ping /bin/ls from /usr/sbin/sshd /bin/bash domain will succeed whereas /bin/ls from /usr/sbin/sshd /bin/tcsh domain will fail because /bin/ls will match //bin-except-su . Likewise, if the order is aggregator /bin/\*\-su\-ping //bin-except-su-and-ping aggregator /bin/\*\-su //bin-except-su /bin/ls from /usr/sbin/sshd /bin/tcsh domain will succeed whereas /bin/ls from /usr/sbin/sshd /bin/bash domain will fail because /bin/ls will match //bin-except-su bin-except-su-and-ping . If we use /usr/sbin/sshd /bin/bash file execute /bin/\*\-su /usr/sbin/sshd /bin/bash //bin-except-su /usr/sbin/sshd /bin/tcsh file execute /bin/\*\-su\-ping /usr/sbin/sshd /bin/tcsh //bin-except-su-and-ping both /bin/ls from /usr/sbin/sshd /bin/tcsh domain and /bin/ls from /usr/sbin/sshd /bin/bash domain will succeed because we don't need to use "aggregator". Advantage 4: Well, advantage 3 may be false because we have "path_group". path_group group_for_bash /bin/\*\-su path_group group_for_tcsh /bin/\*\-su\-ping /usr/sbin/sshd /bin/bash file execute @group_for_bash /usr/sbin/sshd /bin/tcsh file execute @group_for_tcsh But /usr/sbin/sshd /bin/bash file execute @group_for_bash keep /usr/sbin/sshd /bin/tcsh file execute @group_for_tcsh keep will save us from writing no_initialize_domain /bin/\*\-su from /usr/sbin/sshd /bin/bash no_initialize_domain /bin/\*\-su\-ping from /usr/sbin/sshd /bin/tcsh no_reset_domain /bin/\*\-su from /usr/sbin/sshd /bin/bash no_reset_domain /bin/\*\-su\-ping from /usr/sbin/sshd /bin/tcsh delete no_keep_domain /bin/\*\-su from /usr/sbin/sshd /bin/bash delete no_keep_domain /bin/\*\-su\-ping from /usr/sbin/sshd /bin/tcsh keep_domain /bin/\*\-su from /usr/sbin/sshd /bin/bash keep_domain /bin/\*\-su\-ping from /usr/sbin/sshd /bin/tcsh to exception policy. From jamie at tomoyolinux.co.uk Mon Aug 29 04:19:02 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sun, 28 Aug 2011 20:19:02 +0100 Subject: [tomoyo-dev-en 317] Re: "file execute" directive withoptional"destination domain" argument. In-Reply-To: <201108271501.GGI04618.WUOFPNPNttZtPESPGF@I-love.SAKURA.ne.jp> References: <201108262106.BBF69205.FPNZPNEtPWtFtPUSOG@I-love.SAKURA.ne.jp> <201108270745.CFH69742.FtFWtUNPSPPPGZNEtO@I-love.SAKURA.ne.jp> <201108271501.GGI04618.WUOFPNPNttZtPESPGF@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > Advantage 1: > ... Thanks very much for the write up Tetsuo. I'm not sure that I am convinced by the advantages. I agree with Toshiharu that the "aggregator" directive is available for dealing with these kind of scenarios. If there were no way to solve problems using currently existing directives, I would be more than happy for new directives to be added. But since the new directives aren't making any new things possible or making any new problems solvable, I'm reluctant to see them added. We already have many directives, and they all serve their purpose well. If we are considering adding more directives, then I want to be able to say "wow, that would be really useful" (like for example the addition of namespaces), but the scenarios above can already be solved using existing directives. There is some added convenience, but it is small compared to the added complexity. I'd rather see tomoyo take the "simple" approach here and just stick with what we already have. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Mon Aug 29 07:17:59 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 29 Aug 2011 07:17:59 +0900 Subject: [tomoyo-dev-en 318] Re: "file execute" directivewithoptional"destination domain" argument. In-Reply-To: References: <201108270745.CFH69742.FtFWtUNPSPPPGZNEtO@I-love.SAKURA.ne.jp> <201108271501.GGI04618.WUOFPNPNttZtPESPGF@I-love.SAKURA.ne.jp> Message-ID: <201108290717.FBF30284.GtNFFEtPSPtUZPOPNW@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > But since the new directives aren't making any new things possible or making > any new problems solvable, I'm reluctant to see them added. Well, at least, advantage 1 is made possible by this optional argument. Until now, there was no way to transit to different domains depending on command line arguments/environment variables/process's credentials passed to execve() request (unless we use "task manual_domain_transition" from a program executed by "task auto_execute_handler"). An alternative approach to make advantage 1 possible is to expand domain transition control directives in exception policy like transit_domain /usr/sbin/sshd //batch-session upon /bin/sh from any if exec.argc=2 exec.argv[1]="-c" . (If we take alternative approach, we might be able to change from reset_namespace /usr/sbin/sshd from any to transit_domain upon /usr/sbin/sshd from any if task.uid=0 .) Also, advantage 3 solves ordering problem caused by use of "aggregator" directive. Advantage 4 simplifies exception policy by removing lines (e.g. no_initialize_domain /usr/sbin/sendmail from /var/www/cgi-bin/mailform.cgi that applies to only /var/www/cgi-bin/mailform.cgi domain). This proposal makes it possible to specify domain transition more precisely without adding domain transition control directives to exception policy. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Mon Aug 29 10:16:23 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 29 Aug 2011 10:16:23 +0900 Subject: [tomoyo-dev-en 319] Re: "file execute" directivewithoptional"destination domain" argument. In-Reply-To: <201108290717.FBF30284.GtNFFEtPSPtUZPOPNW@I-love.SAKURA.ne.jp> References: <201108270745.CFH69742.FtFWtUNPSPPPGZNEtO@I-love.SAKURA.ne.jp> <201108271501.GGI04618.WUOFPNPNttZtPESPGF@I-love.SAKURA.ne.jp> <201108290717.FBF30284.GtNFFEtPSPtUZPOPNW@I-love.SAKURA.ne.jp> Message-ID: <201108290116.p7T1GNic018601@www262.sakura.ne.jp> Tetsuo Handa wrote: > This proposal makes it possible to specify domain transition more precisely > without adding domain transition control directives to exception policy. One more thing. It is one of TOMOYO's characteristic features that "any process transits to child of current domain upon execve() unless explicitly specified using domain transition control directives in exception policy (and TOMOYO creates domains automatically if the domain to transit to does not exist in order not to reject execve() requests unless enforcing mode is specified)". This feature is useful when analyzing a system's behavior because it does not ask the user to beforehand have knowledge of what applications are installed in the target system and how they behave. But after the user obtained knowledge of what applications are installed in the target system and how they behave, the user designs how domains (and optionally namespaces) should be divided and modifies domain transition control entries in exception policy. At this moment, the user will be able to specify "how domain transition should be applied upon executing this program" to each "file execute" entry (if my proposal is implemented) instead of modifying domain transition control entries in exception policy. If the user wants to apply enforcing mode to the entire system (e.g. Android), the user will be able to specify "how domain transition should be applied upon execve()" to each "file execute" entry and remove all domain transition control entries in exception policy (because all "file execute" entries and domain transition patterns need to be identified and explicitly specified in order to apply enforcing mode to the entire system). Also, the user will be able to remove all "aggregator" entries in exception policy (because the user can specify like path_group EDITORS /bin/vi path_group EDITORS /usr/bin/emacs file execute @EDITORS ). We can remove "aggregator"/"reset_domain"/"no_reset_domain"/"initialize_domain" /"no_initialize_domain"/"keep_domain"/"no_keep_domain" if the user is skillful enough to specify all "file execute" entries and enforce them (in other words, figure out all domains and programs for each domain). After all, "aggregator"/"reset_domain"/"no_reset_domain"/"initialize_domain"/ "no_initialize_domain"/"keep_domain"/"no_keep_domain" are essential for users who don't want to specify all "file execute" entries, but are optional for users who can specify all "file execute" entries. I'm not proposing removal of "aggregator"/"reset_domain"/"no_reset_domain"/ "initialize_domain"/"no_initialize_domain"/"keep_domain"/"no_keep_domain" directives. My proposal is for experts who can live without these directives. From jamie at tomoyolinux.co.uk Wed Aug 31 17:48:30 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Wed, 31 Aug 2011 09:48:30 +0100 Subject: [tomoyo-dev-en 320] Re: "file execute" directivewithoptional"destination domain" argument. In-Reply-To: <201108290116.p7T1GNic018601@www262.sakura.ne.jp> References: <201108270745.CFH69742.FtFWtUNPSPPPGZNEtO@I-love.SAKURA.ne.jp> <201108271501.GGI04618.WUOFPNPNttZtPESPGF@I-love.SAKURA.ne.jp> <201108290717.FBF30284.GtNFFEtPSPtUZPOPNW@I-love.SAKURA.ne.jp> <201108290116.p7T1GNic018601@www262.sakura.ne.jp> Message-ID: Tetsuo Handa wrote: > It is one of TOMOYO's characteristic features that "any process transits to > child of current domain upon execve() unless explicitly specified using domain > transition control directives in exception policy (and TOMOYO creates domains > automatically if the domain to transit to does not exist in order not to reject > execve() requests unless enforcing mode is specified)". This feature is useful > when analyzing a system's behavior because it does not ask the user to > beforehand have knowledge of what applications are installed in the target > system and how they behave. > > But after the user obtained knowledge of what applications are installed in the > target system and how they behave, the user designs how domains (and optionally > namespaces) should be divided and modifies domain transition control entries > in exception policy. At this moment, the user will be able to specify "how > domain transition should be applied upon executing this program" to each "file > execute" entry (if my proposal is implemented) instead of modifying domain > transition control entries in exception policy. > > If the user wants to apply enforcing mode to the entire system (e.g. Android), > the user will be able to specify "how domain transition should be applied upon > execve()" to each "file execute" entry and remove all domain transition control > entries in exception policy (because all "file execute" entries and domain > transition patterns need to be identified and explicitly specified in order to > apply enforcing mode to the entire system). Also, the user will be able to > remove all "aggregator" entries in exception policy (because the user can > specify like > > ?path_group EDITORS /bin/vi > ?path_group EDITORS /usr/bin/emacs > > ?file execute @EDITORS > > ). > > We can remove "aggregator"/"reset_domain"/"no_reset_domain"/"initialize_domain" > /"no_initialize_domain"/"keep_domain"/"no_keep_domain" if the user is skillful > enough to specify all "file execute" entries and enforce them (in other words, > figure out all domains and programs for each domain). > > After all, "aggregator"/"reset_domain"/"no_reset_domain"/"initialize_domain"/ > "no_initialize_domain"/"keep_domain"/"no_keep_domain" are essential for users > who don't want to specify all "file execute" entries, but are optional for > users who can specify all "file execute" entries. > > I'm not proposing removal of "aggregator"/"reset_domain"/"no_reset_domain"/ > "initialize_domain"/"no_initialize_domain"/"keep_domain"/"no_keep_domain" > directives. My proposal is for experts who can live without these directives. Your proposal is growing on me. I think I can see this being put to good use. Might I ask what you personally feel are the disadvantages of your proposal? If you see no major problems, then I have no firm objections. In your first post you seemed maybe a little unsure, but now you seem very sure. I trust your opinion here, and you've fought your side of the debate well :-) From haradats at nttdata.co.jp Wed Aug 31 18:15:34 2011 From: haradats at nttdata.co.jp (Toshiharu Harada) Date: Wed, 31 Aug 2011 18:15:34 +0900 Subject: [tomoyo-dev-en 321] Re: "file execute" directive withoptional"destination domain" argument. In-Reply-To: <201108271501.GGI04618.WUOFPNPNttZtPESPGF@I-love.SAKURA.ne.jp> References: <201108262106.BBF69205.FPNZPNEtPWtFtPUSOG@I-love.SAKURA.ne.jp> <201108270745.CFH69742.FtFWtUNPSPPPGZNEtO@I-love.SAKURA.ne.jp> <201108271501.GGI04618.WUOFPNPNttZtPESPGF@I-love.SAKURA.ne.jp> Message-ID: <4E5DFBB6.2020207@nttdata.co.jp> (2011/08/27 15:01), Tetsuo Handa wrote: > Toshiharu Harada wrote: >> I assume the new suggestions include several >> different purposes/advantages. What seems to be most >> important to you?>Tetsuo (Eliminating needs to synchronize the >> exception policy? I guess) Thanks a lot for the in depth information. Now things are much cleaner for me. > Advantage 1: > > /usr/sbin/sshd > file execute /bin/bash /usr/sbin/sshd //batch-session exec.argc=2 exec.argv[1]="-c" > file execute /bin/bash /usr/sbin/sshd //root-session task.uid=0 > file execute /bin/bash /usr/sbin/sshd //nonroot-session task.uid!=0 > > will allow transition to different domains based on conditions. > > Advantage 2: > > file execute /tmp/logrotate.\?\?\?\?\?\? > > will allow executing /tmp/logrotate.\?\?\?\?\?\? in domain > without defining "aggregator /tmp/logrotate.\?\?\?\?\?\? /tmp/logrotate.tmp". > > Advantage 3: > > If we use "aggregator" entry, it affects all domains in the same namespace. > It may not be always preferable when the "aggregator" matches many pathnames. > > For example, if we want to allow execution of /bin/\* other than /bin/su , > > aggregator /bin/\*\-su //bin-except-su > > /usr/sbin/sshd /bin/bash > file execute //bin-except-su > > will allow it. But, within the same namespace, if we want to allow execution > of /bin/\* other than /bin/su and /bin/ping , > > aggregator /bin/\*\-su\-ping //bin-except-su-and-ping > > /usr/sbin/sshd /bin/tcsh > file execute //bin-except-su-and-ping > > will allow it. However, if the order is > > aggregator /bin/\*\-su //bin-except-su > aggregator /bin/\*\-su\-ping //bin-except-su-and-ping > > /bin/ls from /usr/sbin/sshd /bin/bash domain will succeed whereas > /bin/ls from /usr/sbin/sshd /bin/tcsh domain will fail because > /bin/ls will match //bin-except-su . Likewise, if the order is > > aggregator /bin/\*\-su\-ping //bin-except-su-and-ping > aggregator /bin/\*\-su //bin-except-su > > /bin/ls from /usr/sbin/sshd /bin/tcsh domain will succeed whereas > /bin/ls from /usr/sbin/sshd /bin/bash domain will fail because > /bin/ls will match //bin-except-su bin-except-su-and-ping . > > If we use > > /usr/sbin/sshd /bin/bash > file execute /bin/\*\-su /usr/sbin/sshd /bin/bash //bin-except-su > > /usr/sbin/sshd /bin/tcsh > file execute /bin/\*\-su\-ping /usr/sbin/sshd /bin/tcsh //bin-except-su-and-ping > > both /bin/ls from /usr/sbin/sshd /bin/tcsh domain and > /bin/ls from /usr/sbin/sshd /bin/bash domain will succeed because > we don't need to use "aggregator". Advantages 1 and 2 look pretty intuitive and I liked them. And disadvantages mentioned in 3 appeared to be persuasive to me. > Advantage 4: > > Well, advantage 3 may be false because we have "path_group". > > path_group group_for_bash /bin/\*\-su > path_group group_for_tcsh /bin/\*\-su\-ping > > /usr/sbin/sshd /bin/bash > file execute @group_for_bash > > /usr/sbin/sshd /bin/tcsh > file execute @group_for_tcsh > > But > > /usr/sbin/sshd /bin/bash > file execute @group_for_bash keep > > /usr/sbin/sshd /bin/tcsh > file execute @group_for_tcsh keep > > will save us from writing > > no_initialize_domain /bin/\*\-su from /usr/sbin/sshd /bin/bash > no_initialize_domain /bin/\*\-su\-ping from /usr/sbin/sshd /bin/tcsh > no_reset_domain /bin/\*\-su from /usr/sbin/sshd /bin/bash > no_reset_domain /bin/\*\-su\-ping from /usr/sbin/sshd /bin/tcsh > delete no_keep_domain /bin/\*\-su from /usr/sbin/sshd /bin/bash > delete no_keep_domain /bin/\*\-su\-ping from /usr/sbin/sshd /bin/tcsh > keep_domain /bin/\*\-su from /usr/sbin/sshd /bin/bash > keep_domain /bin/\*\-su\-ping from /usr/sbin/sshd /bin/tcsh > > to exception policy. Looks just nice. :-) So, let me say, "I am convinced". Best regards, Toshiharu Harada From jamie at tomoyolinux.co.uk Wed Aug 31 18:18:26 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Wed, 31 Aug 2011 10:18:26 +0100 Subject: [tomoyo-dev-en 322] Re: "file execute" directive withoptional"destination domain" argument. In-Reply-To: <4E5DFBB6.2020207@nttdata.co.jp> References: <201108262106.BBF69205.FPNZPNEtPWtFtPUSOG@I-love.SAKURA.ne.jp> <201108270745.CFH69742.FtFWtUNPSPPPGZNEtO@I-love.SAKURA.ne.jp> <201108271501.GGI04618.WUOFPNPNttZtPESPGF@I-love.SAKURA.ne.jp> <4E5DFBB6.2020207@nttdata.co.jp> Message-ID: Toshiharu Harada wrote: > So, let me say, "I am convinced". Ditto :-)