> The different modules may have different relationship on every hooks. > Stacker can not do these. And stacker should not do these. The stacker module is intended for use in stacking small, limited-purpose modules. See the archives of this mailing list for prior discusisons about things closer to what you are trying. That's not to say what you want isn't feasible, even easily implemented, but a general purpose stacking LSM should probably not be bogged down with this. This is a case where the coding may be easy, and the configuration is very difficult. > > And how do we do "(a and b) or c" ? :) > > I think this is the problem should be resolved. And this relationship may be > optimiszed to implement. I'm not sure what you mean by "may be optimised to implement." On a per-module basis, one approach would be: # modprobe stacker # echo "(a and b) or c" > /sys/security/stacker/compose # modprobe digsig_verif # modprobe bsdjail # modprobe seclvl On a per-hook basis, I suppose you could # modprobe stacker # echo "default a or b or c" > /sys/security/stacker/compose # echo "inode_permission (a and b) or c" > /sys/security/stacker/compose # ... # modprobe digsig_verif # modprobe bsdjail # modprobe seclvl > The examples come from our pratical work. If the different modules, such as DAC, > MAC, RBAC, are in the same system, the relationship should be explicit on every > hook. I usually think of LSM as implementing MAC and not DAC, but I guess there's nothing stopping you :) What do you want in additional DAC, mainly to build your own ACL's? I'll be interested to see your results. Are you implementing your own MAC and RBAC systems, or starting with, say, SELinux? > BTW: Can someone tell me how to parse a configure file? The example source > codes are welcome. This file can be read by kernel module. > The configure file may be: > #this is comment > hostname = xxx.xxx.xxx.xxx > #this is netmask > mask = xxx.xxx.xxx.xxx Use of a pseudofs or a sysfs interface is strongly recommended. Reading a file from the kernel is very strongly frowned upon. As an example of the pseudofs approach, look to linux/security/selinux/selinuxfs.c:sel_write_load and linux/security/selinux/ss/services.c:security_load_policy. For DTE, I use a sysfs file and cat the policy into that file line by line. -serge
This archive was generated by hypermail 2.1.3 : Wed Sep 08 2004 - 19:05:24 PDT