I thought on using a tree view for all policies, but it leads to confusion. For example, /sbin/init could lead to a lot of daemons, each daemon leading to a multitude of applications, and so on. So if we use the treeview, it will require to go about 13 levels deeper to get the application you want. And it also makes harder to find the application you want.

The ccs-editpolicy simplifies it by trimming the initial path, so it is easier to see. Maybe I’ll follow the same idea.

Another problem is that the entire policy is contained in the same big policy file. So we cannot, for example, provide specific policy for an RPM inside the package, we’ll have to merge it with the system policy. For example, we cannot set policy for /sbin/httpd – we have to check all the possible execution paths leading to /sbin/httpd (like /sbin/init, /sbin/init /etc/rc …, and so on). I was already thinking on it, but nothing is done about this yet.

2nd : this is always the same thing. So I guess this is the executable on which we want to apply some policies ?

3rd column : what is it ? The list of function calls by the 2nd column ? If yes, then we should use a hierarchical tree. Something like this : | + — /etc/rc.d/init.d/asusoled | |- /bin/rm |- /bin/sed

cf also : http://tomoyo.sourceforge.jp/en/1.6.x/tool-editpolicy.html

Another interesting things which could be interesting : - ability to save or load a policy for a domain/executable. Some polices sample here : http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/?v=policy-sample - ability to manage policies by rpm packages: list installed packages on the system, select a package, start learning mode. As we have the list of files in the packages, only the entries ( and their children ) for the files contained in the package will be shown.

Good job doc.!