* Yuan Chunyang (cyyuan79@private) wrote: > > 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 > > yes. But I want to put this metapolicy in a concentrated configure file. Then we can > write our this rule, such as "(a and b) or c", in a file. When boot up, kernel will read > it . As you said , I will implement it using sysfs filesystem. I can't imagine exposing per-hook rules will help improve security in any way. This is the kind of thing that is exporting the internals of a framework and expecting people to make sense of it. Further, the framework interface is not intended to be completely stable, it changes as other kernel internals change. Can you give a precise example where a single default composition policy is insufficient? (BTW, thanks for using sysfs, reading config file from kernel is a no go) > > 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? > > Yes. The DAC is implemented by ACL. > > > > > I'll be interested to see your results. Are you implementing your own MAC and > > RBAC systems, or starting with, say, SELinux? > > Ok, when the framework comes out, I will put it to maillist. We accomplished our > own MAC system. > What framework are you waiting for? No shame in publish early/publish often ;-) thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2.1.3 : Thu Sep 09 2004 - 09:33:10 PDT