Re: Multiple contexts

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Wed, Jan 12, 2005 at 09:40:46PM +0000, Stephen Bennett wrote:
> On Wed, 2005-01-12 at 13:11 -0700, Ivan Gyurdiev wrote:
> > > Because then policy would be encoded in the file attributes, not in a
> > > centralized security policy.  Hence, one would be unable to analyze
> > > information flow in the system based solely on the policy and would have
> > > to also analyze the complete filesystem state, and that state is much
> > > more subject to change at runtime than the policy itself (one would
> > > hope).
> > 
> > Please explain this some more - Luke also seems confused about this
> > (unless I misunderstand). I don't understand how the change from one
> > context to multiple contexts stored per file translates into policy
> > being encoded in the file attributes.
> 
> AIUI, the issue is something like this: 
> 
> With only one type per file, it's possible to look at the policy and be
> certain (for example) that domain1 can't affect domain2 in any way,
> because there are no interactions allowed between the two, and the file
> types they can access don't overlap. If you allow multiple contexts per
> file, that ability goes out of the window, and you have to look at which
> files have multiple contexts and what contexts they are before you can
> figure out where information can and can't flow.
 
 and you'd need to take all of the files matched by a regexp for one
 filetype, and all of the files of the other, work out if there are any
 common ones, and those would be your "multiple contexted" files.

 this you could do at policy compilation time.

 the thing is - which is easier: to expect people to do that
 analysis themselves [by modifying the default policies]
 or to do it in an automated at-pol-compile-time?
 
 what is gained and is it worth it in terms of the cost of development
 and extra complexity of the policy macroing system and the useability?

 is the extra syntax useful or hazardously complex?

 l.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.