Re: about the multiple security module in LSM

* Yuan Chunyang (cyyuan79@xxxxxxxxxxx) 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