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 </usr/sbin/httpd2> 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="</usr/sbin/httpd3>" task manual_domain_transition </usr/sbin/httpd4> 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. <apache>) policy is meaningless > without top-level namespace (e.g. <kernel>) 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...) _______________________________________________ tomoyo-dev-en mailing list tomoyo-dev-en@lists.sourceforge.jp http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev-en
