Tomoyo GUI
July 6, 2009
As promised in the previous post, here come some first insight into the GUI for Tomoyo Linux, which will be present in Mandriva 2010.
Initial view
Active security domains
As far as I know, this is the first GUI for Tomoyo out there (except the TomoyoGUI Eclipse Plugin, but it seems to be quite eclipse-bound and abandoned. Its page is in Japanese, but the all-mighty google translator helped me to take a peek into it). But, of course, I might be wrong – so please let me know if you know of any other GUI for Tomoyo Linux.
Obviously there are still a lot of things to do:
- add support for auditing/tomoyo security log into msec
- add support for reloading profile on-the-fly
- saving/loading/changing settings on the fly
- support complex statements
- everything else
so keep an eye on this blog for more news.
Regards,
Dr. Eugeni 
hehehehe
Good job doc.!
I have some difficulties understanding the UI. If I understand correctly : 1st column : . What is it ? When lokking at some policies samples, it seems to be always . Should we show it then ?
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.
The problem with tomoyo is that the policies do not contain the executable path, but the sequences of execution from kernel until the current executable.
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.
Wouldn’t it be a good idea to integrate tomoyo_gui into msec_gui? To have one gui for all security related settings…
That’s the idea
.
You don’t need to check all the possible execution paths leading to specific daemon/executable – you just need an ‘initialize_domain’ rule in exception_policy.conf. Just say ‘initialize_domain /sbin/httpd’ and then all the rules applied to /sbin/httpd/ domain will take effect no matter how httpd was executed.