David Wagner wrote: > > Stephen Smalley wrote: > >It seems that we should be able to address this problem by providing > >support for composing security modules with the dummy functions. > > Good point. That sounds like a clean way to address the issue. One can always write a policy which encompasses multiple policy components, without resorting to composition. The "dummy" functions should provide the "traditional" Linux behavior. Any module which replaces the traditional (dummy) modules will have to account for the traditional behavior, either by maintaining it or replacing it. > > This does have one interesting consequence: We have to start thinking > about composition. Up to now, there was some rough consensus to not > even think about composition at all, because it is tricky. I'd like > to suggest that we ought to think carefully about composition---I think > there are some things we can do to make the problems less troublesome > (see some of my earlier posts on the topic), but composition introduces > non-trivial issues. Policy composition goes well beyond "non-trivial". If you've any doubts, consider a policy as simple as privileged ports. Is it a DAC policy? If it isn't, and "privilege" is defined as permission to violate a policy (as P1003.1e assumes) then what kind of policy is it, and how does that relate to the DAC policy on files? (Please, no one start a thread trying to answer these questions!) I remain of the opinion that a policy composer policy module is the best way to handle this issue. -- Casey Schaufler Manager, Trust Technology, SGI caseyat_private voice: 650.933.1634 casey_pat_private Pager: 888.220.0607 _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu May 31 2001 - 15:22:31 PDT