Daniel, First of all, it was so nice to read your opinion in this mailing list. Thank you for the posting. 2011/5/1 Daniel Thau <danth****@yahoo*****>: > I doubt I'm the first person to have interest in doing this, but using search engines to look for "tomoyo blacklist" did not turn up much along these lines. I apologize if this has been answered and I've simply missed it. You are not the first person. Since the first release of TOMOYO, several people asked/proposed to support blacklist. > First, some background of my understanding of the situation (in case I'm missing something or I misunderstood something): > > I realize that disallowing everything except what is whitelisted has numerous advantages over allowing everything except what is blacklisted. The problem with whitelisting mandatory access control (in general) is that the system is useless until policies have been created which cover everything. I'm rather fond of TOMOYO's approach to this, in which one can choose to either allow everything (disabled/learning/permissive modes) or disallow everything which is not whitelisted (enforcing mode), per domain. This allows me to slowly build up my policies, locking down one domain at a time. A very smart solution. However, this means that no file is protected by TOMOYO from being destroyed or altered until all domains are have full policies. It will take me a while to create policies for everything, and the better protected I can be in the mean time the better. > > What I would like to do, if TOMOYO supports this in some fashion, is to allow any domain which I have not yet created a policy for be able to do anything except what is blacklisted. Specifically, I'd like to protect files and directories such as my backups from being altered or destroyed by programs I've not created a policy for yet. Due to the fact that TOMOYO is pathname-based, I believe this would also require blacklisting symlinking and hardlinking to the files and directories I want to protect, and maybe blacklisting mounting as well. Or maybe I can simply protect them based on inode, which I don't believe would change despite hardlinking/symlinking/mounting. > > What I have been doing up until now is initialize_domain for specific programs such as /bin/rm, and in those whitelisting everything except what I want blacklisted. I would then no_initialize_domain /bin/rm for every other domain which I have created a policy for. This has already saved me from accidentally rm'ing files I wanted to keep. However, it does not protect those files from every program which could potentially harm them. > > The only way I was able to think of to do this would be to create an acl_group for all domains that have not yet had a policy written specifically for them yet. This acl_group would then be filled with everything I can allow (file execute, file read, misc env, ipc_signal, etc), except what I want to blacklist. Presumably that would require a lot of use of the \- wildcard. > > I am using TOMOYO Linux 1.8.x. > > I have two questions: I assume that Tetsuo has been preparing a detailed (and long) responce. Before that here's my opinion. > (1) Is there anything I'm missing which would make this a bad idea? I suspect so, otherwise it'd likely be mentioned somewhere in the documentation, but I've been unable to think of anything else. I thought it best to ask on this mailing list before I try to use it. It's not a bad idea at all, but there are some problems that can not be ignored. Suppose TOMOYO supports blacklist and you write up your policy, your policy include pathnames. Obviously, you don't want to change the meaning of your policy. It is not easy to keep the meaning of your policy because "names" can be changed by many ways. To keep your policy definitions, you have to keep "names" a system. It is not only renaming that affect names, consider chroot, mount and other namespace operations. For the above reasons, I don't think blacklist approach cannot be a solution for "security first" cases. But I think for some situations, having a blacklist might benefit users and enlarge usages of TOMOYO. I would like to encourage you to dig the situations where we can apply the blacklist approach, first. If you succeed to find the needs or special situations, I'm quite sure Tetsuo will be willing to add new features to TOMOYO. > (2) Is there a better way to go about doing this other than what I have mentioned? Listing everything under "Domain policy syntax" in the acl_group seems a bit awkward, and I'm likely to miss something as I'm not completely familiar with all of the things which TOMOYO can allow/disallow. Best regards, Toshiharu Harada harad****@gmail*****
TOMOYO
Fork