>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. I'll have to figure out how to search the mailing list properly. > >> 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. I'm looking forward to reading it. > >> (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. Yes, this the main concern I had, and one area where label-based MAC like SELinux does have a noticeable advantage over pathname-based MAC such as TOMOYO Linux. However, as http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#g6a56098 clearly shows, TOMOYO was made with these limitations in mind. Chroot isn't an issue because TOMOYO uses the absolute pathname (I've played around with this quite a bit). The potential problems, as I see them, are: 1) renaming (mv foo bar) 2) symlinking (ln foo bar) 3) hardlinking (ln -s foo bar) 4) modifying Unix properties (chown/chmod) 5) mounting (--bind or otherwise) 6) switch_root/pivot_root() If blacklisting commands were added, there are two ways to solve the first four items I've listed. First, one could blacklist the path1 part of the commands, with something along these lines: deny file write /dev/shadow deny file append /dev/shadow deny file unlink /dev/shadow deny file chown /dev/shadow deny file chgrp /dev/shadow deny file chmod /dev/shadow deny file symlink /dev/shadow any deny file link /dev/shadow any deny file rename /dev/shadow any That may not be exhaustive. For example, directories may need to be protected as well. If need be I'll put more time and thought into coming up with a more complete list. If code is added for this type of blacklisting, maybe a "deny file change" or something along those lines could be added to include all of these possibilities. For the remaining items (mount and switch_root/pivot_root()), blacklisting the specific ways to get to the protected file/directory would be overly complicated; I would simply mounting and switch_root/pivot_root() completely from all domains which don't have a policy created for them yet. I realize this could become complicated quickly. For example, the domain which reads and implements /etc/fstab would have to have a policy created for it so that it is allowed to mount, which would then mean that /etc/fstab would have to be protected via blacklisting, which would then mean that a policy would have to be created for at least one program to edit /etc/fstab, which would mean that we would have to be careful not to allow domains which are lacking a full policy from transitioning to domains which can alter /etc/fstab. Despite this, I feel that a blacklisting approach like this could be quite doable. Just to reiterate, I realize blacklisting isn't nearly as good as whitelisting, but for the domains which don't have a full policy yet it may be a good way to make the system just a bit more secure until everything has a whitelisting policy. > >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