Serge E. Hallyn wrote: <snip> > > >>>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. > What does a, b and c refer to (obviously modules) but which ones? what about modules built into the kernel like SELinux, capabilities, root plug and so on? How does the user know what their symbol is? This should be done by name, (selinux and capabilities) or backdoor, and so on. > > 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 > Shouldn't there just be a file for each hook instead of this awkward syntax? echo "(selinux and capabilities) or backdoor" > /sys/security/stacker/inode_permission echo "selinux and capabilities" > /sys/security/stacker/default Aside from these trivial notation changes, how would this be implemented practically? You'd have to have an init script setting these on boot, long after some modules may have become active and started enforcing. This makes it not trivial to set the decisions up from the beginning, either an initrd or compiling them into the kernel as config options would be required. > 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? > SELinux is flexible enough that starting a new MAC implementation from scracth should be really a last resort. > >>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 > you probably shouldn't try to put a parser in the kernel, this is excessive overhead that can be avoided by serializing the data to a binary file and feeding that into the kernel (see SELinux and checkpolicy). > 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 > Joshua Brindle
This archive was generated by hypermail 2.1.3 : Thu Sep 09 2004 - 08:00:02 PDT