From jamie at tomoyolinux.co.uk Sun May 1 00:02:43 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sat, 30 Apr 2011 16:02:43 +0100 Subject: [tomoyo-dev-en 201] Re: About supporting policy namespace. In-Reply-To: <201104292154.GDJ04627.PUFtWNZPEtNtPPOFSG@I-love.SAKURA.ne.jp> References: <201104210757.p3L7vOCM044857@www262.sakura.ne.jp> <201104292154.GDJ04627.PUFtWNZPEtNtPPOFSG@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > (1) Loosen "" prefix in domainnames to accept "<$namespace>" format > ? ?where $namespace is an arbitrary word (e.g. apache or /usr/sbin/httpd ). > ? ?$namespace == kernel is reserved for the built-in namespace. > > ? ?Namespaces do not have parent-child relationship whereas domains in each > ? ?namespace have parent-child relationship. > > ? ?Each domain belongs to one namespace, and the namespace for the domain is > ? ?equals to the first word of the domainname (e.g. " /sbin/init" > ? ?domain belongs to "" namespace, " /bin/mail" domain belongs > ? ?to "" namespace). > > ? ?Any process can jump to different namespace's root domain if permitted by > ? ?the policy for the namespace where the domain where the process belongs to > ? ?belongs to. I like the <$namespace> format, as is itself a namespace. Quite self-explanatory syntax. > "move_namespace" might replace "initialize_domain". What is your suggested syntax/usage for "move_namespace" and "no_move_namespace" ? From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Sun May 1 11:57:27 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 1 May 2011 11:57:27 +0900 Subject: [tomoyo-dev-en 202] Re: About supporting policy namespace. In-Reply-To: References: <201104210757.p3L7vOCM044857@www262.sakura.ne.jp> <201104292154.GDJ04627.PUFtWNZPEtNtPPOFSG@I-love.SAKURA.ne.jp> Message-ID: <201105011157.FFF39095.tWPGSFtUPPEOZtPNFN@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > > "move_namespace" might replace "initialize_domain". > > What is your suggested syntax/usage for "move_namespace" and > "no_move_namespace" ? Same with "initialize_domain"/"no_initialize_domain". For example, "move_namespace /usr/sbin/httpd from any" will transit to "" namespace when /usr/sbin/httpd is executed. If we want to specify namespace to transit to, we can't reuse syntax/parser for "initialize_domain"/"keep_domain". auto_domain_transition="" in ACL's condition part will transit to "" namespace whereas auto_domain_transition="/usr/sbin/httpd" in ACL's condition part will transit to "current domainname" + "/usr/sbin/httpd" domain. task auto_domain_transition will transit to "" namespace if current namespace is not "", will transit to "" domain otherwise. If we want to use different keywords (like 'auto_namespace_transition="httpd"' and 'task auto_namespace_transition apache' ) for easier understanding, I can do so. From jamie at tomoyolinux.co.uk Sun May 1 22:19:21 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sun, 1 May 2011 14:19:21 +0100 Subject: [tomoyo-dev-en 203] Re: About supporting policy namespace. In-Reply-To: <201105011157.FFF39095.tWPGSFtUPPEOZtPNFN@I-love.SAKURA.ne.jp> References: <201104210757.p3L7vOCM044857@www262.sakura.ne.jp> <201104292154.GDJ04627.PUFtWNZPEtNtPPOFSG@I-love.SAKURA.ne.jp> <201105011157.FFF39095.tWPGSFtUPPEOZtPNFN@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > Jamie Nguyen wrote: >> > "move_namespace" might replace "initialize_domain". >> >> What is your suggested syntax/usage for "move_namespace" and >> "no_move_namespace" ? > > Same with "initialize_domain"/"no_initialize_domain". For example, > "move_namespace /usr/sbin/httpd from any" will transit to "" > namespace when /usr/sbin/httpd is executed. If we want to specify namespace to > transit to, we can't reuse syntax/parser for "initialize_domain"/"keep_domain". I'm worried that this may potentially be quite confusing for new users. They already have to try to understand the concept of "domains" but now also have to understand the concept of "namespaces". I think it is often best to make it possible for new features to be ignored if users don't need them, but I'm not sure if this is possible here. Also, concerning the directive syntax, how about using "initialize_namespace" instead? This might be more easily recognisable as a drop-in replacement for "initialize_domain" and easier for existing users to get used to. > auto_domain_transition="" in ACL's condition part will transit to > "" namespace whereas auto_domain_transition="/usr/sbin/httpd" in ACL's > condition part will transit to "current domainname" + "/usr/sbin/httpd" domain. > > > > task auto_domain_transition will transit to "" namespace > if current namespace is not "", will transit to "" domain > otherwise. > > > > If we want to use different keywords (like 'auto_namespace_transition="httpd"' > and 'task auto_namespace_transition apache' ) for easier understanding, > I can do so. This directive can result in transition to either a domain or a namespace, so both "auto_domain_transition" and "auto_namespace_transition" don't describe perfectly. So I think it is best to stick with "auto_domain_transition" to keep syntax familiar. It also functions in exactly the same way unless <$namespace> is specified, which makes it easier for users to ignore namespace functionality. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Sun May 1 22:48:51 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 1 May 2011 22:48:51 +0900 Subject: [tomoyo-dev-en 204] Re: About supporting policy namespace. In-Reply-To: References: <201104210757.p3L7vOCM044857@www262.sakura.ne.jp> <201104292154.GDJ04627.PUFtWNZPEtNtPPOFSG@I-love.SAKURA.ne.jp> <201105011157.FFF39095.tWPGSFtUPPEOZtPNFN@I-love.SAKURA.ne.jp> Message-ID: <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > I'm worried that this may potentially be quite confusing for new > users. They already have to try to understand the concept of "domains" > but now also have to understand the concept of "namespaces". I think > it is often best to make it possible for new features to be ignored if > users don't need them, but I'm not sure if this is possible here. By default, only namespace is defined. Users need not to understand the concept of namespaces as long as they live in the namespace only. > Also, concerning the directive syntax, how about using > "initialize_namespace" instead? This might be more easily recognisable > as a drop-in replacement for "initialize_domain" and easier for > existing users to get used to. I have no problem with using "initialize_namespace"/"no_initialize_namespace" rather than "move_namespace"/"no_move_namespace". > > If we want to use different keywords (like 'auto_namespace_transition="httpd"' > > and 'task auto_namespace_transition apache' ) for easier understanding, > > I can do so. > > This directive can result in transition to either a domain or a > namespace, so both "auto_domain_transition" and > "auto_namespace_transition" don't describe perfectly. So I think it is > best to stick with "auto_domain_transition" to keep syntax familiar. > It also functions in exactly the same way unless <$namespace> is > specified, which makes it easier for users to ignore namespace > functionality. Excuse me, I couldn't catch. "auto_namespace_transition=" and "task auto_namespace_transition" are for jumping to a different namespace. "auto_domain_transition=" and "task auto_domain_transition" are for jumping to a different domain in the same namespace. Users need not to understand "initialize_namespace"/"no_initialize_namespace"/ "auto_namespace_transition="/"task auto_namespace_transition" as long as they live in the namespace only. From jamie at tomoyolinux.co.uk Sun May 1 23:18:52 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sun, 1 May 2011 15:18:52 +0100 Subject: [tomoyo-dev-en 205] Re: About supporting policy namespace. In-Reply-To: <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> References: <201104210757.p3L7vOCM044857@www262.sakura.ne.jp> <201104292154.GDJ04627.PUFtWNZPEtNtPPOFSG@I-love.SAKURA.ne.jp> <201105011157.FFF39095.tWPGSFtUPPEOZtPNFN@I-love.SAKURA.ne.jp> <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > Jamie Nguyen wrote: >> I'm worried that this may potentially be quite confusing for new >> users. They already have to try to understand the concept of "domains" >> but now also have to understand the concept of "namespaces". I think >> it is often best to make it possible for new features to be ignored if >> users don't need them, but I'm not sure if this is possible here. > > By default, only namespace is defined. Users need not to understand > the concept of namespaces as long as they live in the namespace only. Just to make sure we understand each other, do I understand correctly that you want to remove "initialize_domain" directive and replace with "initialize_namespace"? Or do you intend them to exist together? >> This directive can result in transition to either a domain or a >> namespace, so both "auto_domain_transition" and >> "auto_namespace_transition" don't describe perfectly. So I think it is >> best to stick with "auto_domain_transition" to keep syntax familiar. >> It also functions in exactly the same way unless <$namespace> is >> specified, which makes it easier for users to ignore namespace >> functionality. > > Excuse me, I couldn't catch. "auto_namespace_transition=" and > "task auto_namespace_transition" are for jumping to a different namespace. > "auto_domain_transition=" and "task auto_domain_transition" are for jumping to > a different domain in the same namespace. > > Users need not to understand "initialize_namespace"/"no_initialize_namespace"/ > "auto_namespace_transition="/"task auto_namespace_transition" as long as they > live in the namespace only. Sorry, I'm not sure I understand completely. You posted this question earlier: > If we want to use different keywords (like 'auto_namespace_transition="httpd"' > and 'task auto_namespace_transition apache' ) for easier understanding, > I can do so. This was the first time I saw that you introduced these directives. Are you saying that these directives are optional, and we could implement without them? Could you also explain the difference between "auto_domain_transition=" and "task auto_domain_transition ". I am familiar with "task ....." but not the other. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Mon May 2 00:11:16 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 2 May 2011 00:11:16 +0900 Subject: [tomoyo-dev-en 206] Re: About supporting policy namespace. In-Reply-To: References: <201105011157.FFF39095.tWPGSFtUPPEOZtPNFN@I-love.SAKURA.ne.jp> <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> Message-ID: <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > Just to make sure we understand each other, do I understand correctly > that you want to remove "initialize_domain" directive and replace with > "initialize_namespace"? Or do you intend them to exist together? I won't remove "initialize_domain" directive. "initialize_domain" and "initialize_namespace" directives coexist. > Sorry, I'm not sure I understand completely. You posted this question earlier: > > > If we want to use different keywords (like 'auto_namespace_transition="httpd"' > > and 'task auto_namespace_transition apache' ) for easier understanding, > > I can do so. > > This was the first time I saw that you introduced these directives. > Are you saying that these directives are optional, and we could > implement without them? > These directives will not be used by users who can satisfy their needs within only namespacce. > Could you also explain the difference between > "auto_domain_transition=" and "task auto_domain_transition > ". I am familiar with "task ....." but not the other. Sure. "auto_domain_transition=" is used as conditional ACL (case (g) below). Currently 7 directives are defined. (a) initialize_domain /usr/sbin/httpd from any Jump to " /usr/sbin/httpd" domain. (b) no_initialize_domain /bin/mail from any Don't jump to " /usr/sbin/httpd" domain. (c) keep_domain any from /usr/sbin/httpd /bin/bash Don't transit to child domain from " /usr/sbin/httpd /bin/bash" domain. (d) no_keep_domain /usr/bin/passwd from any Transit to "current domain's name" + "/usr/bin/passwd" domain. (e) task manual_domain_transition /usr/sbin/httpd //some/host Jump to " /usr/sbin/httpd //some/host" domain by "echo /usr/sbin/httpd //some/host > /proc/ccs/self_domain". (f) task auto_domain_transition //lockdown task.uid=1000 Jump to " //lockdown" domain when process's uid became 1000. (g) file read /foo auto_domain_transition="/foo" Jump to "current domain's name" + "/foo" domain when /foo is opened for reading. These directives work within the same namespace. I'm considering introducing 5 more directives in order to support namespaces. (h) initialize_namespace /usr/sbin/httpd from any Jump to "" domain. (i) no_initialize_namespace /usr/sbin/httpd from any Don't jump to "" domain. (j) task manual_namespace_transition apache Jump to "" domain by "echo apache > /proc/ccs/self_domain". (k) task auto_namespace_transition apache task.uid=48 Jump to "" domain when process's uid became 48. (l) file read /foo auto_namespace_transition="foo" Jump to "" domain when /foo is opened for reading. When namespace is added, (a) - (g) works with the current namespace. For example, initialize_domain /bin/sh from any in namespace means Jump to " /bin/sh" domain when /bin/sh is executed. and initialize_domain /bin/sh from any in namespace means Jump to " /bin/sh" domain when /bin/sh is executed. . From jamie at tomoyolinux.co.uk Mon May 2 01:01:02 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sun, 1 May 2011 17:01:02 +0100 Subject: [tomoyo-dev-en 207] Re: About supporting policy namespace. In-Reply-To: <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> References: <201105011157.FFF39095.tWPGSFtUPPEOZtPNFN@I-love.SAKURA.ne.jp> <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > Jamie Nguyen wrote: >> Just to make sure we understand each other, do I understand correctly >> that you want to remove "initialize_domain" directive and replace with >> "initialize_namespace"? Or do you intend them to exist together? > > I won't remove "initialize_domain" directive. > "initialize_domain" and "initialize_namespace" directives coexist. This was the root of my misunderstanding! I was falsely under the impression that you wanted to replace "initialize_domain", but since this is not the case, namespaces can indeed be ignored by users that don't need it. Great! > Sure. "auto_domain_transition=" is used as conditional ACL (case (g) below). > Currently 7 directives are defined. > > (a) initialize_domain /usr/sbin/httpd from any > > ? ?Jump to " /usr/sbin/httpd" domain. > > (b) no_initialize_domain /bin/mail from any > > ? ?Don't jump to " /usr/sbin/httpd" domain. > > (c) keep_domain any from /usr/sbin/httpd /bin/bash > > ? ?Don't transit to child domain from " /usr/sbin/httpd /bin/bash" domain. > > (d) no_keep_domain /usr/bin/passwd from any > > ? ?Transit to "current domain's name" + "/usr/bin/passwd" domain. > > (e) task manual_domain_transition /usr/sbin/httpd //some/host > > ? ?Jump to " /usr/sbin/httpd //some/host" domain by "echo /usr/sbin/httpd //some/host > /proc/ccs/self_domain". > > (f) task auto_domain_transition //lockdown task.uid=1000 > > ? ?Jump to " //lockdown" domain when process's uid became 1000. > > (g) file read /foo auto_domain_transition="/foo" > > ? ?Jump to "current domain's name" + "/foo" domain when /foo is opened for reading. > > These directives work within the same namespace. > > I'm considering introducing 5 more directives in order to support namespaces. > > (h) initialize_namespace /usr/sbin/httpd from any > > ? ?Jump to "" domain. > > (i) no_initialize_namespace /usr/sbin/httpd from any > > ? ?Don't jump to "" domain. > > (j) task manual_namespace_transition apache > > ? ?Jump to "" domain by "echo apache > /proc/ccs/self_domain". > > (k) task auto_namespace_transition apache task.uid=48 > > ? ?Jump to "" domain when process's uid became 48. > > (l) file read /foo auto_namespace_transition="foo" > > ? ?Jump to "" domain when /foo is opened for reading. > > When namespace is added, (a) - (g) works with the current namespace. > For example, > > ? ?initialize_domain /bin/sh from any > > in namespace means > > ? ?Jump to " /bin/sh" domain when /bin/sh is executed. > > and > > ? ?initialize_domain /bin/sh from any > > in namespace means > > ? ?Jump to " /bin/sh" domain when /bin/sh is executed. All the changes look very good to me. I am guessing that you are proposing that each namespace will have it's own exception_policy.conf ? From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Mon May 2 06:57:58 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 2 May 2011 06:57:58 +0900 Subject: [tomoyo-dev-en 208] Re: About supporting policy namespace. In-Reply-To: References: <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> Message-ID: <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > Tetsuo Handa wrote: > > Jamie Nguyen wrote: > >> Just to make sure we understand each other, do I understand correctly > >> that you want to remove "initialize_domain" directive and replace with > >> "initialize_namespace"? Or do you intend them to exist together? > > > > I won't remove "initialize_domain" directive. > > "initialize_domain" and "initialize_namespace" directives coexist. > > This was the root of my misunderstanding! I was falsely under the > impression that you wanted to replace "initialize_domain", but since > this is not the case, namespaces can indeed be ignored by users that > don't need it. Great! Sorry for making you confused. I meant to say that using "initialize_namespace" is convenient for most cases for policy developers than using "initialize_domain" because they can develop policy without worrying conflicts for domain_policy exception_policy profile and manager. > All the changes look very good to me. I am guessing that you are > proposing that each namespace will have it's own exception_policy.conf > ? Yes. Each namespace will have its own domain_policy.conf exception_policy.conf profile.conf and manager.conf . That's a problem, for we need to consider about userland policy directory layout. For /proc/ccs/ directory, we don't need to create domain_policy exception_policy profile and manager for each namespace because we can switch namespace to read from or write to by writing "namespace $namespace" line. But for /etc/ccs/policy/ directory, I think we want to split files for each namespace. Well, technically it has no problem with concatenating domain_policy-kernel.conf and domain_policy-apache.conf like # domain policy for namespace follows. # domain policy for namespace follows. because the first word in a line (e.g. and ) can serve as namespace separator. But for (e.g.) exception_policy-kernel.conf and exception_policy-apache.conf , can we accept concatenated format like namespace # exception policy for namespace follows. namespace # exception policy for namespace follows. which makes it impossible to use existing commands like /bin/sort ? But if we split exception_policy.conf for each namespace, both exception_policy-$namespace.conf and $namespace/exception_policy.conf are bad if we accept / in $namespace . Oliver, how do you want to have policy files for each LXC environment? Concatenated single file or separated multiple files? From jamie at tomoyolinux.co.uk Mon May 2 07:47:57 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sun, 1 May 2011 23:47:57 +0100 Subject: [tomoyo-dev-en 209] Re: About supporting policy namespace. In-Reply-To: <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> References: <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > Yes. Each namespace will have its own domain_policy.conf exception_policy.conf > profile.conf and manager.conf . That's a problem, for we need to consider about > userland policy directory layout. For /proc/ccs/ directory, we don't need to > create domain_policy exception_policy profile and manager for each namespace > because we can switch namespace to read from or write to by writing > "namespace $namespace" line. But for /etc/ccs/policy/ directory, I think we > want to split files for each namespace. Well, technically it has no problem > with concatenating domain_policy-kernel.conf and domain_policy-apache.conf like > > ?# domain policy for namespace follows. > ?# domain policy for namespace follows. > > because the first word in a line (e.g. and ) can > serve as namespace separator. But for (e.g.) exception_policy-kernel.conf and > exception_policy-apache.conf , can we accept concatenated format like > > ?namespace > ?# exception policy for namespace follows. > ?namespace > ?# exception policy for namespace follows. > > which makes it impossible to use existing commands like /bin/sort ? > > But if we split exception_policy.conf for each namespace, > both exception_policy-$namespace.conf and $namespace/exception_policy.conf > are bad if we accept / in $namespace . Personally, I think splitting is much more preferable than concatenating. If for example many namespaces are being used (e.g. >5), this is much more easily manageable in separate files than within a single concatenated file. Do you think it is a problem to disallow "/" in $namespace ? Also, I much prefer "/etc/ccs/$namespace/exception_policy.conf" rather than "/etc/ccs/exception_policy-$namespace.conf". If we use exception_policy-$namespace.conf, then things can get rather messy when many namespaces are used. Also, if we do use a different directory for $namespace, then I suppose "/etc/ccs/policy/current" can include further subdirectories for each namespace, for example "/etc/ccs/policy/current/apache". Proposed layout looks like this: # ls -R /etc/ccs apache/ ccs-load-module domain_policy.conf exception_policy.conf manager.conf policy/ profile.conf stat.conf tools/ /etc/ccs/apache: domain_policy.conf exception_policy.conf manager.conf profile.conf /etc/ccs/policy: 11-05-01.09:32:47/ 11-05-01.15:41:01/ current previous /etc/ccs/policy/11-05-01.09:32:47: domain_policy.conf exception_policy.conf manager.conf profile.conf /etc/ccs/policy/11-05-01.15:41:01: apache/ domain_policy.conf exception_policy.conf manager.conf profile.conf /etc/ccs/policy/11-05-01.15:41:01/apache: domain_policy.conf exception_policy.conf manager.conf profile.conf /etc/ccs/tools: auditd.conf editpolicy.conf notifyd.conf patternize.conf What do you think? > Oliver, how do you want to have policy files for each LXC environment? > Concatenated single file or separated multiple files? Yes, it would be good to get opinions of users that use namespaces on a regular basis. From jamie at tomoyolinux.co.uk Mon May 2 07:52:38 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sun, 1 May 2011 23:52:38 +0100 Subject: [tomoyo-dev-en 210] Re: About supporting policy namespace. In-Reply-To: References: <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> Message-ID: Oops, forgot to reply to all (I wish gmail would remind me!). Forwarding to Oliver also. ---------- Forwarded message ---------- From: Jamie Nguyen Date: 1 May 2011 23:47 Subject: Re: [tomoyo-dev-en 208] Re: About supporting policy namespace. To: tomoyo-dev-en at lists.sourceforge.jp Tetsuo Handa wrote: > Yes. Each namespace will have its own domain_policy.conf exception_policy.conf > profile.conf and manager.conf . That's a problem, for we need to consider about > userland policy directory layout. For /proc/ccs/ directory, we don't need to > create domain_policy exception_policy profile and manager for each namespace > because we can switch namespace to read from or write to by writing > "namespace $namespace" line. But for /etc/ccs/policy/ directory, I think we > want to split files for each namespace. Well, technically it has no problem > with concatenating domain_policy-kernel.conf and domain_policy-apache.conf like > > ?# domain policy for namespace follows. > ?# domain policy for namespace follows. > > because the first word in a line (e.g. and ) can > serve as namespace separator. But for (e.g.) exception_policy-kernel.conf and > exception_policy-apache.conf , can we accept concatenated format like > > ?namespace > ?# exception policy for namespace follows. > ?namespace > ?# exception policy for namespace follows. > > which makes it impossible to use existing commands like /bin/sort ? > > But if we split exception_policy.conf for each namespace, > both exception_policy-$namespace.conf and $namespace/exception_policy.conf > are bad if we accept / in $namespace . Personally, I think splitting is much more preferable than concatenating. If for example many namespaces are being used (e.g. >5), this is much more easily manageable in separate files than within a single concatenated file. Do you think it is a problem to disallow "/" in $namespace ? Also, I much prefer "/etc/ccs/$namespace/exception_policy.conf" rather than "/etc/ccs/exception_policy-$namespace.conf". If we use exception_policy-$namespace.conf, then things can get rather messy when many namespaces are used. Also, if we do use a different directory for $namespace, then I suppose "/etc/ccs/policy/current" can include further subdirectories for each namespace, for example "/etc/ccs/policy/current/apache". Proposed layout looks like this: # ls -R /etc/ccs apache/ ?ccs-load-module ?domain_policy.conf ?exception_policy.conf manager.conf ?policy/ ?profile.conf ?stat.conf ?tools/ /etc/ccs/apache: domain_policy.conf ?exception_policy.conf ?manager.conf ?profile.conf /etc/ccs/policy: 11-05-01.09:32:47/ ?11-05-01.15:41:01/ ?current ?previous /etc/ccs/policy/11-05-01.09:32:47: domain_policy.conf ?exception_policy.conf ?manager.conf ?profile.conf /etc/ccs/policy/11-05-01.15:41:01: apache/ ?domain_policy.conf ?exception_policy.conf ?manager.conf ?profile.conf /etc/ccs/policy/11-05-01.15:41:01/apache: domain_policy.conf ?exception_policy.conf ?manager.conf ?profile.conf /etc/ccs/tools: auditd.conf ?editpolicy.conf ?notifyd.conf ?patternize.conf What do you think? > Oliver, how do you want to have policy files for each LXC environment? > Concatenated single file or separated multiple files? Yes, it would be good to get opinions of users that use namespaces on a regular basis. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Mon May 2 14:30:45 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 02 May 2011 14:30:45 +0900 Subject: [tomoyo-dev-en 211] Re: About supporting policy namespace. In-Reply-To: References: <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> Message-ID: <201105020530.p425UjSQ027087@www262.sakura.ne.jp> Jamie Nguyen wrote: > Personally, I think splitting is much more preferable than > concatenating. If for example many namespaces are being used (e.g. > >5), this is much more easily manageable in separate files than within > a single concatenated file. Do you think it is a problem to disallow > "/" in $namespace ? Well, I think we will need to choose one from choices listed below: (1) implicitly use the basename of the program (e.g. httpd for "initialize_namespace /usr/sbin/httpd from any" case) (2) let users explicitly specify the namespace (e.g. apache for "initialize_namespace apache /usr/sbin/httpd from any" case) (3) use escape (e.g. \057usr\057sbin\057httpd for /usr/sbin/httpd ) like AppArmor does (i.e. replace '/' with '.') when accessing namespace directories. > Also, if we do use a different directory for $namespace, then I > suppose "/etc/ccs/policy/current" can include further subdirectories > for each namespace, for example "/etc/ccs/policy/current/apache". > Proposed layout looks like this: As you locate $namespace directory under $YY-$MM-$DD.$hh:$mm:$ss directory, you prefer saving all namespace's policy files atomically over saving individual namespace's policy files as needed, don't you? /etc/ccs/ ccs-load-module For loading the kernel module. ccs-post-init For doing additional initialization. domain_policy.conf Symlink to policy/current/domain_policy.conf exception_policy.conf Symlink to policy/current/exception_policy.conf profile.conf Symlink to policy/current/profile.conf manager.conf Symlink to policy/current/manager.conf stat.conf Memory usage quota configuration. /etc/ccs/tools/ auditd.conf Configuration for /usr/sbin/ccs-auditd editpolicy.conf Configuration for /usr/sbin/ccs-editpolicy notifyd.conf Configuration for /usr/sbin/ccs-notifyd patternize.conf Configuration for /usr/sbin/ccs-patternize /etc/ccs/policy/ current Symlink to $YY-$MM-$DD.$hh:$mm:$ss previous Symlink to location where current was pointing to. /etc/ccs/policy/$YY-$MM-$DD.$hh:$mm:$ss/ domain_policy.conf Domain policy for kernel namespace. exception_policy.conf Exception policy for kernel namespace. profile.conf Profile for kernel namespace. manager.conf Manager for kernel namespace. /etc/ccs/policy/$YY-$MM-$DD.$hh:$mm:$ss/$namespace/ domain_policy.conf Domain policy for $namespace namespace. exception_policy.conf Exception policy for $namespace namespace. profile.conf Profile for $namespace namespace. manager.conf Manager for $namespace namespace. Do we locate policy files for kernel namespace to /etc/ccs/policy/$YY-$MM-$DD.$hh:$mm:$ss/ and retain 4 symlinks in /etc/ccs/ ? This is good for backward compatibility, but may cause operation mistakes (e.g. adding to kernel namespace while meant to add to apache namespace) when users started using other namespaces. In this case, $namespace is none of 'kernel' 'domain_policy.conf' 'exception_policy.conf' 'profile.conf' 'manager.conf'. If locate policy files for kernel namespace to /etc/ccs/policy/$YY-$MM-$DD.$hh:$mm:$ss/kernel/ and remove 4 symlinks in /etc/ccs/ , this breaks backward compatibility but may help avoiding operation mistakes. In this case, $namespace can be any word. If we split /etc/ccs/ files for each namespace, we might also want to split corresponding /proc/ccs/ files. Regarding /proc/ccs/ directory: /proc/ccs/ namespace For listing namespaces and adding new namespace query For /usr/sbin/ccs-queryd audit For /usr/sbin/ccs-auditd stat Statistics information version TOMOYO's version self_domain Current thread's domain .execute_handler For execute handler programs .process_status For /usr/sbin/ccs-pstree domain_policy Mirror of /proc/ccs/$namespace/domain_policy exception_policy Mirror of /proc/ccs/$namespace/exception_policy profile Mirror of /proc/ccs/$namespace/profile manager Mirror of /proc/ccs/$namespace/manager .domain_status Mirror of /proc/ccs/$namespace/.domain_status /proc/ccs/$namespace/ domain_policy Domain policy for $namespace namespace. exception_policy Exception policy for $namespace namespace. profile Profile for $namespace namespace. manager Manager for $namespace namespace. .domain_status Subset of domain_policy for /usr/sbin/ccs-setprofile In this case, $namespace is none of 'namespace' 'query' 'audit' 'stat' 'version' 'self_domain' '.execute_handler' '.process_status' 'domain_policy' 'exception_policy' 'profile' 'manager' '.domain_status'. /proc/ccs/ namespace For listing namespaces and adding new namespace query For /usr/sbin/ccs-queryd audit For /usr/sbin/ccs-auditd stat Statistics information version TOMOYO's version self_domain Current thread's domain .execute_handler For execute handler programs .process_status For /usr/sbin/ccs-pstree domain_policy Mirror of /proc/ccs/namespace.d/$namespace/domain_policy exception_policy Mirror of /proc/ccs/namespace.d/$namespace/exception_policy profile Mirror of /proc/ccs/namespace.d/$namespace/profile manager Mirror of /proc/ccs/namespace.d/$namespace/manager .domain_status Mirror of /proc/ccs/namespace.d/$namespace/.domain_status /proc/ccs/namespace.d/$namespace/ domain_policy Domain policy for $namespace namespace. exception_policy Exception policy for $namespace namespace. profile Profile for $namespace namespace. manager Manager for $namespace namespace. .domain_status Subset of domain_policy for /usr/sbin/ccs-setprofile In this case, $namespace can be any word. For backward compatibility, above layout provides domain_policy exception_policy profile manager .domain_status as mirrors of namespace.d/$namespace/ files rather than symlinks to namespace.d/$namespace/ files. Well, .domain_status is used by /usr/sbin/ccs-setprofile but /usr/sbin/ccs-setprofile is unlikely used because we nowadays use /usr/sbin/ccs-editpolicy instead. We can remove .domain_status if we modify /usr/sbin/ccs-setprofile to use domain_policy instead. From jamie at tomoyolinux.co.uk Mon May 2 17:32:49 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Mon, 2 May 2011 09:32:49 +0100 Subject: [tomoyo-dev-en 212] Re: About supporting policy namespace. In-Reply-To: <201105020530.p425UjSQ027087@www262.sakura.ne.jp> References: <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> <201105020530.p425UjSQ027087@www262.sakura.ne.jp> Message-ID: Tetsuo Handa wrote: > Well, I think we will need to choose one from choices listed below: > > (1) implicitly use the basename of the program (e.g. httpd for > ? ?"initialize_namespace /usr/sbin/httpd from any" case) > > (2) let users explicitly specify the namespace (e.g. apache for > ? ?"initialize_namespace apache /usr/sbin/httpd from any" case) > > (3) use escape (e.g. \057usr\057sbin\057httpd for /usr/sbin/httpd ) > ? ?like AppArmor does (i.e. replace '/' with '.') > > when accessing namespace directories. If we use (1) then there is the possibility that 2 namespaces might conflict, such as /usr/bin/foo and /usr/lib/foo . Can we do (3) by default and let (2) also be possible? If we allow (2) then I guess we either have to disallow "/", or automatically convert "/" to "." . Also, are you planning on allowing a sub-level namespace (e.g. <.usr.sbin.lxc>) to have a further sub-sub-level namespace? And how are you planning to handle display of namespaces in ccs-editpolicy? Will it look something like this (indenting sub-level namespaces to indicate it's parent namespace): * /sbin/init /etc/rc.sysinit .... .... * /usr/sbin/httpd .... .... <.usr.sbin.lxc> * /sbin/init /etc/rc.sysinit .... .... > As you locate $namespace directory under $YY-$MM-$DD.$hh:$mm:$ss directory, > you prefer saving all namespace's policy files atomically over saving > individual namespace's policy files as needed, don't you? Yes, much less complicated to perform saving of everything at the same time. Also, sub-level namespace (e.g. ) policy is meaningless without top-level namespace (e.g. ) policy, as top-level namespace decides what domains transit to the sub-level namespace. > Do we locate policy files for kernel namespace to > /etc/ccs/policy/$YY-$MM-$DD.$hh:$mm:$ss/ and retain 4 symlinks in /etc/ccs/ ? > This is good for backward compatibility, but may cause operation mistakes (e.g. > adding to kernel namespace while meant to add to apache namespace) when users > started using other namespaces. In this case, $namespace is none of 'kernel' > 'domain_policy.conf' 'exception_policy.conf' 'profile.conf' 'manager.conf'. > > If locate policy files for kernel namespace to > /etc/ccs/policy/$YY-$MM-$DD.$hh:$mm:$ss/kernel/ and remove 4 symlinks in > /etc/ccs/ , this breaks backward compatibility but may help avoiding > operation mistakes. In this case, $namespace can be any word. Alternatively we could create "/etc/ccs/namespace.d/" folder in which we can put namespace directories. This can avoid $namespace name conflicts with "domain_policy.conf" etc. I like the "/etc/ccs/policy/$YY-$MM-$DD.$hh:$mm:$ss/kernel/" approach, but maybe it's better to keep the old layout and retain backwards compatibility. If we keep the old layout then users can ignore "/etc/ccs/namespace.d/" directory if they don't need namespace management. > If we split /etc/ccs/ files for each namespace, we might also want to split > corresponding /proc/ccs/ files. Regarding /proc/ccs/ directory: > > ... > > /proc/ccs/namespace.d/$namespace/ > > ?domain_policy ? ? ? ? Domain policy for $namespace namespace. > ?exception_policy ? ? ?Exception policy for $namespace namespace. > ?profile ? ? ? ? ? ? ? Profile for $namespace namespace. > ?manager ? ? ? ? ? ? ? Manager for $namespace namespace. > ?.domain_status ? ? ? ?Subset of domain_policy for /usr/sbin/ccs-setprofile > > In this case, $namespace can be any word. I prefer this approach to avoid name conflicts, and also match "/etc/ccs/namespace.d/" directory that I proposed above. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Mon May 2 21:53:49 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 2 May 2011 21:53:49 +0900 Subject: [tomoyo-dev-en 213] Re: About supporting policy namespace. In-Reply-To: References: <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> <201105020530.p425UjSQ027087@www262.sakura.ne.jp> Message-ID: <201105022153.BDD30704.tEWPPPFNUOFNtSGZPt@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > Tetsuo Handa wrote: > > Well, I think we will need to choose one from choices listed below: > > > > (1) implicitly use the basename of the program (e.g. httpd for > > "initialize_namespace /usr/sbin/httpd from any" case) > > > > (2) let users explicitly specify the namespace (e.g. apache for > > "initialize_namespace apache /usr/sbin/httpd from any" case) > > > > (3) use escape (e.g. \057usr\057sbin\057httpd for /usr/sbin/httpd ) > > like AppArmor does (i.e. replace '/' with '.') > > > > when accessing namespace directories. > > If we use (1) then there is the possibility that 2 namespaces might > conflict, such as /usr/bin/foo and /usr/lib/foo . Can we do (3) by > default and let (2) also be possible? If we allow (2) then I guess we > either have to disallow "/", or automatically convert "/" to "." . As soon as we convert "/" to ".", the problem similar to (1) arises. There may be /foo/bar.buz and /foo.bar/buz . Thus, I think escaping is the only acceptable way if we embed namespace's name into the polify file's locations. Given that said, \057 is illegal for TOMOYO. Maybe URLencode is better. > Also, are you planning on allowing a sub-level namespace (e.g. > <.usr.sbin.lxc>) to have a further sub-sub-level namespace? No. Namespaces have flat layout because we can implement tree layout within each namespace using domains in that namespace. > And how > are you planning to handle display of namespaces in ccs-editpolicy? Prints only one namespace at a time. > Will it look something like this (indenting sub-level namespaces to > indicate it's parent namespace): If you can prepare a virtual machine, you can try revision 4690 with diff.txt in the SVN's root?directory applied. You can switch to <<< Namespace Selector >>> by "w" -> "n"?keys, add a namespace by "a" key, add initialize_namespace /usr/sbin/httpd2 from any to exception policy and add file execute /usr/sbin/httpd2 file read /foo auto_domain_transition="" task manual_domain_transition to somewhere in the domain policy. Then, go to <<< Domain Transition Editor >>> and operate as you like. (Please note that directives are not up to date and implementation is not complete.) > > As you locate $namespace directory under $YY-$MM-$DD.$hh:$mm:$ss directory, > > you prefer saving all namespace's policy files atomically over saving > > individual namespace's policy files as needed, don't you? > > Yes, much less complicated to perform saving of everything at the same > time. Also, sub-level namespace (e.g. ) policy is meaningless > without top-level namespace (e.g. ) policy, as top-level > namespace decides what domains transit to the sub-level namespace. OK. I worried that saving all namespaces (even if namespaces have no changes) is nothing but a waste of disk space. But if we don't care disk space, saving all will be fine. > Alternatively we could create "/etc/ccs/namespace.d/" folder in which > we can put namespace directories. This can avoid $namespace name > conflicts with "domain_policy.conf" etc. Or /etc/ccs/policy.d/ (like /etc/httpd/conf/ and /etc/httpd/conf.d/ ). > I like the "/etc/ccs/policy/$YY-$MM-$DD.$hh:$mm:$ss/kernel/" approach, > but maybe it's better to keep the old layout and retain backwards > compatibility. If we keep the old layout then users can ignore > "/etc/ccs/namespace.d/" directory if they don't need namespace > management. For compatibility and simplicity, I think below choice is also worth considering. > I prefer this approach to avoid name conflicts, and also match > "/etc/ccs/namespace.d/" directory that I proposed above. Another choice is to use concatenated files for TOMOYO 1.8.x (for compatibility) and consider using splitted files for TOMOYO 1.9.x. Regarding other implementations, it is easy to manage policy using splitted policy files because basically only "load policy" operation is needed. But regarding TOMOYO, we need to also support "save policy" operation because TOMOYO's kernel modifies policy. This complicates things when dividing into splitted policy files. If we think simplicity, using concatenated files can reduce number of directories and files being created in /etc/ccs/ directory, can save time for scanning directories and opening files, can simplify error handling. Even if all namespaces are packed into single policy file, we can easily pick up interested ranges using ccs-selectpolicy utility when the administrator needs to browse policy manually. (Umm, I can't remember how many times did I typo "namescape" today...) From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Tue May 3 01:20:32 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 3 May 2011 01:20:32 +0900 Subject: [tomoyo-dev-en 214] FW: Re: Re: About supporting policy namespace. References: Message-ID: <201105030120.GGF73345.UZSNPtNEWPFPFOtPGt@I-love.SAKURA.ne.jp> ------- Forwarded Message From: Jamie Nguyen Subject: Re: [tomoyo-dev-en 212] Re: About supporting policy namespace. Date: Mon, 2 May 2011 15:03:22 +0100 Tetsuo Handa wrote: > If you can prepare a virtual machine, you can try revision 4690 with diff.txt > in the SVN's root?directory applied. You can switch to <<< Namespace Selector >>> > by "w" -> "n"?keys, add a namespace Sure, I will have a look tonight. > OK. I worried that saving all namespaces (even if namespaces have no changes) > is nothing but a waste of disk space. But if we don't care disk space, > saving all will be fine. I don't see disk space as too much of a problem. If disk space is tight, then old policy folders can be deleted. > Another choice is to use concatenated files for TOMOYO 1.8.x (for > compatibility) and consider using splitted files for TOMOYO 1.9.x. > > Regarding other implementations, it is easy to manage policy using splitted > policy files because basically only "load policy" operation is needed. But > regarding TOMOYO, we need to also support "save policy" operation because > TOMOYO's kernel modifies policy. This complicates things when dividing into > splitted policy files. If we think simplicity, using concatenated files can > reduce number of directories and files being created in /etc/ccs/ directory, > can save time for scanning directories and opening files, can simplify error > handling. Even if all namespaces are packed into single policy file, we can > easily pick up interested ranges using ccs-selectpolicy utility when the > administrator needs to browse policy manually. If we use concatenated, can we then forget about the problem you mentioned here? : > As soon as we convert "/" to ".", the problem similar to (1) arises. There may > be /foo/bar.buz and /foo.bar/buz . Thus, I think escaping is the only > acceptable way if we embed namespace's name into the polify file's locations. > > Given that said, \057 is illegal for TOMOYO. Maybe URLencode is better. I think it is true that concatenated is simpler, reduces number of files, reduces possibility of human error, and is backwards compatible. We can also ignore problems caused by "/" within $namespace, and do not have to change directory layout of /etc/ccs. The problem with concatenated is that with many namespaces, domain_policy.conf can become very large. But as you said, ccs-selectpolicy can help here, as well as use of grep/awk/sed. On reflection, I think it is much nicer to have whole domain policy contained within a single file (and same for exception policy). I agree that concatenated is simpler, so I will vote for that. I'm a fan of simplicity. By the way, how are you planning to manage profile.conf and manager.conf? Each namespace will of course need to have their own section within domain_policy.conf and exception_policy.conf, but they don't really need their own section in profile.conf, as it may become very confusing if profile=3 in namespace is not the same as profile=3 in namespace. > (Umm, I can't remember how many times did I typo "namescape" today...) Moved to a new desktop last week after using a laptop for so long, and I'm struggling to get used to the keyboard... On an unrelated note, I have noticed that ccs-queryd will pick up "misc env" access requests that have been rejected, but these will not be picked up by ccs-auditd. Is this intended behaviour? ------- End of Forwarded Message From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Tue May 3 01:21:48 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 3 May 2011 01:21:48 +0900 Subject: [tomoyo-dev-en 215] Re: FW: Re: Re: About supporting policy namespace. In-Reply-To: <201105030120.GGF73345.UZSNPtNEWPFPFOtPGt@I-love.SAKURA.ne.jp> References: <201105030120.GGF73345.UZSNPtNEWPFPFOtPGt@I-love.SAKURA.ne.jp> Message-ID: <201105030121.HBD57891.ZPttGFUtPWEOPNPSFN@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > If we use concatenated, can we then forget about the problem you > mentioned here? : I think you answered yourself "yes". ;-) | I think it is true that concatenated is simpler, reduces number of | files, reduces possibility of human error, and is backwards | compatible. We can also ignore problems caused by "/" within | $namespace, and do not have to change directory layout of /etc/ccs. The backwards incompatible point is that we can no longer sort exception_policy profile and manager using /bin/sort utility because these files become stateful like domain_policy . > By the way, how are you planning to manage profile.conf and > manager.conf? Each namespace will of course need to have their own > section within domain_policy.conf and exception_policy.conf, but they > don't really need their own section in profile.conf, Insert a special line that tells start of a new namespace. For example, manager.conf will look like namespace /usr/sbin/ccs-editpolicy /usr/sbin/ccs-loadpolicy namespace /usr/sbin/ccs-loadpolicy namespace /path/to/some/manager-app by introducing namespace. > as it may become > very confusing if profile=3 in namespace is not the same as > profile=3 in namespace. The purpose of having its own section is to avoid interference across namespaces. It is normal if profile=3 in namespace is not the same as profile=3 in namespace. Which mode to assign to which profile is up to policy developers. For example, profile 3 in namespace enforces only file related operations whereas profile 3 in namespace enforces both file related operations and network related operations. In order to avoid accidentally inheriting "use_profile"/"use_group" setting when jumping to a different namespace, I allow only transition to the root domain of the new namespace where the domain was already created and was assigned a profile. > > (Umm, I can't remember how many times did I typo "namescape" today...) > > Moved to a new desktop last week after using a laptop for so long, and > I'm struggling to get used to the keyboard... > Also, I frequently typo "whilelisting" (of course, I mean "whitelisting") because I use "while" in C programs. > On an unrelated note, I have noticed that ccs-queryd will pick up > "misc env" access requests that have been rejected, but these will not > be picked up by ccs-auditd. Is this intended behaviour? OK, you found a bug. "misc env" permission is checked using next domain's profile ee->r.type = CCS_MAC_ENVIRON; ee->r.mode = ccs_get_mode(ccs_current_domain()->profile, CCS_MAC_ENVIRON); but I forgot to update ee->r.profile . As a result, permission is checked because ee->r.mode was set to "enforcing mode" but the audit log is not generated using next domain's profile number because ee->r.profile was not updated. I think --- a/security/ccsecurity/domain.c (revision 4960) +++ b/security/ccsecurity/domain.c (working copy) @@ -643,8 +643,8 @@ /* printk(KERN_DEBUG "start %d %d\n", argv_count, envp_count); */ int error = -ENOMEM; ee->r.type = CCS_MAC_ENVIRON; - ee->r.mode = ccs_get_mode(ccs_current_domain()->profile, - CCS_MAC_ENVIRON); + ee->r.profile = ccs_current_domain()->profile; + ee->r.mode = ccs_get_mode(ee->r.profile, CCS_MAC_ENVIRON); if (!r->mode || !envp_count) return 0; arg_ptr = kzalloc(CCS_EXEC_TMPSIZE, CCS_GFP_FLAGS); will fix it. From jamie at tomoyolinux.co.uk Tue May 3 04:08:11 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Mon, 2 May 2011 20:08:11 +0100 Subject: [tomoyo-dev-en 216] Re: FW: Re: Re: About supporting policy namespace. In-Reply-To: <201105030121.HBD57891.ZPttGFUtPWEOPNPSFN@I-love.SAKURA.ne.jp> References: <201105030120.GGF73345.UZSNPtNEWPFPFOtPGt@I-love.SAKURA.ne.jp> <201105030121.HBD57891.ZPttGFUtPWEOPNPSFN@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: >> By the way, how are you planning to manage profile.conf and >> manager.conf? Each namespace will of course need to have their own >> section within domain_policy.conf and exception_policy.conf, but they >> don't really need their own section in profile.conf, > > Insert a special line that tells start of a new namespace. > For example, manager.conf will look like > > ?namespace > ?/usr/sbin/ccs-editpolicy > ?/usr/sbin/ccs-loadpolicy > ?namespace > ?/usr/sbin/ccs-loadpolicy > ?namespace > ?/path/to/some/manager-app > > by introducing namespace. > >> as it may become >> very confusing if profile=3 in namespace is not the same as >> profile=3 in namespace. > > The purpose of having its own section is to avoid interference across > namespaces. It is normal if profile=3 in namespace is not the same as > profile=3 in namespace. Which mode to assign to which profile is up to > policy developers. For example, profile 3 in namespace enforces only > file related operations whereas profile 3 in namespace enforces both > file related operations and network related operations. > In order to avoid accidentally inheriting "use_profile"/"use_group" setting > when jumping to a different namespace, I allow only transition to the root > domain of the new namespace where the domain was already created and was > assigned a profile. OK, sounds good. >> On an unrelated note, I have noticed that ccs-queryd will pick up >> "misc env" access requests that have been rejected, but these will not >> be picked up by ccs-auditd. Is this intended behaviour? > > OK, you found a bug. "misc env" permission is checked using next domain's > profile > > ? ? ? ?ee->r.type = CCS_MAC_ENVIRON; > ? ? ? ?ee->r.mode = ccs_get_mode(ccs_current_domain()->profile, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?CCS_MAC_ENVIRON); > > but I forgot to update ee->r.profile . As a result, permission is checked > because ee->r.mode was set to "enforcing mode" but the audit log is not > generated using next domain's profile number because ee->r.profile was not > updated. I think > > --- a/security/ccsecurity/domain.c ? ? ?(revision 4960) > +++ b/security/ccsecurity/domain.c ? ? ?(working copy) > @@ -643,8 +643,8 @@ > ? ? ? ?/* printk(KERN_DEBUG "start %d %d\n", argv_count, envp_count); */ > ? ? ? ?int error = -ENOMEM; > ? ? ? ?ee->r.type = CCS_MAC_ENVIRON; > - ? ? ? ee->r.mode = ccs_get_mode(ccs_current_domain()->profile, > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CCS_MAC_ENVIRON); > + ? ? ? ee->r.profile = ccs_current_domain()->profile; > + ? ? ? ee->r.mode = ccs_get_mode(ee->r.profile, CCS_MAC_ENVIRON); > ? ? ? ?if (!r->mode || !envp_count) > ? ? ? ? ? ? ? ?return 0; > ? ? ? ?arg_ptr = kzalloc(CCS_EXEC_TMPSIZE, CCS_GFP_FLAGS); > > will fix it. Thanks. I've applied this to ccs-patch 1.8.1p1 and it works as expected now: diff -uNr linux-2.6.38.orig/security/ccsecurity/domain.c linux-2.6.38/security/ccsecurity/domain.c --- linux-2.6.38.orig/security/ccsecurity/domain.c 2011-04-11 01:00:00.000000000 +0100 +++ linux-2.6.38/security/ccsecurity/domain.c 2011-05-02 19:45:35.429994536 +0100 @@ -673,8 +673,8 @@ /* printk(KERN_DEBUG "start %d %d\n", argv_count, envp_count); */ int error = -ENOMEM; ee->r.type = CCS_MAC_ENVIRON; - ee->r.mode = ccs_get_mode(ccs_current_domain()->profile, - CCS_MAC_ENVIRON); + ee->r.profile = ccs_current_domain()->profile; + ee->r.mode = ccs_get_mode(ee->r.profile, CCS_MAC_ENVIRON); if (!r->mode || !envp_count) return 0; arg_ptr = kzalloc(CCS_EXEC_TMPSIZE, CCS_GFP_FLAGS); From jamie at tomoyolinux.co.uk Tue May 3 07:51:59 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Mon, 2 May 2011 23:51:59 +0100 Subject: [tomoyo-dev-en 217] Re: FW: Re: Re: About supporting policy namespace. In-Reply-To: References: <201105030120.GGF73345.UZSNPtNEWPFPFOtPGt@I-love.SAKURA.ne.jp> <201105030121.HBD57891.ZPttGFUtPWEOPNPSFN@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > If you can prepare a virtual machine, you can try revision 4690 with diff.txt > in the SVN's root?directory applied. You can switch to <<< Namespace Selector >>> > by "w" -> "n"?keys, add a namespace I ran r4960 with diff.txt applied. I couldn't add a new namespace for some reason, but otherwise it looks good. I like the complete separation between namespaces. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Tue May 3 22:49:08 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 3 May 2011 22:49:08 +0900 Subject: [tomoyo-dev-en 218] Re: FW: Re: Re: About supporting policynamespace. In-Reply-To: References: <201105030120.GGF73345.UZSNPtNEWPFPFOtPGt@I-love.SAKURA.ne.jp> <201105030121.HBD57891.ZPttGFUtPWEOPNPSFN@I-love.SAKURA.ne.jp> Message-ID: <201105032249.GAE65106.PtWPEStUNPGPFNFtZO@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > I ran r4960 with diff.txt applied. I couldn't add a new namespace for > some reason, but otherwise it looks good. I like the complete > separation between namespaces. OK. Then, you can watch http://tomoyo.sourceforge.jp/incoming/namespace.avi . From jamie at tomoyolinux.co.uk Wed May 4 07:51:06 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Tue, 3 May 2011 23:51:06 +0100 Subject: [tomoyo-dev-en 219] Re: FW: Re: Re: About supporting policynamespace. In-Reply-To: <201105032249.GAE65106.PtWPEStUNPGPFNFtZO@I-love.SAKURA.ne.jp> References: <201105030120.GGF73345.UZSNPtNEWPFPFOtPGt@I-love.SAKURA.ne.jp> <201105030121.HBD57891.ZPttGFUtPWEOPNPSFN@I-love.SAKURA.ne.jp> <201105032249.GAE65106.PtWPEStUNPGPFNFtZO@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > OK. Then, you can watch http://tomoyo.sourceforge.jp/incoming/namespace.avi . Looks great! :-) From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Sun May 8 22:05:25 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 8 May 2011 22:05:25 +0900 Subject: [tomoyo-dev-en 220] Re: FW: Re: Re: About supportingpolicynamespace. In-Reply-To: References: <201105030121.HBD57891.ZPttGFUtPWEOPNPSFN@I-love.SAKURA.ne.jp> <201105032249.GAE65106.PtWPEStUNPGPFNFtZO@I-love.SAKURA.ne.jp> Message-ID: <201105082205.HEF34318.OFUttNWESNPZPPGtPF@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > Tetsuo Handa wrote: > > OK. Then, you can watch http://tomoyo.sourceforge.jp/incoming/namespace.avi . > > Looks great! :-) OK. I reconsidered the specification a bit. Since domainname starts with "<$namespace>", /proc/ccs/domain_policy and /etc/ccs/domain_policy.conf do not require "namespace <$namespace>" separator. So, I decided to add "namespace <$namespace>" separator to only /proc/ccs/exception_policy /proc/ccs/profile /proc/ccs/manager and /etc/ccs/exception_policy.conf /etc/ccs/profile.conf /etc/ccs/manager.conf . As of revision 4971, the sequence to add new namespace and policy are like # echo '' | ccs-loadpolicy -n # (echo 'namespace ' ; echo '/bin/bash' ) | ccs-loadpolicy -m # (echo 'namespace ' ; echo '0-COMMENT=hello' ) | ccs-loadpolicy -p # (echo 'namespace ' ; echo 'acl_group 0 file read /foo' ) | ccs-loadpolicy -e and the output after adding these entries looks like # cat /proc/ccs/manager namespace /usr/sbin/ccs-loadpolicy /usr/sbin/ccs-editpolicy /usr/sbin/ccs-setlevel /usr/sbin/ccs-setprofile /usr/sbin/ccs-queryd namespace /bin/bash # cat /proc/ccs/profile namespace PROFILE_VERSION=20100903 0-COMMENT=-----Disabled Mode----- 0-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 enforcing_penalty=0 } 0-CONFIG={ mode=disabled grant_log=no reject_log=yes } 1-COMMENT=-----Learning Mode----- 1-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 enforcing_penalty=0 } 1-CONFIG={ mode=learning grant_log=no reject_log=yes } 2-COMMENT=-----Permissive Mode----- 2-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 enforcing_penalty=0 } 2-CONFIG={ mode=permissive grant_log=no reject_log=yes } 3-COMMENT=-----Enforcing Mode----- 3-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 enforcing_penalty=0 } 3-CONFIG={ mode=enforcing grant_log=no reject_log=yes } namespace PROFILE_VERSION=20100903 0-COMMENT=hello 0-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 enforcing_penalty=0 } 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } # cat /proc/ccs/exception_policy namespace aggregator /etc/rc.d/rc\?.d/\?\+\+messagebus /etc/rc.d/init.d/messagebus aggregator /etc/rc.d/rc\?.d/\?\+\+haldaemon /etc/rc.d/init.d/haldaemon aggregator /etc/rc.d/rc\?.d/\?\+\+dovecot /etc/rc.d/init.d/dovecot (...snipped...) acl_group 0 file ioctl @ANY_PATHNAME @COMMON_IOCTL_CMDS acl_group 0 file read @ANY_DIRECTORY acl_group 0 file getattr @ANY_PATHNAME namespace acl_group 0 file read /foo . The "namespace <$namespace>" line serves as namespace separator. As I said before, if we add "namespace <$namespace>" line to /proc/ccs/exception_policy /proc/ccs/profile /proc/ccs/manager , these files becomes no longer sortable by /bin/sort (i.e. stateful) . But since $namespace is a single word whereas a domainname is multiple words, we can safely identify "namespace <$namespace>" sequence within a line. If we add "namespace <$namespace>" prefix to each line of these files like # echo '' | ccs-loadpolicy -n # echo 'namespace /bin/bash' | ccs-loadpolicy -m # echo 'namespace 0-COMMENT=hello' | ccs-loadpolicy -p # echo 'namespace acl_group 0 file read /foo' | ccs-loadpolicy -e and make output like # cat /proc/ccs/manager namespace /usr/sbin/ccs-loadpolicy namespace /usr/sbin/ccs-editpolicy namespace /usr/sbin/ccs-setlevel namespace /usr/sbin/ccs-setprofile namespace /usr/sbin/ccs-queryd namespace /bin/bash # cat /proc/ccs/profile namespace PROFILE_VERSION=20100903 namespace 0-COMMENT=-----Disabled Mode----- namespace 0-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 enforcing_penalty=0 } namespace 0-CONFIG={ mode=disabled grant_log=no reject_log=yes } namespace 1-COMMENT=-----Learning Mode----- namespace 1-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 enforcing_penalty=0 } namespace 1-CONFIG={ mode=learning grant_log=no reject_log=yes } namespace 2-COMMENT=-----Permissive Mode----- namespace 2-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 enforcing_penalty=0 } namespace 2-CONFIG={ mode=permissive grant_log=no reject_log=yes } namespace 3-COMMENT=-----Enforcing Mode----- namespace 3-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 enforcing_penalty=0 } namespace 3-CONFIG={ mode=enforcing grant_log=no reject_log=yes } namespace PROFILE_VERSION=20100903 namespace 0-COMMENT=hello namespace 0-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 enforcing_penalty=0 } namespace 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } # cat /proc/ccs/exception_policy namespace aggregator /etc/rc.d/rc\?.d/\?\+\+messagebus /etc/rc.d/init.d/messagebus namespace aggregator /etc/rc.d/rc\?.d/\?\+\+haldaemon /etc/rc.d/init.d/haldaemon namespace aggregator /etc/rc.d/rc\?.d/\?\+\+dovecot /etc/rc.d/init.d/dovecot (...snipped...) namespace acl_group 0 file ioctl @ANY_PATHNAME @COMMON_IOCTL_CMDS namespace acl_group 0 file read @ANY_DIRECTORY namespace acl_group 0 file getattr @ANY_PATHNAME namespace acl_group 0 file read /foo , these files remains sortable by /bin/sort (i.e. stateless). The sum of lines in /proc/ccs/exception_policy + /proc/ccs/profile + /proc/ccs/manager are generally much fewer than the lines in /proc/ccs/domain_policy . Maybe "namespace <$namespace>" prefix is fine. Both "namespace <$namespace>" line and "namespace <$namespace>" prefix are hidden from users when browsing/editing via ccs-editpolicy . Also, we can make "namespace <$namespace>" prefix omissible when we use only namespace. The "namespace <$namespace>" line and the "namespace <$namespace>" prefix, which do you like to use? Well, the "namespace <$namespace>" line/prefix for /proc/ccs/manager might be confusing. But do we want to specify different manager programs/domains for different namespace at all? Is namespace for /proc/ccs/manager useful? From jamie at tomoyolinux.co.uk Sun May 8 22:34:09 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sun, 8 May 2011 14:34:09 +0100 Subject: [tomoyo-dev-en 221] Re: FW: Re: Re: About supportingpolicynamespace. In-Reply-To: <201105082205.HEF34318.OFUttNWESNPZPPGtPF@I-love.SAKURA.ne.jp> References: <201105030121.HBD57891.ZPttGFUtPWEOPNPSFN@I-love.SAKURA.ne.jp> <201105032249.GAE65106.PtWPEStUNPGPFNFtZO@I-love.SAKURA.ne.jp> <201105082205.HEF34318.OFUttNWESNPZPPGtPF@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > OK. I reconsidered the specification a bit. > > ... > > Both "namespace <$namespace>" line and "namespace <$namespace>" prefix are > hidden from users when browsing/editing via ccs-editpolicy . Also, we can make > "namespace <$namespace>" prefix omissible when we use only namespace. > > The "namespace <$namespace>" line and the "namespace <$namespace>" prefix, > which do you like to use? Prefix looks like a good approach to me. > Well, the "namespace <$namespace>" line/prefix for /proc/ccs/manager might be > confusing. But do we want to specify different manager programs/domains for > different namespace at all? Is namespace for /proc/ccs/manager useful? It would be good to get an opinion on this from someone who uses namespaces/containers regularly. I personally don't see much benefit from splitting manager.conf for each namespace. It is simpler just to keep the same manager programs for all namespaces. From haradats at nttdata.co.jp Mon May 9 12:52:49 2011 From: haradats at nttdata.co.jp (Toshiharu Harada) Date: Mon, 9 May 2011 12:52:49 +0900 Subject: [tomoyo-dev-en 222] Re: About supporting policy namespace. In-Reply-To: <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> References: <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> Message-ID: <4DC76511.8030506@nttdata.co.jp> I guess I'm late. (2011/05/02 6:57), Tetsuo Handa wrote: > Jamie Nguyen wrote: >> Tetsuo Handa wrote: >>> Jamie Nguyen wrote: >>>> Just to make sure we understand each other, do I understand correctly >>>> that you want to remove "initialize_domain" directive and replace with >>>> "initialize_namespace"? Or do you intend them to exist together? >>> >>> I won't remove "initialize_domain" directive. >>> "initialize_domain" and "initialize_namespace" directives coexist. >> >> This was the root of my misunderstanding! I was falsely under the >> impression that you wanted to replace "initialize_domain", but since >> this is not the case, namespaces can indeed be ignored by users that >> don't need it. Great! > > Sorry for making you confused. I meant to say that using "initialize_namespace" > is convenient for most cases for policy developers than using "initialize_domain" > because they can develop policy without worrying conflicts for domain_policy > exception_policy profile and manager. My understanding of initialize_domain is resetting the domain, which occurs in the existing "namespace". Personally, I prefer the new directive for "namespace" to imply creating/changing to a different "namespace". For example, change_namespace or transit_namespace, instead of initialize_namespace (I can live with initialize_namespace, though). >> All the changes look very good to me. I am guessing that you are >> proposing that each namespace will have it's own exception_policy.conf >> ? > > Yes. Each namespace will have its own domain_policy.conf exception_policy.conf > profile.conf and manager.conf . That's a problem, for we need to consider about > userland policy directory layout. For /proc/ccs/ directory, we don't need to > create domain_policy exception_policy profile and manager for each namespace > because we can switch namespace to read from or write to by writing > "namespace $namespace" line. But for /etc/ccs/policy/ directory, I think we > want to split files for each namespace. Well, technically it has no problem > with concatenating domain_policy-kernel.conf and domain_policy-apache.conf like > > # domain policy for namespace follows. > # domain policy for namespace follows. > > because the first word in a line (e.g. and ) can > serve as namespace separator. But for (e.g.) exception_policy-kernel.conf and > exception_policy-apache.conf , can we accept concatenated format like > > namespace > # exception policy for namespace follows. > namespace > # exception policy for namespace follows. > > which makes it impossible to use existing commands like /bin/sort ? > > But if we split exception_policy.conf for each namespace, > both exception_policy-$namespace.conf and $namespace/exception_policy.conf > are bad if we accept / in $namespace . > > Oliver, how do you want to have policy files for each LXC environment? > Concatenated single file or separated multiple files? -- Toshiharu Harada haradats at nttdata.co.jp From jamie at tomoyolinux.co.uk Mon May 9 15:18:52 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Mon, 9 May 2011 07:18:52 +0100 Subject: [tomoyo-dev-en 223] Re: About supporting policy namespace. In-Reply-To: <4DC76511.8030506@nttdata.co.jp> References: <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> <4DC76511.8030506@nttdata.co.jp> Message-ID: Toshiharu Harada wrote: > My understanding of initialize_domain is resetting the domain, > which occurs in the existing "namespace". > Personally, I prefer the new directive for "namespace" to imply > creating/changing to a different "namespace". > For example, change_namespace or transit_namespace, instead of > initialize_namespace (I can live with initialize_namespace, though). Hmm, I see your point. My main reason for suggesting initialize_namespace was to reduce the "overhead" on remembering many different directives. We already have "file read foo" so I thought "initialize_foo" might be appropriate. But I don't really mind either way. I can live with transit_namespace. From haradats at nttdata.co.jp Mon May 9 15:27:08 2011 From: haradats at nttdata.co.jp (Toshiharu Harada) Date: Mon, 9 May 2011 15:27:08 +0900 Subject: [tomoyo-dev-en 224] Re: About supporting policy namespace. In-Reply-To: References: <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> <4DC76511.8030506@nttdata.co.jp> Message-ID: <4DC7893C.9000005@nttdata.co.jp> (2011/05/09 15:18), Jamie Nguyen wrote: > Toshiharu Harada wrote: >> My understanding of initialize_domain is resetting the domain, >> which occurs in the existing "namespace". >> Personally, I prefer the new directive for "namespace" to imply >> creating/changing to a different "namespace". >> For example, change_namespace or transit_namespace, instead of >> initialize_namespace (I can live with initialize_namespace, though). > > Hmm, I see your point. My main reason for suggesting > initialize_namespace was to reduce the "overhead" on remembering many > different directives. We already have "file read foo" so I thought > "initialize_foo" might be appropriate. But I don't really mind either > way. I can live with transit_namespace. My understanding is "domains" are under the namespace and different namespaces mean different worlds. For that reason, I wanted to emphasize namespace is more fundamental. However, I'm quite sure we can live with any directives. ;-) I can live with initialize_namespace, too. From jamie at tomoyolinux.co.uk Tue May 10 05:48:27 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Mon, 9 May 2011 21:48:27 +0100 Subject: [tomoyo-dev-en 225] Re: About supporting policy namespace. In-Reply-To: <4DC7893C.9000005@nttdata.co.jp> References: <201105012248.FBB09824.PtWtPNZFUSPOFPGENt@I-love.SAKURA.ne.jp> <201105020011.AGC65678.PFFtttPNSPNZEUGOPW@I-love.SAKURA.ne.jp> <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> <4DC76511.8030506@nttdata.co.jp> <4DC7893C.9000005@nttdata.co.jp> Message-ID: Toshiharu Harada wrote: > However, I'm quite sure we can live with any directives. ;-) > I can live with initialize_namespace, too. Hehe I think we are both sitting on the fence here ;-) Tetsuo originally suggested/implemented "move_namespace", probably for similar reasons to yourself. Since both of you suggested similar directives, perhaps it is better to use "transit_namespace" instead of "initialize_namespace" (majority vote!). If we carry on this discussion much longer, it might become classified as "bikeshedding" ;-) Though I suppose we are too polite to each other for bikeshedding.... expect some serious flames from me in the next email so that we can really classify this as bikeshedding!! ;-) From jamie at tomoyolinux.co.uk Thu May 12 07:33:16 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Wed, 11 May 2011 23:33:16 +0100 Subject: [tomoyo-dev-en 226] Documentation Message-ID: I made changes in r4992 due to the contents page for 1.8.x docs possibly being too scary for new users and being a little too verbose. So the new default contents page is the shortened version found at htdocs/1.8/index.html.en, and the longer version can be found at htdocs/1.8/index-long.html.en. The longer version is basically identical to what we had as the contents page before r4992. Feel free to revert if you feel the older layout was better. I will be starting work on tomoyo 2.3 docs tomorrow. I plan to sync 1.8 docs to AKARI as well after I finish with 2.3 docs, which hopefully won't take too long. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Thu May 12 14:41:58 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 12 May 2011 14:41:58 +0900 Subject: [tomoyo-dev-en 227] Re: Documentation In-Reply-To: References: Message-ID: <201105120541.p4C5fw9s071747@www262.sakura.ne.jp> Jamie Nguyen wrote: > I made changes in r4992 due to the contents page for 1.8.x docs > possibly being too scary for new users and being a little too verbose. OK. I updated Japanese part. > I will be starting work on tomoyo 2.3 docs tomorrow. I was planning to start it today. ;-) So, last night I once deleted 2.3-tmp and re-copied from 1.8. Rough changes are done by now (revision 5002), but screenshots need to be retaken. I'll start retaking screenshots. From jamie at tomoyolinux.co.uk Fri May 13 05:30:30 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Thu, 12 May 2011 21:30:30 +0100 Subject: [tomoyo-dev-en 228] Re: Documentation In-Reply-To: <201105120541.p4C5fw9s071747@www262.sakura.ne.jp> References: <201105120541.p4C5fw9s071747@www262.sakura.ne.jp> Message-ID: Tetsuo Handa wrote: > Jamie Nguyen wrote: >> I made changes in r4992 due to the contents page for 1.8.x docs >> possibly being too scary for new users and being a little too verbose. > > OK. I updated Japanese part. > >> I will be starting work on tomoyo 2.3 docs tomorrow. > > I was planning to start it today. ;-) > So, last night I once deleted 2.3-tmp and re-copied from 1.8. > Rough changes are done by now (revision 5002), but screenshots > need to be retaken. I'll start retaking screenshots. Nice work! 2.3-tmp looks pretty good so far. Any further work we need to do in 2.3-tmp? By the way, is 2.4 going to make 2.6.40? I saw your posting of 38 patches to LSM but it seems only a few have been applied to security-testing#next From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Fri May 13 09:29:34 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Fri, 13 May 2011 09:29:34 +0900 Subject: [tomoyo-dev-en 229] Re: Documentation In-Reply-To: References: <201105120541.p4C5fw9s071747@www262.sakura.ne.jp> Message-ID: <201105130929.DJJ30722.ZPSUPtOFGtFENtPPNW@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > Tetsuo Handa wrote: > > Jamie Nguyen wrote: > >> I made changes in r4992 due to the contents page for 1.8.x docs > >> possibly being too scary for new users and being a little too verbose. > > > > OK. I updated Japanese part. > > > >> I will be starting work on tomoyo 2.3 docs tomorrow. > > > > I was planning to start it today. ;-) > > So, last night I once deleted 2.3-tmp and re-copied from 1.8. > > Rough changes are done by now (revision 5002), but screenshots > > need to be retaken. I'll start retaking screenshots. > > Nice work! 2.3-tmp looks pretty good so far. Any further work we need > to do in 2.3-tmp? I will merge texts/screenshots in 2.3 into 2.3-tmp. > By the way, is 2.4 going to make 2.6.40? I saw your posting of 38 > patches to LSM but it seems only a few have been applied to > security-testing#next TOMOYO 2.4 is blocked at "[07/38] LSM: Revive security_task_alloc()/security_task_free()/security_bprm_free() hooks." in the "[PATCH 0/38] TOMOYO: Starting toward TOMOYO 2.4." patchset. Yama and Snet will also use security_task_free() hook. David, may I have your answer regarding this patch? From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Sun May 15 21:39:41 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 15 May 2011 21:39:41 +0900 Subject: [tomoyo-dev-en 230] Re: Documentation In-Reply-To: <201105130929.DJJ30722.ZPSUPtOFGtFENtPPNW@I-love.SAKURA.ne.jp> References: <201105120541.p4C5fw9s071747@www262.sakura.ne.jp> <201105130929.DJJ30722.ZPSUPtOFGtFENtPPNW@I-love.SAKURA.ne.jp> Message-ID: <201105152139.HEE34303.PFtSGPFPtNPZWOUEtN@I-love.SAKURA.ne.jp> > I will merge texts/screenshots in 2.3 into 2.3-tmp. Done in revision 5026. http://tomoyo.sourceforge.jp/2.3-tmp/ Since most of topics in 1.8's Appendix do not apply for 2.3 (due to kernel version is too old or uses features specific to 1.8), only "Appendix D: Protecting SFTP service" is in the 2.3's Appendix. But I feel Appendix D is out of place compared to Appendix A-C. Should we remove Appendix D from 2.3? Also, since 2.3 does not support conditional ACLs, Advanced Topics has only Chapter 8: Interface permissions Chapter 9: Advanced profile management Chapter 10: Reinforced authentication . Maybe 2.3 does not need "Core"/"Advanced" distinction. From jamie at tomoyolinux.co.uk Sun May 15 22:35:25 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Sun, 15 May 2011 14:35:25 +0100 Subject: [tomoyo-dev-en 231] Re: Documentation In-Reply-To: <201105152139.HEE34303.PFtSGPFPtNPZWOUEtN@I-love.SAKURA.ne.jp> References: <201105120541.p4C5fw9s071747@www262.sakura.ne.jp> <201105130929.DJJ30722.ZPSUPtOFGtFENtPPNW@I-love.SAKURA.ne.jp> <201105152139.HEE34303.PFtSGPFPtNPZWOUEtN@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: >> I will merge texts/screenshots in 2.3 into 2.3-tmp. > Done in revision 5026. http://tomoyo.sourceforge.jp/2.3-tmp/ Great! > Since most of topics in 1.8's Appendix do not apply for 2.3 (due to kernel > version is too old or uses features specific to 1.8), only > "Appendix D: Protecting SFTP service" is in the 2.3's Appendix. > But I feel Appendix D is out of place compared to Appendix A-C. > Should we remove Appendix D from 2.3? Yes, it does seem a little out of place, but I don't think there is any harm done if we leave it there. > Also, since 2.3 does not support conditional ACLs, Advanced Topics has only > > ?Chapter 8: Interface permissions > ?Chapter 9: Advanced profile management > ?Chapter 10: Reinforced authentication > > . Maybe 2.3 does not need "Core"/"Advanced" distinction. Personally, I prefer to keep the distinction. By separating into "Core" group, we indicate to the newcomer that they can get away with only reading "Core". 7 chapters is less scary than 10 chapters, and it is better to make the learning curve appear as short and easy as possible. Also, I have started porting 1.8 docs to AKARI. Before, the home page for akari.sourceforge.jp was simply the documentation contents page, but I have created {index-tmp,about,support,links,documentation}.html.en in a similar style to the tomoyo.sourceforge.jp home page. We can move over to these once docs are finished too. I didn't know if you wished to make it clearer on index-tmp.html.en and about.html.en that AKARI is a personal project, so I leave that to you. At the moment, there are a few things left to do: 1) revise policy specification etc. for directives that AKARI does not support 2) some screenshots may have directives that AKARI does not support 3) I have deleted appendix D-J, but the ones relevant to AKARI can be copied back From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Mon May 16 16:07:46 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 16 May 2011 16:07:46 +0900 Subject: [tomoyo-dev-en 232] Re: Documentation In-Reply-To: References: <201105120541.p4C5fw9s071747@www262.sakura.ne.jp> <201105130929.DJJ30722.ZPSUPtOFGtFENtPPNW@I-love.SAKURA.ne.jp> <201105152139.HEE34303.PFtSGPFPtNPZWOUEtN@I-love.SAKURA.ne.jp> Message-ID: <201105160707.p4G77kSh085408@www262.sakura.ne.jp> Jamie Nguyen wrote: > Yes, it does seem a little out of place, but I don't think there is > any harm done if we leave it there. Domains in "Chapter 10" are deployed in serial and domains in "Appendix D" are deployed in parallel. In other words, "Chapter 10" is the first picture in chapter-10.html and "Appendix D" is the second picture in chapter-10.html . Therefore, I though "Appendix D" can come to the right place if rewritten as "Chapter 11". But I also felt that "Appendix D" is easier to try than "Chapter 10" because "Appendix D" explains complete steps while "Chapter 10" explains only concepts. Maybe rewriting "Chapter 10" as "Appendix E" is better. > Personally, I prefer to keep the distinction. By separating into > "Core" group, we indicate to the newcomer that they can get away with > only reading "Core". 7 chapters is less scary than 10 chapters, and it > is better to make the learning curve appear as short and easy as > possible. OK. If you have no more changes, let's copy 2.3-tmp/ to 2.3/ . > Also, I have started porting 1.8 docs to AKARI. Thank you. Documentation for AKARI is very similar to that of TOMOYO 1.8. What we need to do is to remove some few dozens of lines that explain capability ipc signal network inet dgram recv network unix dgram recv and to add few dozens of lines that explain version&config dependency explained at http://akari.sourceforge.jp/comparison.html . Appendix G-J applies to AKARI. Guiding users to http://tomoyo.sourceforge.jp/1.8/chapter-4.html after installation instructions might be possible if errata pages (like "capability" section explained at http://tomoyo.sourceforge.jp/1.8/policy-specification/domain-policy-syntax.html.ja#capability is not supported by AKARI. "ipc signal" section explained at http://tomoyo.sourceforge.jp/1.8/policy-specification/domain-policy-syntax.html.ja#ipc_signal is not supported by AKARI. ) are provided. From jamie at tomoyolinux.co.uk Tue May 17 06:41:07 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Mon, 16 May 2011 22:41:07 +0100 Subject: [tomoyo-dev-en 233] Re: Documentation In-Reply-To: <201105160707.p4G77kSh085408@www262.sakura.ne.jp> References: <201105120541.p4C5fw9s071747@www262.sakura.ne.jp> <201105130929.DJJ30722.ZPSUPtOFGtFENtPPNW@I-love.SAKURA.ne.jp> <201105152139.HEE34303.PFtSGPFPtNPZWOUEtN@I-love.SAKURA.ne.jp> <201105160707.p4G77kSh085408@www262.sakura.ne.jp> Message-ID: Tetsuo Handa wrote: > Domains in "Chapter 10" are deployed in serial and domains in "Appendix D" are > deployed in parallel. In other words, "Chapter 10" is the first picture in > chapter-10.html and "Appendix D" is the second picture in chapter-10.html . > > Therefore, I though "Appendix D" can come to the right place if rewritten as > "Chapter 11". > But I also felt that "Appendix D" is easier to try than "Chapter 10" because > "Appendix D" explains complete steps while "Chapter 10" explains only concepts. > Maybe rewriting "Chapter 10" as "Appendix E" is better. I'm not really fussed either way. If I had to choose, I would prefer to keep things as they are. Chapter 10 is not really usable without having read all previous chapters and having a fuller understanding of TOMOYO Linux, while Appendix D is more usable as a stand-alone article with less prior knowledge required. > OK. If you have no more changes, let's copy 2.3-tmp/ to 2.3/ . I don't think I have any further changes to do. >> Also, I have started porting 1.8 docs to AKARI. > > Thank you. Documentation for AKARI is very similar to that of TOMOYO 1.8. > What we need to do is to remove some few dozens of lines that explain > > ?capability > ?ipc signal > ?network inet dgram recv > ?network unix dgram recv Is "network inet raw recv" also missing, as according to http://akari.sourceforge.jp/comparison.html.en ? I have removed references to this also. > and to add few dozens of lines that explain version&config dependency explained > at http://akari.sourceforge.jp/comparison.html . Appendix G-J applies to AKARI. Sure, I will add these back. > Guiding users to http://tomoyo.sourceforge.jp/1.8/chapter-4.html after > installation instructions might be possible if errata pages (like > > ?"capability" section explained at http://tomoyo.sourceforge.jp/1.8/policy-specification/domain-policy-syntax.html.ja#capability is not supported by AKARI. > > ?"ipc signal" section explained at http://tomoyo.sourceforge.jp/1.8/policy-specification/domain-policy-syntax.html.ja#ipc_signal is not supported by AKARI. > > ) are provided. I am fine with maintaining separate AKARI pages, but it's up to you. I think it's less confusing for users to have AKARI docs kept separate. However, it does increase maintenance burden for us, but I have created htdocs/1.8/adapt_for_akari.sh to speed up conversion of pages from TOMOYO Linux 1.8.x docs. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Tue May 17 14:52:30 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 17 May 2011 14:52:30 +0900 Subject: [tomoyo-dev-en 234] Re: Documentation In-Reply-To: References: <201105120541.p4C5fw9s071747@www262.sakura.ne.jp> <201105130929.DJJ30722.ZPSUPtOFGtFENtPPNW@I-love.SAKURA.ne.jp> <201105152139.HEE34303.PFtSGPFPtNPZWOUEtN@I-love.SAKURA.ne.jp> <201105160707.p4G77kSh085408@www262.sakura.ne.jp> Message-ID: <201105170552.p4H5qUkQ055635@www262.sakura.ne.jp> Jamie Nguyen wrote: > > OK. If you have no more changes, let's copy 2.3-tmp/ to 2.3/ . > > I don't think I have any further changes to do. > OK. Done in revision 5031. > >> Also, I have started porting 1.8 docs to AKARI. > > > > Thank you. Documentation for AKARI is very similar to that of TOMOYO 1.8. > > What we need to do is to remove some few dozens of lines that explain > > > > capability > > ipc signal > > network inet dgram recv > > network unix dgram recv > > Is "network inet raw recv" also missing, as according to > http://akari.sourceforge.jp/comparison.html.en ? I have removed > references to this also. Yes. I forgot it. > I am fine with maintaining separate AKARI pages, but it's up to you. I > think it's less confusing for users to have AKARI docs kept separate. OK. Done in revision 240. Also, akari-svn ML was created for SVN commit mail notifications. http://lists.sourceforge.jp/mailman/listinfo/akari-svn From jamie at tomoyolinux.co.uk Tue May 17 16:48:13 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Tue, 17 May 2011 08:48:13 +0100 Subject: [tomoyo-dev-en 235] Re: Documentation In-Reply-To: <201105170552.p4H5qUkQ055635@www262.sakura.ne.jp> References: <201105120541.p4C5fw9s071747@www262.sakura.ne.jp> <201105130929.DJJ30722.ZPSUPtOFGtFENtPPNW@I-love.SAKURA.ne.jp> <201105152139.HEE34303.PFtSGPFPtNPZWOUEtN@I-love.SAKURA.ne.jp> <201105160707.p4G77kSh085408@www262.sakura.ne.jp> <201105170552.p4H5qUkQ055635@www262.sakura.ne.jp> Message-ID: Tetsuo Handa wrote: > OK. Done in revision 5031. > > ... > > OK. Done in revision 240. Great! > Also, akari-svn ML was created for SVN commit mail notifications. > http://lists.sourceforge.jp/mailman/listinfo/akari-svn Oops, I didn't realise we had tomoyo-svn and akari-svn mailing lists. I've subscribed now. Well, looks like our redesign and rewrite of websites and docs is basically complete :-) Thank you and congrats!! From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Thu May 19 21:57:30 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 19 May 2011 21:57:30 +0900 Subject: [tomoyo-dev-en 236] Re: About supporting policy namespace. In-Reply-To: References: <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> <4DC76511.8030506@nttdata.co.jp> <4DC7893C.9000005@nttdata.co.jp> Message-ID: <201105192157.ABE18749.NtOZtNPUWtSPPPFEGF@I-love.SAKURA.ne.jp> Jamie Nguyen wrote: > Tetsuo Handa wrote: > > The "namespace <$namespace>" line and the "namespace <$namespace>" prefix, > > which do you like to use? > > Prefix looks like a good approach to me. > OK. I reconsidered the specification a bit. As of revision 5040, I have diff.txt and diff2.txt . The former introduced /proc/ccs/namespace for adding new namespaces and reading namespace list. But as I modify userland tools, I came to feel that maintaining /etc/ccs/policy/current/namespace.conf that contains only the list of namespace (e.g. "", "") and implementing "ccs-loadpolicy -n" and "ccs-savepolicy -n" are wasteful. Thus, I removed /proc/ccs/namespace from the latter. Instead, I changed to create a new namespace when new <$namespace> prefix is used for the first time. > > Well, the "namespace <$namespace>" line/prefix for /proc/ccs/manager might be > > confusing. But do we want to specify different manager programs/domains for > > different namespace at all? Is namespace for /proc/ccs/manager useful? Also, I decided not to introduce namespace support for /proc/ccs/manager . Now, there is no need to use "namespace <$namespace>" prefix, for regarding /proc/ccs/exception_policy and /proc/ccs/profile , no line starts with '<'. "<$namespace>" prefix alone (rather than "namespace <$namespace>") is enough. To summarize, specification for diff2.txt is: (1) Allow using "<$namespace>" prefix in addition to conventional "" prefix when creating domains in /proc/ccs/domain_policy. (2) Domain's namespace is defined as the first word of the domainname. (3) Allow using "<$namespace>" prefix in /proc/ccs/exception_policy and /proc/ccs/profile . (4) Namespace for $namespace is created when "<$namespace>" prefix is used for the first time. "" is the built-in namespace. (5) If there are namespaces other than "" namespace, /proc/ccs/exception_policy and /proc/ccs/profile add "<$namespace>" prefix to each line. Otherwise, /proc/ccs/exception_policy and /proc/ccs/profile do not add "" prefix to each line. (6) Policy editor automatically adds "<$namespace>" prefix to each line when writing to /proc/ccs/exception_policy and /proc/ccs/profile . (7) Policy editor automatically filters by "<$namespace>" prefix on each line when reading from /proc/ccs/exception_policy and /proc/ccs/profile and /proc/ccs/domain_policy . (8) Policy editor provides namespace selector screen by collecting all "<$namespace>" prefix found in /proc/ccs/domain_policy and /proc/ccs/exception_policy and /proc/ccs/profile . (9) ccs-loadpolicy and ccs-savepolicy do not implement "-n" option because /proc/ccs/namespace is not provided. (10) "move_namespace" and "no_move_namespace" (which take same syntax for "initialize_namespace" etc.) are introduced for namespace transition upon execve(). (Do we prefer "change_namespace" or "transit_namespace" ?) (11) auto_namespace_transition="<$namespace>" (like auto_domain_transition="/virtual/pathname" ) is introduced for namespace transition upon permission granted. (Do we prefer auto_namespace_change="<$namespace>" or auto_domain_transition="<$namespace>" ?) (Does it sound strange to allow changing both namespace and domain by "task auto_domain_transition"/"task manual_domain_transition" ?) I'll remove diff.txt unless you prefer /proc/ccs/namespace interface. From jamie at tomoyolinux.co.uk Fri May 20 15:19:10 2011 From: jamie at tomoyolinux.co.uk (Jamie Nguyen) Date: Fri, 20 May 2011 07:19:10 +0100 Subject: [tomoyo-dev-en 237] Re: About supporting policy namespace. In-Reply-To: <201105192157.ABE18749.NtOZtNPUWtSPPPFEGF@I-love.SAKURA.ne.jp> References: <201105020657.GEG82898.ZFNWSGPtFOttNPUPPE@I-love.SAKURA.ne.jp> <4DC76511.8030506@nttdata.co.jp> <4DC7893C.9000005@nttdata.co.jp> <201105192157.ABE18749.NtOZtNPUWtSPPPFEGF@I-love.SAKURA.ne.jp> Message-ID: Tetsuo Handa wrote: > OK. I reconsidered the specification a bit. > > As of revision 5040, I have diff.txt and diff2.txt . Everything looks good to me :-) Personally I prefer transit_namespace rather than move_namespace. From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Sun May 22 23:39:45 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 22 May 2011 23:39:45 +0900 Subject: [tomoyo-dev-en 238] Re: About supporting policy namespace. In-Reply-To: <201105192157.ABE18749.NtOZtNPUWtSPPPFEGF@I-love.SAKURA.ne.jp> References: <4DC76511.8030506@nttdata.co.jp> <4DC7893C.9000005@nttdata.co.jp> <201105192157.ABE18749.NtOZtNPUWtSPPPFEGF@I-love.SAKURA.ne.jp> Message-ID: <201105222339.HEB04692.tttFSPENUOPPNFZPWG@I-love.SAKURA.ne.jp> I committed changes to SVN (revision 5053). You can start trying namespaces. Steps for using namespaces (from inside policy editor and from outside policy editor) are described below. Directives added for namespaces (i.e. "move_namespace" "no_move_namespace" "auto_namespace_transition=") will be revised to be more intuitive. To create a new namespace from policy editor: (1) Change to "Namespace Selector" screen by pressing "w" -> "n" keys. (2) Press "a" key and enter the name of namespace in <$namespace> format and press "Enter" key. (3) <$namespace> will be printed in addition to . To edit domain policy or exception policy or profile from policy editor: (1) Change to "Namespace Selector" screen by pressing "w" -> "n" keys. (2) Choose the name of namespace from the list and press "Enter" key. (3) Go to the screen you want to edit by pressing "w" -> "d"/"e"/"p" keys. To edit namespace transition upon successful execve() from policy editor: (1) Go to "Exception Policy Editor" screen of the namespace you want to edit. (2) Enter "move_namespace" line as with "initialize_domain" line. move_namespace $program from any or move_namespace $program from $domainname or move_namespace $program from $last_component_of_domainname Priority (from highest to lowest order) is shown below. (1) Don't check "move_namespace" entries if matched with one of "no_move_namespace" entries. (2) Transit to "<$program>" domain if matched with one of "move_namespace" entries. (3) Don't check "initialize_domain" entries if matched with one of "no_initialize_domain" entries. (4) Transit to "<$current_namespace> $program" domain if matched with one of "initialize_domain" entries. (5) Transit to "$current_domainname $program" domain if matched with one of "no_keep_domain" entries. (6) Remain at "$current_domainname" domain if matched with one of "keep_domain" entries. (7) Transit to "$current_domainname $program" domain. To edit namespace transition upon ACL match from policy editor: (1) Go to "Domain Policy Editor" screen (or "acl_group" lines in "Exception Policy Editor" screen) of the namespace you want to edit. (2) Enter an ACL entry with auto_namespace_transition="<$namespace>" part. For example, file pivot_root /usr/lxc/lxc1/ /usr/lxc/lxc1/oldroot/ auto_namespace_transition="" will transit to "" domain if pivot_root("/usr/lxc/lxc1/", "/usr/lxc/lxc1/oldroot/") is requested. To edit namespace transition upon condition match or /proc/ccs/self_domain : (1) Go to "Domain Policy Editor" screen (or "acl_group" lines in "Exception Policy Editor" screen) of the namespace you want to edit. (2) Enter "task auto_domain_transition" line or "task manual_domain_transition" line as usual. This allows transition to arbitrary domains in different namespaces whereas "move_namespace" and "auto_namespace_transition=" allow transition to the root domain of different namespaces. To select namespace from outside policy editor: (1) Regarding exception policy and profile, add <$namespace> prefix to each line. Exception policy example: acl_group 0 file read /etc/ld.so.cache acl_group 0 file read /etc/ld.so.cache Profile example: 1-CONFIG={ mode=learning grant_log=no reject_log=yes } 3-CONFIG={ mode=enforcing grant_log=no reject_log=yes } (2) Regarding domain policy, nothing to do since the domainname implies namespace. use_profile 0 use_group 0 /sbin/init use_profile 0 use_group 0 /sbin/init use_profile 0 use_group 0 (3) Regarding other files, nothing to do since namespace is not supported. We are close to finalize the specification of policy namespace support. Oliver, does this specification satisfy your needs for using TOMOYO in LXC environments? From from-tomoyo-dev-en at I-love.SAKURA.ne.jp Tue May 31 17:36:32 2011 From: from-tomoyo-dev-en at I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 31 May 2011 17:36:32 +0900 Subject: [tomoyo-dev-en 239] Re: About supporting policy namespace. In-Reply-To: <201105222339.HEB04692.tttFSPENUOPPNFZPWG@I-love.SAKURA.ne.jp> References: <4DC76511.8030506@nttdata.co.jp> <4DC7893C.9000005@nttdata.co.jp> <201105192157.ABE18749.NtOZtNPUWtSPPPFEGF@I-love.SAKURA.ne.jp> <201105222339.HEB04692.tttFSPENUOPPNFZPWG@I-love.SAKURA.ne.jp> Message-ID: <201105310836.p4V8aWnQ082261@www262.sakura.ne.jp> I added a page for using namespace. http://tomoyo.sourceforge.jp/1.8/chapter-15.html (0) Do you see problems with this specification? (1) What explanation is insufficient in the above page? (2) Should we use auto_domain_transition="/path/to/program" auto_domain_transition="" in conditional ACL rather than auto_domain_transition="/path/to/program" auto_namespace_transition="" ? (3) Should we use transit_namespace / no_transit_namespace or initialize_namespace / no_initialize_namespace or change_namespace / no_change_namespace or jump_namespace / no_jump_namespace in exception policy rather than move_namespace / no_move_namespace ? (4) Should chapter 4 and afterwords be rewritten using policy namespace in the future?