Le 23/11/2011 04:59, Tetsuo Handa a écrit : > TOMOYO has been trying to avoid inheritance of access permissions as much as > possible. I understand that as a very good initial requirement for a straightforward and explicit auditing tool. For access control, inheritance does not necessarily mean redundancy. For me it is the other way around. I agree with Jamie here that the policy writer has a big responsibility to avoid creating redundancy. Unfortunately that is probably true for all frameworks. > Currently, TOMOYO kernel holds only one use_group line for each domain. > This is something like allowing only one "#include" line in source code. > Your suggestion is something like allowing multiple "#include" lines. A good comparison > Of course, it is technically possible to implement your suggestion in > the kernel. The questions would be > (1) whether it is worth to implement your suggestion in the kernel I think only you guys will make that decision :) > (2) inheriting multiple "use_group" lines to domains automatically created > upon execve() might cause a lot of (unused) redundant permissions I might miss your point here, please make it clearer if my view below does not address your question. If I can write something like: <kernel> /bin/prog use_profile 3 use_group BASE use_group X use_group GNOME use_group IBUS use_group PULSEAUDIO file write /xxxx <custom domain specific rules> it is fairly easy to see what functions the application uses and what has been authorized, compared to the same policy with all the explicit rules: <kernel> /bin/prog use_profile 3 use_group 1 file read @X-HOME-RO file read/write/truncate @X-HOME-RW file read @X-FILES file read @GNOME-RO file chmod @IBUS-HOME 0700 file read @IBUS-HOME file read /dev/shm/pulse-shm-\* file create /dev/shm/pulse-shm-\* 0400 file read @PULSE-RO file read/write/truncate/unlink @PULSE-RW file write /xxxx <custom domain specific rules> As you can see, here I have already tried to group paths (FYI @GNOME-RO is ~50 wildcarded paths). But because I can't group rules, I need to create multiple group paths, usually one for read-only, one for read/write "types". That is just some trick I used to simplify my policies, but in reality having grouped rules would be much clearer and exact. Because using these group paths, I sometimes give more access than is necessary (redundancy), that is a sacrifice I make in the hope that one day I will still be able to read my policies, ie: when software updates arrive. You may think this path grouping is probably worse than putting all rules for the domain in one go, but how can you be sure no rule is redundant when you have 150+ lines for one domain? I think a good access control policy is something you need to be able to read *again* :) Otherwise I would be using SELinux haha ;) Grouping by functionality is also a good design principle in my view, as it makes domain specific rules stand out. It is then easier to identify abnormal requests from programs and avoid adding those rules. You probably wouldn't spot those at first if it was in the middle of 150+ rules that you got from learning mode. For me TOMOYO is good because it is simple, straightforward and effective. I hope we can use multiple named grouped rules for policies without cluttering the framework. If you don't have time, I could start diving in the code to provide a patch for this (in a few weeks). Although I am missing kernel coding experience, I'm up for challenges - and would love to see this functionality come alive. I personally believe this would speed up policy writing for TOMOYO, once the base groups have been defined. Regards, Milton Yates
TOMOYO
Fork